The idea to have the reader treat [...] as shorthand
for (**square-brackets** ...) is a nice one. It points the
way to something even more general.
How about:
(define (x a b) (sqrt {a^2 + b^2}))
or
(define msg
#'<p>
<i>Every</i> good syntax has its place, even if there glitches like
having to add quirky escape syntaxes like "'&;#" (spelled "'&;#"
in the source for this document).
</p>'#)
being read to the simple s-exp form of their obvious trees?
The language theorists have given us a careful distinction
between surface and abstract syntax but this distinction is
only halfway fleshed out: We've got mechanisms
such as syntactic closures so that abstract syntax can be
variable yet lexically apparent. Perhaps we want a mechanism
of "surface syntax closures" so that surface syntax can be
variable yet lexically apparent.
If newly defined extensions to surface syntax are reliably
defined in terms of expansions to simple "classical" s-exps
(representing terms in an abstract syntax) then people could
define things like infix math notation or XML notation
independently of choosing any particular interpretation --
interpretations would then be orthogonally determined
by the (abstract) syntax lexical context.
It's a really excellent suggestion, Jonathan.
-t
Jonathan A Rees wrote:
> (If someone else would care to turn the below into a formal comment
> and/or SRFI, to be submitted under my or another name, I would
> be delighted; and in fact if no one wants to go
> to that effort that speaks poorly of the idea and it should probably
> drop. I am sorry but I do not read r6rs-discuss very often so will
> not see followup unless you cc me. -Jonathan)
>
>
> There is a feud between a faction that wants to be able to enlist two
> distinct kinds of brackets to help beginners to learn Scheme, and/or
> to help anyone to write what they consider to be clearer code, and a
> faction that is horrified at the loss of 1/64 of the valuable ASCII
> character space for a purpose that to them isn't justified, preventing
> the use of brackets for legitimate extensions to Scheme.
>
> No one will change anyone else's mind, since this conflict has been
> raging unresolved since the 1970's.
>
> Here is a compromise that satisfies concerns on both sides. Define
> [a b c] to be a special reader syntax for the four-element list
> (*square-bracketed* a b c), just as '(a b c) is special reader syntax
> for the two-element list (quote (a b c)). By "*square-bracketed*" here
> I really do mean the symbol of that name (although it could be some
> other symbol).
>
> For example, it will make sense to define:
>
> (define-syntax let
> (syntax-rules (*square-bracketed*)
> ((let ([?var ?val] ...) ?body ...)
> ((lambda (?var ...) ?body ...) ?val ...))))
>
> if you want to require that let-bindings be written using square
> brackets, or
>
> (define-syntax let
> (syntax-rules (*square-bracketed*)
> ((let ([?var ?val] ...) ?body ...)
> ((lambda (?var ...) ?body ...) ?val ...))
> ((let ((?var ?val) ...) ?body ...)
> ((lambda (?var ...) ?body ...) ?val ...))))
>
> if you want to allow either syntax. If you want [a b c] to be an
> abbreviation for (list a b c), you can do
>
> (define *square-bracketed* list)
>
> and so on.
>
> Note that this improves on synonymizing [ ] with ( ) for teaching
> purposes in that it enables error checking - in every syntactic
> position, you can enable or disable either kind of parenthesis
> selectively.
>
> The same kind of thing could also be done with curly brackets, using a
> different marker. (N.b. the Unicode names for the characters are LEFT
> and RIGHT SQUARE BRACKET and LEFT and RIGHT CURLY BRACKET.)
>
> WRITE could be made to generate [...] on output.
>
> If I remember correctly, we did something like this for T (Yale
> Scheme) in about 1983 or 1984, but I don't remember it being used.
> Perhaps the feature was undocumented or experimental.
>
> You may very well object that this is unhygienic - that the fact
> that the name *square-bracketed* is free in [...] is in poor taste.
> But I will point out that this is already true of quote (we all
> ignored Brian C Smith way back when). The proposal is a
> compromise, and the question is whether the benefits of its
> peacekeeping effect compensates for the embarrassment it causes.
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss at lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
>
Received on Fri Jun 15 2007 - 16:51:12 UTC