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

For using syntacic keywords as first argument to things like map and fold, you need a quite different approuch to special forms. I 
think it is possible, but it would require expansion of special forms at run time, which has been avoided in  R6RS. For good reason, 
for making hygienic transformers that act at run time is pretty nasty. I have done some experiments with this approach, but I have 
not seen any good reason for them. For example ((if test let* let) ((var value) ,,,)) can be implemented if the values of syntactic 
keywords are defined at run time and the forems are expanded at run time. However, this would mean that much code has to be compiled 
at run time. I don't think that is a solution we are looking for. A compiled program should be a compiled program, not a program 
that has still to be compilled (partially).when running.
Jos

----- Original Message ----- 
From: "Stephen Bloch" <sbloch at adelphi.edu>
To: "Jos Koot" <jos.koot at telefonica.net>
Cc: "PLTScheme List" <plt-scheme at list.cs.brown.edu>
Sent: Thursday, December 10, 2009 8:47 PM
Subject: Re: [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
>
>