On Mon, Jan 7, 2013 at 8:28 PM, Andy Wingo <[email protected]> wrote: > On Sun 06 Jan 2013 19:56, Peter Bex <[email protected]> writes: > > > The second form in the following returns 1 in Chibi, Chicken, Gambit, > > MIT Scheme and Gauche: > > > > (define else #f) > > (cond (else 1)) > > Q: Why is this? A: Because all identifiers are present in the initial > environment in these implementations, so "define" is really "set!" > here. Therefore the "else" that is here is the same as the "else" that > the "cond".
This is not true of Chibi. Also, the test is broken - it only works in Chibi (and Chez) in the repl. Separate modules preserve hygiene. Also, I don't think people realize how broken the whole situation is, so I'm going to elaborate. There are basically two things you may be trying to do when matching an identifier - match a binding or match that identifier by name. For an example of matching bindings hygienically, the (outdated) http://synthcode.com/scheme/fast-math.scm uses a term optimization library to rewrite arithmetic expressions more efficiently at compile time. It does this by matching on patterns of `+', `-', `*' and `/'. It would in general be broken to attempt to rewrite these if they weren't the right bindings. Hygienic matching is also necessary for the more fancy syntax-rules tricks like checking if a pattern is a symbol or testing set membership. Almost all DSLs, however, fall into the latter case. I have an unpublished macro that lets you match alternate SREs in a cond-like pattern, and traces the statically named submatches within the SRE, binding them as local variables in the corresponding clauses. SchemeQL, SCSH's run syntax, the portable match.scm, and define-record-type to name a few fall into this category. There's no ambiguity and no reason to rename or worry about hygiene for these identifiers. So in the upcoming R7RS community, how am I to distribute my portable SRE macro? I'm being told to bind every SRE identifier to something and export it from the library. Many of these are already in (scheme base) like `or' and `*', including some new "shared auxiliary syntax ones" like `=>', while others I'll need to define specially like `:' and `?'. Hmmm... those are very common identifiers in DSLs - do I want them to belong exclusively to the SRE library? A local solution I'm seriously considering is to create a (chibi auxiliary-syntax) library, and whenever I need to create a new auxiliary syntax for some library to add it to that. Obviously this doesn't scale to actually sharing code with other people, which was sort of the whole purpose of this standard. The solution some suggest is just to using renaming. Thus usually SREs use `:' and `?', but when I also happen to be using the (foo bar) library which uses those identifiers I have to rename them to `::' and `??'. That also doesn't scale, making it impossible to remember. I could try to prefix the SRE identifiers consistently, e.g. `rx:' and `rx?', except oops, the underlying SRE engine doesn't know these names! Now we're at an impasse - it's simply impossible to reconcile the macro extensions to the DSL with the underlying unhygienic symbol language. Really, when you want to wrap macros on top of a non-macro-based DSL, the only solution is to use unhygienic matching. But there's no way to do this with syntax-rules, which is all we have in both R5RS and R7RS small. This is a SERIOUS problem. I'm still unaware of any halfway decent solution, and although I don't think we're without hope, I'd appreciate it if people stop putting their head in the sand and pretending there isn't a problem here. [Now, as a footnote, the example people always use when discussing this is `cond', which is unfortunate because cond is a special case. Cond really, really wants to just match `else' unhygienically but it can't because it has an ambiguous syntax. So it's a sort of rare hybrid case, which for lack of a better alternative we need to treat hygienically, but it's unproductive to dwell too much on it.] -- Alex
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
