Email list hosting service & mailing list manager

The power of Lists Keith Wright (15 Aug 2005 03:14 UTC)
Re: The power of Lists Jens Axel Søgaard (15 Aug 2005 20:43 UTC)
Re: The power of Lists Keith Wright (16 Aug 2005 04:16 UTC)
Re: The power of Lists Michael Sperber (16 Aug 2005 06:19 UTC)
Re: The power of Lists Andre van Tonder (19 Aug 2005 13:35 UTC)
Re: The power of Lists Michael Sperber (20 Aug 2005 07:00 UTC)
Re: The power of Lists Andre van Tonder (20 Aug 2005 15:28 UTC)
Re: The power of Lists Andre van Tonder (22 Aug 2005 14:30 UTC)

Re: The power of Lists Andre van Tonder 22 Aug 2005 14:29 UTC

On Sat, 20 Aug 2005, Michael Sperber wrote:

> Andre van Tonder <xxxxxx@now.het.brown.edu> writes:

>> I think the cost is worth it.  It is a one-time burden on the implementor that
>> gives significant (in my experience) convenience to users in perpetuity.  The
>> cost is bounded but the savings over all user programs is potentially infinite.
>
> The same could be said for the opposite direction :-)

...in the sense that the number of useful utilities for syntax objects is
pretty much finite, and in the case of opaque objects can be provided once
and for all, if I understand correctly.

For what it's worth, let me point out to those who may not be familiar with it
that it is really easy to provide a fixed set of generic operations only at
compile-time in e.g. MzScheme.  Something like

(module compile-time mzscheme
   (provide (rename this:car car)
            (rename this:cdr cdr)
            ........)

   (define (this:car x)
     (if (pair? x)
         (car x)
         (syntax-case x ()
           ((h . t) (syntax h)))))

   ......
)

Then

   (require-for-syntax compile-time)

imports these operations only for compile time.

The problem with this is, of course, that this way only a fixed set of list
operations will work.  One way of accommodating this restriction in the SRFI
would simply be to specify this set of operations (say those from R5RS that
would make sense on syntax objects).

But if we are specifying a fixed set of operations, one might as well go in the
opposite direction, as you point out, and specify them as e.g.

    syntax-car, syntax-cdr, ......

on opaque syntax objects.  So I guess I agree with you there.

Andre