[r6rs-discuss] [Formal] Reduce over-specification as well as under-specification.

From: Andre van Tonder <andre>
Date: Tue Nov 14 10:36:27 2006

I agree with almost all of the formal comment, but
I do have a minor quibble.

> Library phasing (section 6.2).
>
> The last paragraph of section 6.2 talks about what
> implementations are allowed to do, and states that
> "a portable library's meaning must not depend on
> whether the invocations are distinguished or
> preserved across phases or library expansions."
>
> That paragraph is an example of what I am asking
> the R6RS to do more consistently: It explains the
> programmer's responsibility. It also says that
> implementations have no obligation to implement
> many details of the phasing semantics that had
> been described by the previous 22 paragraphs of
> section 6.2.
>
> In other words, section 6.2 contains a complex
> specification that implementations are not required
> to implement, and on which programs cannot rely.
>
> Hence programmers must establish the correctness of
> portable libraries under the assumption that the
> phasing semantics is implemented, and also under
> the assumption that a single set of bindings is
> shared by all phases.
>
> It seems to me that the complex phasing semantics,
> on which libraries cannot rely but with which they
> must nonetheless be prepared to cope, hinders the
> development of portable libraries more than it helps.

I agree so far.

> One possible solution is for the R6RS to sketch only
> a vague semantics for phase levels, perhaps along
> the lines of the semantics given for declarations in
> section 9.22, instead of specifying so many details
> that implementations are explicitly allowed to ignore.

I am not sure I would agree with making it more vague,
though. As I have argued in a separate formal comment,
there are certain aspects of the phase semantics that are not
currently reliable but can easily be made reliable independently
of the "shared/separate bindings" issue. Where possible,
I think one should err on the side of more reliability
in the case of libraries, due to their novelty and
difficulty.

The problem with making things more vague is that, in the
case of libraries, it is already very easy to draw
inferences not justified by the "axioms" and thus
write non-portable code. Phases are already a little
mind-boggling, and users are likely to rely on some extent
on error reporting to gain some confidence of correctness and
portability. I do this myself. Removing the requirement of
each of these checks is guaranteed to open a separate Pandora's
box of non-portable code that works on one particular
implementation but not on all.

Additionally, some vaguenesses in the library
specification lead to irreducible loss of expressivity.
For example, the current specification does not allow
one to express "identifier-syntax" as a derived form.
Here libraries are different from lists, for example,
where vaguenesses in the specification do not lead to
loss of expressivity.

Andre
Received on Tue Nov 14 2006 - 10:35:51 UTC