Discussions related to Visual Prolog
Peter Muraya
VIP Member
Posts: 147
Joined: 5 Dec 2012 7:29

Inconsistency in trapping and reporting error The interface 'winner{@Vacancy}' takes 1 argument(s)

Unread post by Peter Muraya »

Hi,
I see some inconsistency in the way Visual Prolog compiler traps and reports the following error: The interface 'winner{@Vacancy}' takes 1 argument(s). Consider the following code which I assumed to be valid; the compiler throws up this error at the the line marked /*1*/ , BUT NOT at the one marked /*2*/. To clear the error, I had to add an unbounded domain as illustrated by the commented statement -- which I did not like. Is there some logic to this behavior that I don't understand?

Code: Select all

interface winner{@Vacancy}      domains           method = all; best.        properties           vacancy:@Vacancy. end interface   interface expression      predicates            trim:(winner::method) determ.   /*      1     */            %trim:(winner{_}::method) determ. end interface   class expression:expression end class   implement expression      clauses            trim(winner::all).     /*    2     */   end implement   implement main   clauses     run() :-         succeed(). % place your own code here   end implement main   goal     main::run().  
Mutall Data Management Technical Support
Martin Meyer
VIP Member
Posts: 328
Joined: 14 Nov 2002 0:01

Unread post by Martin Meyer »

Hi Peter,

I think, the compiler's behavior is not inconsistent there. The manual teaches:
This piece of code illustrates how to create an integer queue and insert an element in it:

Code: Select all

..., Q = queueClass{integer}::new(), Q:insert(17), ...
It is not necessary to apply the type explicitly, instead the compiler can infer it from the context:

Code: Select all

..., Q = queueClass::new(), Q:insert(17), ...
The compiler sees that Q must be an integer queue, because we insert 17 into it.
In your line /*1*/ the compiler cannot infer a value for type parameter @Vacancy from the context. However in line /*2*/ it can always determine the value of the type parameter from context (provided the context, i.e. line /*1*/, is stated syntactically correct). Thus, the type parameter cannot be ommitted in /*1*/, but can be ommitted in /*2*/.

The value for type parameter @Vacancy, which has to be supplied in /*1*/, does not need to be _. Usually the code would be something like:

Code: Select all

interface expression{@Vacancy}      predicates            trim : (winner{@Vacancy}::method) determ.   /*      1     */ end interface   class expression{@Vacancy} : expression{@Vacancy} end class   implement expression{@Vacancy}      clauses            trim(winner::all).     /*    2     */ end implement
Many regards
Martin
Martin Meyer
VIP Member
Posts: 328
Joined: 14 Nov 2002 0:01

Unread post by Martin Meyer »

Or, when you want, that expression does not have type parameter @Vacancy, code it in the way:

Code: Select all

interface winnerDomains      domains           method = all; best. end interface   %---   interface winner{@Vacancy}     open winnerDomains     properties         vacancy : @Vacancy. end interface   %---   interface expression     predicates         trim : (winnerDomains::method) determ.   /*      1     */ end interface   class expression : expression end class   implement expression     clauses         trim(winnerDomains::all).     /*    2     */ end implement
Regards
Martin
Peter Muraya
VIP Member
Posts: 147
Joined: 5 Dec 2012 7:29

Unread post by Peter Muraya »

Thanks Martin.
Since this issue is being brought about by the parameter in the winner interface, I have had to move the method domain from where I thought would be its most logical home to one of my existing and non-parameterized interface -- similar to your winnerDomains in the second example.
Mutall Data Management Technical Support
Post Reply