[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Scheme-reports] Please make internal BEGIN a splicing form
- To: scheme-reports@x
- Subject: [Scheme-reports] Please make internal BEGIN a splicing form
- From: Andre van Tonder <andre@x>
- Date: Sun, 24 Apr 2011 11:51:59 -0400 (EDT)
On Sun, 24 Apr 2011, Jussi Piitulainen wrote:
> There are at least three other (begin <something> ...) forms in the
> language now: 5.1. specifies a splicing program-level begin where
> <something> can be any form, 5.2.2. specifies a splicing (begin
> <definition1> ...) that can occur whereever an internal definition
> can, and 5.5.1. specifies the module form (begin <command or
> definition> ...). None of these are expression types.
Plus the (at least) two types of BEGIN in bodies, one for splicing
definitions and syntax definitions (or maybe two different ones if
they cannot be together) as well as the BEGIN that sequences
expressions that can be a macro.
This is utter chaos.
Why can't internal BEGIN be a splicing form as in R6RS? There is
no good reason why
(begin (define-syntax .....)
shouldn't work fine. Even if we don't program like this explicitly,
this kind of thing often comes up as the result of macro expansion.
If internal BEGIN is not a splicing form, it often happens that macros
that work fine at the top level suddenly don't work when used internally.
An example would be a DEFINE-RECORD-TYPE implementation that expands to
syntax definition, a definition, and initializes an internal table.
It is very easy to implement a splicing internal BEGIN, so there is no
technical reason for the reastrictions, whcih contradict the spirit of
the very first sentence of the report:
Programming languages should be designed not by piling
feature on top of feature, but by removing the weaknesses
and restrictions that make additional features appear necessary.
In this spirit, my request is to please make internal BEGIN a general
Scheme-reports mailing list