Reply: 回复: \a^b

"Lumj" <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
Can you point me to some detailed material on the issue discussed long ago? 

 
------------------ Original ------------------
Sender: "Ulrich Neumerkel"<[email protected]>;
Send time: Thursday, Dec 12, 2013 10:52 PM
To: "default"<[email protected]>; "SWI-Prolog"<[email protected]>; "ulrich"<[email protected]>; 

Subject: Re: [SWIPL] 回复:  \a^b



Lumj :
> I'm doing \(X:Y)^p(X,Y) to try a lambda call with parameter pattern
> matching, not to try a binary lambda call. :-)

So syntactically you would write \ (X:Y)^p(X,Y). Yet, the semantics
for this is unclear.

You can easily extend library(lambda) to handle a fixed number of
arguments.  Say

\ (X:Y)^^p(X,Y)

\ (X:Y:Z)^^^p(X,Y,Z)

That is: one new construct for each number of arguments.

But if you want to handle an arbitrary number of arguments with one
construct, you are soon into defaultiness.  You will get all kinds of
undesirable properties, maybe even violating monotonicity.  If you
look into the past, we had a similar issue long ago:

Once upon a time in the early 1980s, there was apply/2, defined as:

        apply(Pred, Args) :-
                Pred =.. List,
                append(List, Args, Full),
                Goal =.. Full,
                call(Goal).

It permitted to reshuffle arguments with the same liberty as
manipulating a list.

Fortunately, it was replaced by call/2..call/8 which is cleaner, as it
"types", permits cross referencing and much more.
-------------- next part --------------
HTML attachment scrubbed and removed
_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.