On Sep 14, 2009, at 8:15 PM, Brian Harvey wrote:

>> 3. `begin' at the REPL should behave as if the body forms were  
>> entered
>> individually at the REPL.
>
>> My suggestion is that property #3 should be sacrificed
>
> No!
>
> Aside from the fact that the REPL is more important than R6 programs,
> there is another issue, which is that all these difficulties seem to
> come (to me anyway, reading the discussion) from an emphasis on macros
> over plain old procedure calling.  And screwy macro calling at that!
> I think this is the tail wagging the dog.
>
> Scheme-without-macros is jewel-like.  Adding macros to Scheme is okay
> to the extent that it makes Scheme a more brilliant jewel, but not if
> it breaks the jewel-like-ness of the original.  Part of the brilliance
> of Scheme-without-macros is that the user can have a really simple
> mental model of how evaluation works.

This isn't about evaluation. It's about expansion order and scoping  
rules. The evaluation order remains left to right in `begin' forms.  
Nobody has proposed changing that.

For those who are not using macros (or using them in non-"screwy"  
ways), the *only* change that this causes is that:

(begin
   (define a 1)
   (define a 2)
   a) -> error, duplicate binding of `a' in `begin'

And isn't it nice that your implementation will detect when you try to  
define the same variable twice in the same `begin' form at the REPL?  
This is the same error you'd get if you'd tried to do this in a  
`lambda' form too.

If you're not interested in doing interesting things with syntactic  
abstraction, well, nobody will take R4RS Scheme away from you. I *am*,  
especially as it relates to module systems, and so I think it's  
important to get these details right. Right now it's difficult to get  
a grasp on what exactly `begin' means in various different contexts.  
It can mean:

* Just splice the body into the top-level. Mutual recursion in  
procedure definitions just kind-of works, because implementations tend  
to treat closing over a not-yet-defined variable as not an error.  
Ditto for mutually recursive syntax definitions.
* R6RS internal define / library form rules. Mutual recursion among  
multiple variable and syntax definitions; expressions can't be mixed  
with definitions.
* R6RS top-level program rules. Expressions can be mixed with  
definitions.

I'd like to see everything (`begin' at the REPL, internal definitions,  
and library bodies) go to the top-level program rules. This way we  
have maximum consistency. If you don't like the additional  
expressivity, don't use it.

--
Brian Mastenbrook
[email protected]
http://brian.mastenbrook.net/

_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to