On 5/9/14, 11:29 AM, Alexander McLin wrote: > Do you mind expanding on what MTWT stands for? I'm not familiar with this > paper and am curious.
Macros that Work Together http://www.eecs.northwestern.edu/~robby/pubs/papers/jfp2012-fcdf.pdf > On Thu, May 8, 2014 at 6:20 PM, John Clements > <cleme...@brinckerhoff.org>wrote: > >> >> On May 8, 2014, at 3:00 PM, Ryan Culpepper <ry...@ccs.neu.edu> wrote: >> >>> IIRC, the typesetting of environment extension might suggest replacement >> in a mapping, but I believe it actually means 'cons' in an association >> list, and 'nostops' is one thing that relies on the latter implementation >> of the environment rather than the former. >> >> Ah… so the model does in fact have the “uncovering” behavior I expected it >> to. In this case, I think that the text of the paper is mistaken; it says >> >> nostops[xi] = {var -> transform | xi(var) = transform and transform != >> STOP } >> >> which certainly suggests to me that these mappings simply wouldn’t appear >> in the updated mapping. >> >> Amazing how ambiguous formal syntax can be. >> >> It seems like the right way to fix this would be to explicitly separate >> the environment xi into a mapping and a stop list—the ‘nostops’ definition >> would be trivial, but lookup in xi would get slightly uglier. Perhaps a >> footnote somewhere in the paper? >> >> Anyway, thanks for clarifying. >> >> >> >> John >> >>> >>> So an environment with 'lambda' in the stop list actually looks like >>> >>> ((lambda STOP) (lambda FUN)) >>> >>> so when 'nostops' filters it, it produces >>> >>> ((lambda FUN)) >>> >>> and the previous meaning of 'lambda' is restored. >>> >>> Ryan >>> >>> >>> On 05/08/2014 04:58 PM, John Clements wrote: >>>> I’m reading through MTWT for the nth time, and this time I have a >> question about the ‘nostops’ metafunction, part of local expansion. >>>> >>>> Specifically: ‘nostops’ takes an environment xi, and strips out >> everything bound to 'STOP’. This prevents the ’STOP’s from an enclosing >> local expand from being in force in this one. However, it seems to me that >> the ’nostops’ metafunction should restore the bindings that were in place >> before they were mapped to STOP. More specifically; suppose a local-expand >> specifies, say, ‘lambda’ as a STOP. This replaces the mapping from ‘lambda’ >> to FUN with a mapping from ‘lambda’ to ’STOP’. Then, a nested local-expand >> uses a different stop-list, that doesn’t include ‘lambda’. If I’m reading >> the paper correctly, this local expansion would then take place in a ‘xi’ >> where there was no binding for lambda at *all*, which would presumably lead >> to an error during that expansion. >>>> >>>> I checked out the model, to see if this was a typesetting issue, but it >> seems pretty clear to me that the model linked to by the paper has exactly >> this property; it’s simply filtering the ‘xi’ environment to throw out >> things that were bound to STOP. >>>> >>>> I tried to construct a racket program to illustrate my question, and >> here’s what I came up with: >>>> >>>> #lang racket >>>> >>>> (let-syntax ([boring (lambda (stx) (cadr (syntax->list stx)))]) >>>> >>>> (let-syntax ([a (lambda (stx) >>>> (local-expand (cadr (syntax->list stx)) >>>> 'expression >>>> (list #'boring)))]) >>>> (let-syntax ([b (lambda (stx) >>>> (local-expand (cadr (syntax->list stx)) >>>> 'expression >>>> (list)))]) >>>> (a (b (boring 34)))))) >>>> >>>> Unsurprisingly, this evaluated to the “correct” value, 34. This means >> that either the model doesn’t match Racket, or (more likely) I’m >> misunderstanding the model. Or possibl >>>> >>>> Ah, what the heck; I’ll cc: the whole racket list. I’ll take help >> wherever I can get it :). >>>> >>>> John >>>> >>> >> >> >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users >> > > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users > ____________________ Racket Users list: http://lists.racket-lang.org/users
