Re: [Scheme-reports] ANN: first draft of R7RS small language available Andre van Tonder (17 Apr 2011 02:02 UTC)
[Scheme-reports] DELAY AND FORCE Andre van Tonder (23 Apr 2011 22:20 UTC)
[Scheme-reports] Regions of imports unspecified Andre van Tonder (23 Apr 2011 22:31 UTC)
Re: [Scheme-reports] Regions of imports unspecified John Cowan (23 Apr 2011 22:43 UTC)
Re: [Scheme-reports] Regions of imports unspecified Alex Shinn (24 Apr 2011 01:59 UTC)
[Scheme-reports] What are regions of toplevel imports? Andre van Tonder (23 Apr 2011 23:41 UTC)
[Scheme-reports] Internal syntax definition order problem Andre van Tonder (23 Apr 2011 22:39 UTC)
[Scheme-reports] Mutable exports Andre van Tonder (23 Apr 2011 22:48 UTC)
Re: [Scheme-reports] Mutable exports Alex Shinn (24 Apr 2011 02:00 UTC)
[Scheme-reports] Internal definition shadowing problems Andre van Tonder (23 Apr 2011 23:19 UTC)
[Scheme-reports] Importing identifier more than once Andre van Tonder (23 Apr 2011 23:37 UTC)

Re: [Scheme-reports] ANN: first draft of R7RS small language available Andre van Tonder 17 Apr 2011 02:00 UTC

On Sun, 17 Apr 2011, Alex Shinn wrote:

> On Sun, Apr 17, 2011 at 2:09 AM, Andre van Tonder <andre@het.brown.edu> 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@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports