Email list hosting service & mailing list manager

Re: Opaque syntax objects Andre van Tonder (12 Aug 2005 21:24 UTC)
Re: Opaque syntax objects Jens Axel Søgaard (13 Aug 2005 00:10 UTC)
Re: Opaque syntax objects Andre van Tonder (13 Aug 2005 00:51 UTC)
Re: Opaque syntax objects Jens Axel Søgaard (14 Aug 2005 20:08 UTC)
Re: Opaque syntax objects Andre van Tonder (14 Aug 2005 20:49 UTC)
Re: Opaque syntax objects Jens Axel Søgaard (14 Aug 2005 21:16 UTC)
Re: Opaque syntax objects Andre van Tonder (13 Aug 2005 02:35 UTC)
Re: Opaque syntax objects Jens Axel Søgaard (14 Aug 2005 20:37 UTC)
Re: Opaque syntax objects Michael Sperber (13 Aug 2005 07:51 UTC)
Re: Opaque syntax objects [course positions] Per Bothner (14 Aug 2005 06:19 UTC)

Re: Opaque syntax objects Andre van Tonder 12 Aug 2005 21:24 UTC

 Hi Mike, thanks for the comments.

 > I'd like to suggest that compound expressions be represented by an
 > opaque type rather than by pairs.  This would ensure a modicum of
 > abstraction, and would *really* make comprehensive the ability of all
 > syntax objects to carry location information.

 The current representation does allow source tracking for compound syntax
 objects.  One would make the reader put the location of each node (pair or
 vector) in a hash table.  Each evaluation of a SYNTAX or QUASISYNTAX form
 can do likewise.  Since pairs keep their identity during expansion,
 location information for every node (and identifier leaf) can always be
 looked up in the hash table at any stage of the expansion.

 > I've come to appreciate
 > this added layer of abstraction in PLT Scheme.

 Would you object to having compound syntax objects be specified as
 a subtype of lists, so that we can use car/.../cddddr/map/.../member/...
 as generic operations on them?  Is there something you find useful
 that such a design would prevent?

 As a subtype, it would have extra operations to, for example, inspect
 the source location.  A precedent for this kind of design exists in the
 R%RS numeric types, where an operation such as |remainder| is specified for
 integers but not reals (like our source location operation), while other
 operations such as + are generic (like our car/cdr).

 Since we are talking about a Lisp where programs can be mapped to lists,
 there should be a very good reason not to take advantage of the
 ability, which comes for free, to reuse all the builtins and large corpora
 of library list operations on syntax objects.  Making syntax objects
 disjoint from lists would throw this away.  Is there something sufficiently
 major that can be gained that would justify this?

 As we know, subtyping can be thought of in terms of implicit coercions.
 The alternative is having explicit coercions as in PLT, the
 use of which quickly becomes tedious when expressing simple things like

    (apply append stx))

 which would become, with coercions:

   (with-syntax ((result (apply append (map syntax->list (syntax->list stx)))
     (syntax result))

 although notice that even PLT does an implicit type conversion
 list->syntax-object to the result of evaluating (apply (map ....)).

 (As an aside, I suspect enough of these kinds of coercions can make a linear
 algorithm exponential.)

 Cheers
 Andre