[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Initial comments & questions



On Sat, 20 Mar 2004, Ken Dickey wrote:

> On Saturday 20 March 2004 04:06 am, Andre van Tonder wrote:

> >  Taylor Campbell wrote:

> > >   - SYNTAX-DO -- I don't like this at all.  It's not very descriptive
> > >     and it clashes with the DO syntax in regular Scheme.  While it may
> > >     be a good point that it does nothing more than 'do' a computation,
> > >     and this is also what Haskell uses, it still isn't descriptive to
> > >     just say 'do,' and it still has the clash.
> >
> > Understood.  I haven't been able to come up with a better name, though.
> 
> I would suggest SYNTAX-BIND, since binding is what it does, and picking a new 
> name for the current (internal) syntax-bind.

At first glance, binding is indeed what it does, but there are two
possible problems that I can see.  

First, in the monadic prior art, *bind* is already used for something more
akin to the current internal *syntax-bind*, so using bind for do could
cause confusion.  

Second, in e.g. Haskell, with *do* one can actually choose not to bind
results of intermediate computations when these are done for their side
effects.  Extending *syntax-do* in this ways could actually be very
useful, since this gives the perfect hook for adding certain things that
are currently impossible to do via syntax-rules such as warnings and
Taylor's debug messages.  For example:

  (syntax-do (x <- ......)
             (syntax-message "The intermediate result is:" x)
             (syntax-if (atom? x)
               (syntax-do (syntax-warning "Atoms may explode if split")
                          (y <- ......)
                          (syntax-message "y = " y)
                          (z <- ......)
                       .
                       . 
         
Note that this would be an argument for keeping both the current <- arrows
and the current indentation and bracketing.

I am thinking of adding a section, perhaps called "Requests for future
extensions" for currently impossible things that could perhaps easily be
supported in future.  I would include, for example,

   syntax-debug-message
   syntax-warning
   syntax-string?
   syntax-number?
   ...