On Sun, 17 Apr 2011, Alex Shinn wrote:
On Sun, Apr 17, 2011 at 2:09 AM, Andre van Tonder <andre@x> wrote:- There is a very strong argument for requiring these literals to be bound. If they refer to bindings, they can be exported, imported, prefixed, renamed, or excluded. These are useful operations, and I think it is important for users to be able to rely on them to work portably.This and most of your arguments confused me greatly for a while, because a different identifier should never match a syntax-rules literal. Then I realized you're assuming that any imported binding from another module should count as having the "same lexical binding," not simply be bound to the same value, in which case they would match. The module system does not make this requirement, in deference to the many types of module systems out there which may simply copy the bindings, so in general you can't assume you can rename =>.
I don't understand what you mean. I want => to be bound (to a macro that expands to an error message). So it does have a specific binding in the exporting module, and can therefore be renamed, excluded, translated into another language, etc. This should work in any module system that allows exporting and renaming identifiers, shouldn't it?
- We cannot easily create a teaching language where => clauses are not allowed in COND unless => is bound.Sure you can, just bind =>.
It is not the same. For example, I may want COND without =>, AND I may want => to be free so that my users can do with it what they want. For your solution to work, the user of your little language will have to import both COND and => from your library just to obtain a simpler =>-less COND, and then depending on the module system they may be prevented from redefining => for their own purposes.
COND seems a silly example - if you want a more useful example think about reproducing R5RS underscore-less SYNTAX-RULES. With your solution, the user importing your R5RS module will have to import your redefined underscore to get the underscoreless R5RS syntax-rules, which seems rather silly.
There is no free-identifier=? in WG1 Scheme, nor at the present time is there likely to be in WG2 Scheme.
There has to be something like that in the machinery of the macro system, because this is the comparison operation Scheme uses to identify the meaning of ANY lexical binding.
- Typically, such literals mcan be bound to a macro expanding to a syntax error, which is extremely useful for error checking.If they are unbound we also get a descriptive error.
No you would not always. As an example, consider what happens if a user binds UNQUOTE in his code. Suddenly a quaisquote expression that used to work may now have (UNQUOTE ...) subexpressions left over. If UNQUOTE is bound to an error message macro, this problem will throw an error at expansion time. IF not, you will have to wait until runtime and then get a generic unbound identifier error instead. Also, consider what happens if you leave => unbound and a user accidentally binds => (a rather common math symbol) in his code. Suddenly COND expressions will start malfunctioning in mysterious ways. However, if => were bound in the COND-exporting library, then at least the importing module can throw a redefinition error (or warning if you would like to allow redefinitions) to make the user aware of the problem.
- A lot of these literals are common enough names that users are likely to stop on them by accident. Fi they are bound, the expander will thorw an redefinition error.Not if they are locally shadowed, ...
These kinds of problems tend to rear their head in my experience mostly in the case of toplevel shadowing. People tend to be more careful with local shadowing and local bindings are just that, local, which means that you can easily scan for them, as opposed to toplevel bindings that may be pages away or in another module. I've done accidental toplevel shadowings that made code malfunction in (to me) mysterious ways, so although I am fine with redefinition, warning messages are in my experience extremely useful.
Andre
_______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports