[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] ANN: first draft of R7RS small language available
- To: Alex Shinn <alexshinn@x>
- Subject: Re: [Scheme-reports] ANN: first draft of R7RS small language available
- From: Andre van Tonder <andre@x>
- Date: Sat, 16 Apr 2011 22:00:49 -0400 (EDT)
- Cc: scheme-reports@x
- In-reply-to: <BANLkTi=7N-mRVJ_ZDyHp7C+XxJZS4hgf4A@mail.gmail.com>
- References: <BANLkTi=hSfKrHo13BUMP==SNPCX-+As0HQ@mail.gmail.com> <BANLkTi=kSqWZpF-fAPObreiuAf9FxPb85w@mail.gmail.com> <BANLkTik2QF-u=58SLtQDTTWnx6htQxhqXA@mail.gmail.com> <Pine.SOC.email@example.com> <BANLkTi=7N-mRVJ_ZDyHp7C+XxJZS4hgf4A@mail.gmail.com>
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
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.
Scheme-reports mailing list