Re: [racket-dev] internal-definition parsing

2010-10-13 Thread Carl Eastlund
On Wed, Jul 7, 2010 at 12:23 PM, Matthew Flatt mfl...@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.

--Carl
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] internal-definition parsing

2010-10-13 Thread Matthew Flatt
At Wed, 13 Oct 2010 08:23:09 -0400, Carl Eastlund wrote:
 On Wed, Jul 7, 2010 at 12:23 PM, Matthew Flatt mfl...@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

Re: [racket-dev] internal-definition parsing

2010-10-13 Thread Matthias Felleisen

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 mfl...@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

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] internal-definition parsing

2010-10-13 Thread Carl Eastlund
In the case I have, though, I want the sequence to be empty.  The
problem is that these bodies -- (let () ...), (parameterize () ...),
etc. -- are used for a lot of different things.  A macro may splice in
a sequence that is intended to represent definitions to bind in a
scope, expressions to evaluate for effect, expressions to evaluate in
order and return the last, mixed definitions and expressions, or
perhaps some other odd interpretation of the body sequence.

I have some RackUnit test cases that are currently empty as I have no
checks to put in them.  They're just placeholders.  Under the
planet-based SchemeUnit, this works fine.  Under RackUnit, it expands
into (parameterize ([stuff ...])), because there are no body
expressions.  This happens about 2-3 macros down from where I write
it.  We could start adding blame and possibly making various macros
add (block e ...), but really, why not just make it work?  It seems a
lot easier, and all it means is that you get in trouble if you forget
to write the body of your function.  That's not really that surprising
an error.  The (define (f) ... (define (g) ...)) bug Matthew
originally cited is fairly easy to debug, too.  Running into a problem
with nested macros imported from someone else's libraries is something
I'd much rather make easy.

Carl Eastlund

On Wed, Oct 13, 2010 at 10:02 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 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 mfl...@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


Re: [racket-dev] internal-definition parsing

2010-10-13 Thread Joe Marshall
On Wed, Oct 13, 2010 at 7:08 AM, Carl Eastlund c...@ccs.neu.edu wrote:
 In the case I have, though, I want the sequence to be empty.  The
 problem is that these bodies -- (let () ...), (parameterize () ...),
 etc. -- are used for a lot of different things.  A macro may splice in
 a sequence that is intended to represent definitions to bind in a
 scope, expressions to evaluate for effect, expressions to evaluate in
 order and return the last, mixed definitions and expressions, or
 perhaps some other odd interpretation of the body sequence.

This is the reason that I prefer a lot of lattitude in Scheme syntax.
There are forms that no human would write but that are marginally
legitimate and might be generated by a macro.  It is painful to try
to make every part of a complex macro expand into well-written
code.


-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] internal-definition parsing

2010-07-08 Thread Matthias Felleisen

On Jul 7, 2010, at 5:55 PM, Eli Barzilay wrote:

 Some examples that show how useful this is:
 
  * In the lazy language you want the implicit begin to force all
expressions except for the last one.
 
  * I've redefined the implicit begin (in an ugly way) for my course
language to force all non-tail expressions to have a `Void' type.
 
  * The scribble/text language should really return a list of all
values instead of just the last one.  It currently provides `text'
that builds on `begin/collect', which allows each block of
consecutive definitions to be mutually recursive -- this is now a
problem in that it's different in a subtle way than the default
implicit begin.
 
 I think that a good goal is to have all of these uses available as
 simple macro definitions.
 
 If you take the lazy use as an example, then just a single `#%body'
 thing is not enough: since it needs to force only expressions, then
 having a `#%body' means that it will need to do its own crawling over
 the expressions to find which ones are not definitions and force
 them.  So it looks like another special #% macro would be needed, and
 even that is not enough to implement the last one conveniently, since
 it needs to collect all non-definition expressions and combine them.


1. Three distinct examples (plus Algol, which could benefit too) sound like 
enough. 

2. I do not understand why #%body isn't enough. Couldn't #%body locally expand 
to the point where defs and exps are distinguished? 

3. Also, I am beginning to wonder whether the right name is #%block-begin of 
#%body-begin 

4. The next thing to consider is whether #%module-begin and #%block-begin are 
truly separate features. In a sense, we now should say that modules are just 
bodies. Or is there a difference? 

-- Matthias



_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] internal-definition parsing

2010-07-08 Thread Jay McCarthy
On Thu, Jul 8, 2010 at 11:19 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 On Jul 7, 2010, at 5:55 PM, Eli Barzilay wrote:

 Some examples that show how useful this is:

  * In the lazy language you want the implicit begin to force all
    expressions except for the last one.

  * I've redefined the implicit begin (in an ugly way) for my course
    language to force all non-tail expressions to have a `Void' type.

  * The scribble/text language should really return a list of all
    values instead of just the last one.  It currently provides `text'
    that builds on `begin/collect', which allows each block of
    consecutive definitions to be mutually recursive -- this is now a
    problem in that it's different in a subtle way than the default
    implicit begin.

 I think that a good goal is to have all of these uses available as
 simple macro definitions.

 If you take the lazy use as an example, then just a single `#%body'
 thing is not enough: since it needs to force only expressions, then
 having a `#%body' means that it will need to do its own crawling over
 the expressions to find which ones are not definitions and force
 them.  So it looks like another special #% macro would be needed, and
 even that is not enough to implement the last one conveniently, since
 it needs to collect all non-definition expressions and combine them.


 1. Three distinct examples (plus Algol, which could benefit too) sound like 
 enough.

 2. I do not understand why #%body isn't enough. Couldn't #%body locally 
 expand to the point where defs and exps are distinguished?

 3. Also, I am beginning to wonder whether the right name is #%block-begin of 
 #%body-begin

 4. The next thing to consider is whether #%module-begin and #%block-begin are 
 truly separate features. In a sense, we now should say that modules are just 
 bodies. Or is there a difference?

