Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!olivea!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: STCS8004%IRUCCVAX.UCC.IE@mitvma.mit.EDU
Newsgroups: comp.lang.scheme
Subject: Logic does not Apply
Message-ID: <9104300906.aa04392@mc.lcs.mit.edu>
Date: 30 Apr 91 12:36:00 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 58

The title says it all, but some elaboration is perhaps in order!

One might expect (naively?) that

     (apply bin-op (list item1 item2))  =  (bin-op  item1 item2)

for *all* bin-ops, provided that bin-op's arguments are compatible with it.
But it is not so, since instead of the expected

     (apply and '(#f #t)) --> #f

one gets some  grumble that either 'and' is an  undefined variable or it is
not the right kind of parameter-1 to 'apply'.

However if one uses the eta-conversion  (lambda (x y) (f x y)) = f then
'apply' works as expected:

     (apply (lambda (x y) (and x y)) '(#f #t)) --> #f.

The  catch  is  that  eta-conversion  is  normally  but  not  strictly (pun
*intended*) valid  for 'and'. Why? Because  the lambda-abstracted form will
evaluate *both* arguments before passing them  on to the 'and' in its body,
whereas (and a b) will not evaluate 'b' if 'a' evaluates to false (see RxRS
Section 7.3).

Now '+', being a built-in procedure, can be applied directly in expressions
like:

     (apply + '( 2 3)) --> 5

so why not 'and' and 'or' without the lambda wrapping?

It  seems to  me that  the difference  lies in  the fact  that the  logical
operators are  defined in the R3  and R3.99 reports (section  7.3) as being
*derived* expression types, so presumably do not qualify as 'procedures' in
the sense specified for the first argument to 'apply' (section 6.9).

So,  we  can  define  operators  like  'and',  'or',  ... using primitives,
therefore they  only rank as  *derived expressions*, not  procedures. Fine!
But  we can  also define  arithmetic operators  in terms  of the primitives
zero and  the successor function. Even  better, everything---boolean values
and functions,  integers and arithmetic  operators, and so  on---all can be
defined in terms of lambdas and  applications alone, so why not make *them*
derived expressions also? :-)

That the logical operators are derived  expressions may well be the *legal*
answer as to  why 'and' and 'or' cannot be  used with 'apply'---my question
is though: is it a *reasonable* answer, with or without the RxRs Reports to
hand?  Why shouldn't 'and' and 'or' be first class citizens of Scheme?

It seems that logic does not apply! :-)

Gordon Oulsnam                                 stcs8004@iruccvax.ucc.hea.ie

"When *I* use a word," Humpty Dumpty said, in a rather scornful tone,
"it means just what I choose it to mean---neither more nor less."

'Through the Looking Glass', Lewis Carroll