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.
On Sun, 7 Nov 2004, Alcoholic Petrofsky wrote: > 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 Whoa! Sorry, I didn't even notice the RCS tag junk when I committed it to srfi.schemers.org -- the updating of it was automatic and completely beyond my notice. I'll fix that immediately. Please make a similar change in alexpander (also, I suggest you fetch > a more recent version of alexpander). ...and that too. > 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) Yes, my SRFI subscriptions are *really* screwed up. I pestered the editors about it a little while ago, but to very little noticeable effect. I never remember which SRFI lists I'm still subscribed to, so I just Cc them anyway and hope someone notices the email. > > > ... 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 ...". OK, I shall specify that further. > > > 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))". Whoops. I suspect that the opium I consumed earlier today for lunch dessert in the form of bearclaw-related foods may have something to do with this confusion. I'll fix this, too. > 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. OK, very well, I'll add that. After all these changes you have made to the SRFI, Al*, at both the levels of fundamental design and written content, I think you really deserve to be noted as one of the SRFI's authors; after all, I just started the SRFI and wrote some text, whereas you changed the main body of the SRFI to be CYOE and rewrote much of the significant text -- do you agree, and would you mind if I update the document to reflect this?