[plt-scheme] macros, special forms, and lazy functions

On Dec 10, 2009, at 2:09 PM, Jos Koot replied to my questions:

>> As far as my beginning students are concerned, "and" and "or" are   
>> functions with contract
>> Boolean Boolean ... -> Boolean
>> They happen to be "smart" about their arguments, not bothering to   
>> evaluate the later arguments if the earlier arguments answer the   
>> question.
>
> In fact -> any (including multiple values), for example:
> (and #t #t (values 1 2)) --> multiple value 1 2

Right, but my beginning students are using HtDP languages, which  
don't have "values" and require "and" and "or" to take booleans.

>> Failing that, would it be reasonable to define "and" and "or" in  
>> such  a way that if they appear other than in function-call  
>> position, they  evaluate to a function that does the right thing,  
>> so again they could  be passed around as functions?
>
> Something like:
> [snip]

Yes, that's pretty much what I had in mind, and that's exactly the  
issue I figured would come up.

> However it seems pretty messy to me <or> sometimes evaluating all  
> <arguments> and sometimes just as many as needed. Why not stick to  
> and and or as special forms and use regular functions with slightly  
> different names (like andf and orf) where a function is wanted  
> (implying that all their arguments are evaluated)

Yes, that would be messy.  But is it messier than saying "or" can be  
used in function-call position, but it can't be used AT ALL in  
function-argument position?

For my first-semester, non-CS-major students, it would be nice to be  
able to use "or" and "and" as arguments to "map" or "foldr" or  
something like that.  In ISLL, they shouldn't run into situations  
where short-circuit evaluation makes a significant difference (unless  
one of the arguments is a function call that goes infinite).   
Particularly since, by the time you've constructed a "list" of these  
things in order to use "map" or "foldr", all the elements of the list  
have already been evaluated anyway.


Stephen Bloch
sbloch at adelphi.edu