[racket-dev] internal-definition parsing

In a sense you just want to change the 'fault blame' designation when 

 e/d ... 

moves from macro foo to macro bar so that bar isn't blamed. It is then
foo's job to ensure that the sequence isn't empty and foo is blamed when 
things go wrong. 

I suspect this can be solved in syntax-parse, too. 

-- Matthias



On Oct 13, 2010, at 8:34 AM, Matthew Flatt wrote:

> At Wed, 13 Oct 2010 08:23:09 -0400, Carl Eastlund wrote:
>> On Wed, Jul 7, 2010 at 12:23 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>>> Should an expression be required at the end? A `module', `unit', or
>>> `class' body can consist of just definitions. Similarly, if an
>>> internal-definition context ends with a definition, we could define the
>>> result to be `(void)', which is what the `block' form does.
>>> 
>>> I think it's better to require an expression at the end, partly on the
>>> grounds that the internal-definition block is supposed to return a
>>> value (unlike the body of `module', etc.) and partly to avoid making
>>> forms like
>>> 
>>>  (define (f x)
>>>   x
>>>  (define (g y)
>>>   y))
>>> 
>>> legal when they are almost certainly mistakes.
>> 
>> Macros constructing sequences of def-or-expr for implicit begin (as
>> found in let, lambda, parameterize, etc.) won't always know if the
>> sequence is empty or non-empty, and whether it is terminated by an
>> expression or definition.  If a begin-like sequence ends with a
>> definition, currently a macro must add an expression such as (void) to
>> follow it.  If it ends with an expression, the macro must *not* add
>> such an expression, because that changes the return value.  It would
>> be far more convenient if primitive forms worked with any sequence of
>> def-or-expr so that each wrapper macro did not have to implement its
>> own local-expand loop to figure out how the sequence ends, and as
>> always it is much nicer to write macros when sequences can be
>> zero-length.
> 
> How about the option of using `block' in the macro implementation,
> instead of allowing forms like `(let ())', `(define (h))', the `f' and
> `g' example above?
> 
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev