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

Re: Opaque syntax objects

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



 Felix Winkelmann wrote:
 
 > On 8/12/05, Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
 > > 
 > > The issue has come up in the discussion, but hasn't really been in the
 > > focus yet:
 > > 
 > > 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.  I've come to appreciate
 > > this added layer of abstraction in PLT Scheme.
 > > 
 > 
 > But wouldn't this completely break the (IMHO) rather practical ability
 > to destructure arguments passed to macros via normal Scheme operators?
 > What I like about srfi-72 is that I can write hygienic macros with (nearly)
 > the same ease as in conventional Lisp-/quasiquote-style. 
 
 
 As a supporting data point, I was able to port the Scheme48 basic forms 
 (cond, case, etc. ...), as well as its syntax-rules implementation, a very
 nontrivial macro, with the greatest of ease to SRFI-72, without having to
 worry about converting cadddr's, null?'s, higher order list operations 
 such as map, every, ..., and so on.  I also did not have to worry that 
 some coercion might have changed the complexity class of the algorithm.