#%module-begin as the top level controlling macro is a distinguishing
feature. Requires and provides can only be there and you know there's
only one application.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

The glory of God is Intelligence - DC 93
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] internal-definition parsing

2010-07-08 Thread Matthias Felleisen

On Jul 8, 2010, at 12:09 PM, Jay McCarthy wrote:

 #%module-begin as the top level controlling macro is a distinguishing
 feature. Requires and provides can only be there and you know there's
 only one application.

These could be an argument to the #%...-begin macro: 

 are-you-top-level? :: (U false (interface Provides Requires))

-- Matthias


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] internal-definition parsing

2010-07-08 Thread Eli Barzilay
On Jul  8, Matthias Felleisen wrote:
 
 2. I do not understand why #%body isn't enough. Couldn't #%body
locally expand to the point where defs and exps are
distinguished?

Yes, it could -- and I guess that would be in analogy to
`#%module-begin'.  But I generally don't like that macros that need to
distinguish definitions from expressions need to do that work in that
context too -- it's delicate enough that it shouldn't be left to the
good enough instinct of leaving partial solutions.  (In the
`#%module-begin' case, a common result of this instinct is matching on
expressions that use `define', without expanding them, or expanding
them without dealing with macros.)


 3. Also, I am beginning to wonder whether the right name is
#%block-begin of #%body-begin
 
 4. The next thing to consider is whether #%module-begin and
#%block-begin are truly separate features. In a sense, we now
should say that modules are just bodies. Or is there a
difference?

It could be the same macro with (syntax-local-context) distinguishing
the two...  It might even make sense to do so in some cases where a
similar macro is needed in both (as with the lazy case).

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] internal-definition parsing

2010-07-08 Thread Eli Barzilay
On Jul  8, Matthias Felleisen wrote:
 On Jul 8, 2010, at 12:09 PM, Jay McCarthy wrote:
 
  #%module-begin as the top level controlling macro is a distinguishing
  feature. Requires and provides can only be there and you know there's
  only one application.
 
 These could be an argument to the #%...-begin macro: 
 
  are-you-top-level? :: (U false (interface Provides Requires))

(It could also be an argument for making local requires more
accessible...)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] internal-definition parsing

2010-07-07 Thread Eli Barzilay
On Jul  7, Matthew Flatt wrote:
 Short version:
 
 I'm planning to change internal-definition expansion (anywhere that
 says `body ...' in the Racket documentation) to allow expressions to
 mingle with definitions. For example,
 [...]

Nice!


On Jul  7, Matthias Felleisen wrote:
 
 4. I am vaguely interested in #%body because I have a hunch that
there are yet more possibilities. But at the same time, I
understand your objection and I can only see a limited utility of
#%body now. (That doesn't mean much, because I originally failed
to appreciate #%module-begin.)

I have a very conceret interest in that.  Is there any concrete
example for something that would go wrong with it now?

What bugs me often is that playing around with a different semantics
for body sequences is currently very tedious -- I have to redefine
`lambda', `let', `define', and their (many) relatives (even things
like `for' etc, if it should be complete), and in practice it always
ends up being a half-assed job instead...

Some examples that show how useful this is:

  * In the lazy language you want the implicit begin to force all
expressions except for the last one.

  * I've redefined the implicit begin (in an ugly way) for my course
language to force all non-tail expressions to have a `Void' type.

  * The scribble/text language should really return a list of all
values instead of just the last one.  It currently provides `text'
that builds on `begin/collect', which allows each block of
consecutive definitions to be mutually recursive -- this is now a
problem in that it's different in a subtle way than the default
implicit begin.

I think that a good goal is to have all of these uses available as
simple macro definitions.

If you take the lazy use as an example, then just a single `#%body'
thing is not enough: since it needs to force only expressions, then
having a `#%body' means that it will need to do its own crawling over
the expressions to find which ones are not definitions and force
them.  So it looks like another special #% macro would be needed, and
even that is not enough to implement the last one conveniently, since
it needs to collect all non-definition expressions and combine them.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev