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