I somehow failed to get back to this before the release, and so the currently available version of Redex will produce syntax errors for such models. Lets hope it isn't too painful for people and if it is, we can maybe try to unfix it.
Robby On Tue, Dec 22, 2015 at 3:30 PM, William J. Bowman <w...@williamjbowman.com> wrote: > On Sun, Dec 20, 2015 at 08:42:25PM -0600, Robby Findler wrote: >> The reason the "E_1" and the "e_1" are treated differently is that the >> "e" is mentioned in "binding" position of the shortcut. That is what >> makes it special. Does this make sense? > Yes, thank you. > >> (Have a read of the paragraph >> in the redex docs for reduction-semantics that talks about shortcuts >> and let me know if it makes more sense now and, even better, if you >> have any suggestions for edits!) > > I read through the documentation at > http://pkg-build.racket-lang.org/doc/redex/The_Redex_Reference.html?q=reduction-relation#(mod-path._redex/reduction-semantics). > The closest paragraph I can see to talking about this seems out of date. > > "Each shortcut clause defines arrow names in terms of base-arrow-name > and earlier shortcut definitions. The left- and right-hand sides of a > shortcut definition are identifiers, not patterns and terms. These > identifiers need not correspond to non-terminals in language." > > Of course now, the last sentence requires s/need not/must not/. I would > also add a final sentence such as "Therefore, the output of the shortcut is > not checked against the syntax of any non-terminal." > >> What if I were to actually make it do what people seem to think it >> does, in the case that the chosen name is a non-terminal? So, if you >> write a shortcut whose name is NOT a non-terminal, say "x" then it >> would be like you wrote "any_x". And if you used a non-terminal, then >> the shortcut would apply only when the expression actually matches the >> corresponding non-terminal. Redex would still have to insist that the >> parameters to the shortcuts are identifiers, but I could add in that >> restriction? >> >> This is also backwards incompatible, but in a different way, tho. So >> that's slightly worrying. This form of backwards incompatibility has >> the downside that it will just make things stop reducing instead of >> getting a syntax error. So we'd have to like it a LOT to go this way. > The fact that it will cause previously good code to fail silently > is rather unacceptable. Although, I think this changed behavior is > preferable because it matches the behavior of much of the rest of Redex, > and matches what people seem to except. > > Perhaps a different syntax for this changed version of shortcut, and > deprecating the current version? > > -- > William J. Bowman -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
