On 6/20/07, Felix Klock <pfr6rs at pnkfx.org> wrote:
>
> On Jun 20, 2007, at 8:06 AM, Sam TH wrote:
>
> > On 6/20/07, AndrevanTonder <andre at het.brown.edu> wrote:
> >> On Tue, 19 Jun 2007, William D Clinger wrote, quoting Jonathan Reese:
> >>
> >>> Define
> >>> [a b c] to be a special reader syntax for the four-element list
> >>> (*square-bracketed* a b c)
> >
> > This also requires that the various special forms defined in the R6RS
> > would need to specify if they allowed or required square brackets.
> > For example, if it was decided that cond required square brackets, it
> > would be much harder to port existing R5RS code to R6RS. If it was
> > decided the other way, the large quantities of code written currently
> > with square brackets could not be made to work with R6RS.
>
> Your use of the phrase "the other way" here was ambiguous; I infer
> that you meant "if it were decided that cond *disallowed* square
> brackets, the large quantities of code . . .", but note that there is
> the other interpretation of "the other way" (of "if it were decided
> that cond *allowed* square brackets") since you stated above that
> R6RS would need to specify between "allowed" or "required."
>
> The reality is that there are three choices here; the various special
> form would need to specify if they allowed, disallowed, or required
> square brackets.
You are entirely correct here - I left out the "allowed but not
required" possibility.
> I just wanted to make it crystal clear that if cond were specified to
> *allow* (but not require) square brackets (which is implementable as
> a syntax-rules macro under the proposal, if a bit ugly) under the
> proposal, then there is no portability problem, and there is no
> problem with the "large quantities of code written currently with
> square brackets."
>
> Furthermore, even if cond were not specified to allow (but instead
> require or even disallow) square brackets, I believe that under the
> proposal you would still have the freedom to write your own
> compatibility library that did allow square brackets and import cond
> from that library instead of the (r6rs) library.
>
> The only problem I can see with the proposal is that it does
> introduce a burden on the macro writer who wants to emulate the
> behavior that square brackets are synonymous with parentheses,
> because (I think) they must write several more clauses depending on
> how complex the pattern of their macro is. But then again, I imagine
> that someone could come up with a helper procedure for syntax case
> that would solve even this problem.
There are a few burdens here:
1. Every macro must document the places where square brackets are
allowed, required and prohibited as part of its interface. This is, I
think, the biggest problem.
2. Implementing "allowed but not required" is a pain (although
appropriate abstractions might be able to alleviate this).
3. It's impossible to specify (or even allow) use of [] as an
application form for any macro (or any function application) without
making [] just as "useless" as it is in the current draft.
4. Macro writers must anticipate all possible places where someone
might want to use [] as a part of their macro.
I expect that the combination of these burdens would lead to a
situation in which the current specification is implemented by
"cooperation" between macro authors and macro users, but with lots of
inconvenience.
--
sam th
samth at ccs.neu.edu
Received on Wed Jun 20 2007 - 11:28:53 UTC