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

Re: Initial comments & questions

This page is part of the web mail archives of SRFI 53 from before July 7th, 2015. The new archives for SRFI 53 contain all messages, not just those from before July 7th, 2015.

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,