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

Re: Suggestions and EIOD update

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



The eiod-based reference implementation says:

  ;; eiod.scm: eval-in-one-define
  ;; $Id: eiod.scm,v 1.2 2004/11/07 17:32:23 campbell Exp $

If you want to add your own version information, that's fine, but
please do not put anything out on the net that only identifies itself
as eiod 1.2, unless it is the petrofsky.org eiod 1.2, which is dated
2002/05/21 and is quite different from what you have there.  I suggest
you add something like this:

  ;; The rest of this file is eiod.scm version 1.16 from
  ;; http://petrofsky.org/src

Please make a similar change in alexpander (also, I suggest you fetch
a more recent version of alexpander).

Campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote in message
<Pine.LNX.4.44.0411070951080.1365-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
(which doesn't seem to have made it to schemers.org yet, but of which
I received a carbon copy):

> >   ... The macro system must make the usual hygienic arrangements
> >   to preserve the lexical scoping of these bindings.
> 
> OK, I've changed the text to look a bit more like this.

Draft 1.3 says:

  ... The macro system implementation must make usual hygienic
  arrangements to preserve & protect the lexical scope of these
  bindings.

I think "usual" needs to be "the usual" or "its usual".  Perhaps
better would be "... must make the hygienic arrangements described in
r5rs section 4.3 to preserve ...".

I'm not sure what "to preserve & protect" adds over "to preserve".  I
was echoing the r5rs wording, which is "preserve Scheme's lexical
scoping".  "To preserve & protect" does have a nice law-and-order feel
to it, should the scheme police be looking for something to inscribe
on their cruisers.

> > Here's an example you could use, whose result depends on whether or
> > not F inserts the binding for ::: hygienicly:
> > 
> >   (let-syntax
> >       ((f (syntax-rules ()
> > 	    ((f e)
> > 	     (let-syntax
> > 		 ((g (syntax-rules ::: ()
> > 		       ((g (x e) (y :::))
> > 			'((x) e (y) :::)))))
> > 	       (g (1 2) (3 4)))))))
> >     (f :::))
> >   => ((1) 2 (3) (4))    [ rather than ((1) (2) (3) (4)) ]
> 
> I have added this example.

You added it like this:

  (let-syntax
      ((f (syntax-rules ()
	    ((f ?e)
	     (let-syntax
		 ((g (syntax-rules ::: ()
		       ((g (??x ?e) (??y :::))
			'((??x) ?e (??y :::))))))
	       (g (1 2) (3 4)))))))
    (f :::))

      ; => ((1) 2 (3 4)), if hygienic rules of ellipsis identifiers are
      ;      correctly implemented, not ((1) (2) (3) (4))

You need to change that to "not ((1) (2) (3 4))", or (preferably) to
follow my example more closely and change '((??x) ?e (??y :::)) to
'((??x) ?e (??y) :::) and change "=> ((1) 2 (3 4))" to "=> ((1) 2 (3)
(4))".

> > I think the "tail patterns" feature would also benefit from at least
> > one example expression, which should explicitly include the concrete
> > result you expect.  Here's one:
> > 
> >   (let-syntax
> >       ((foo (syntax-rules ()
> > 	      ((foo x y ... z) (list x (list y ...) z)))))
> >     (foo 1 2 3 4 5))
> >   => (1 (2 3 4) 5)  
> 
> I think this example isn't really necessary; there already is one --
> FAKE-BEGIN -- which I think suffices.

I like the expanded discussion of fake-begin, but I still think you
should have *at least* one example in the r5rs 1.3.4 format of
"<expression> => <value>", which allows people to cut and paste
<expression> into a repl and see <value> printed, and also allows them
to easily add the expression (equal? <expression> '<value>) to a test
suite and expect it to evaluate to #t.

-al