On Mon, Apr 18, 2011 at 11:48 PM, Andre van Tonder <andre@het.brown.edu> wrote: > > As someone who has implemented the R6RS macro and module system > (in a form of explicit renaming system no less), it is clear to me from > this and other remarks that you and perhaps others on the WG don't > quite appreciate the technical ins and outs of implementing macros > and modules in a mutually consistent way. Sigh. It's amazing how quickly Schemers resort to argument from authority. > I would therefore STRONGLY advise that, before you continue work > on the module and macro system, you do a reference implementation > first and foremost. As announced in the post, Chibi is a reference implementation of the entire report (modulo some naming, and also modulo the I/O system which is still under minor contention, but was taken directly from Gambit). We considered proof of implementability essential before deciding on anything. I happen to be the author of Chibi, so I do know a thing or two about module systems and macros, but that's irrelevant. Figuring out who knows more isn't interesting to me. All I'm concerned with is making the best report possible, and that requires actually thinking out all the alternatives and implications of every decision. If this means I have to play devil's advocate and ask the stupid questions that no one else is asking and look like a fool in the process, so be it. We're getting lost in the details on the individual points, and they pretty much all hinge on the one real question - are imported values required to be the "same" binding in terms of the syntax-rules pattern language? This is http://trac.sacrideo.us/wg/ticket/157, so we'll be voting on it in the next ballot. If it really is so obvious then giving a reason should have been easy. Since you didn't give a reason I'm going to have to try to provide both sides of the argument. As a bit of background, the absolute most important goal in my opinion is that as many implementations as possible are able to implement the standard and write and share modules. I'm willing to sacrifice features in the standard if it means more implementations can be supported, so long as it doesn't _prevent_ those features from being implemented in a robust implementation. This is why the module system is deliberately vaguely specified. So given this status quo, we can consider the pros and cons of binding keywords: (1) Pro: In some cases it may be possible to provide earlier or more descriptive error messages. Con: You need to import all of the keywords used, and list them explicitly if using "only". Con: Keywords aren't guaranteed to actually match outside of the (scheme) module. And if we don't bind the keywords: (2) Pro: No need to import keywords explicitly. Pro: Multiple unrelated modules can use the same keyword, and both of those modules can be used by a third-party module without needing to rename the keywords. Con: May lose some opportunities for earlier or more descriptive error messages. Con: Must rename any imported identifier that conflicts with a keyword (i.e. keywords you use must always stay unbound). Con: Chez may have to violate the standard on this point and bind the keywords anyway (with various ugly repercussions), or possibly match them unhygienically. Of course, in neither case can you portably rename keywords. There are some interesting points on both sides, but the "keywords aren't guaranteed to match" issue is pretty damning and basically breaks R5RS compatibility. If we don't require imported bindings to match, I think the only sane thing is to leave the standard keywords unbound. Robust implementations of course will make imported bindings match anyway, and may take advantage of this in their own modules. You weren't even considering this scenario, so let's look at what happens if we require imported bindings to match. First, the pros and cons if the keywords are bound: (3) Pro: In some cases it may be possible to provide earlier or more descriptive error messages. Pro: You can rename keywords. Con: You need to import all of the keywords used, and list them explicitly if using "only". Con: Some simple implementations may need to violate the standard and leave the keywords unbound (with various ugly repercussions), or possibly match them unhygienically. and if they are unbound: (4) Pro: No need to import keywords explicitly. Pro: Multiple unrelated modules can use the same keyword, and both of those modules can be used by a third-party module without needing to rename the keywords. Con: May lose some opportunities for earlier or more descriptive error messages. Con: Can't rename keywords. Con: Must rename any imported identifier that conflicts with a keyword (i.e. keywords you use must always stay unbound). So (1) is not even an option, and both (2) and (3) pose problems for some implementation techniques, so without weighing the pros and cons too heavily (4) stands out as possibly the safest option. It doesn't prevent more robust implementations from binding other keywords in non-standard modules, but if they want versions of cond, case, etc. which refer to bound (and thus renamable) bindings, they would have to provide them in a separate module. On the other hand, implementations for which (3) is a problem may not be worth supporting. That's a statement I'm _very_ hesitant to make, and some of the implementations we want to target don't have module systems and/or hygienic macros at the moment, so I want to look into this a little more. -- Alex _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
