[R6RS] Comments from the public
Marc Feeley
feeley
Tue Nov 23 14:00:53 EST 2004
Hi. After the first progress report was posted by Mitch Wand, some
comments from the public were sent to Mitch Wand and Guy Steele. I'm
forwarding them to the R6RS list so that you can be aware of them.
I told Mitch and Guy that in the future it would be best to direct
the public to the SRFI process if they want the editors to be aware
of a specific proposal. Do you think we should be more open to
comments?
Marc
------------------------------------------------------------------------------
Date: Wed, 20 Oct 2004 17:37:24 -0400
From: Guy Steele <Guy.Steele at Sun.COM>
Subject: Comments about Scheme from Jonathan Shapiro
To: feeley at IRO.UMontreal.CA
Cc: alan at bawden.org, wand at ccs.neu.edu
Reply-To: Guy.Steele at Sun.COM
Organization: Sun Microsystems Inc.
X-Accept-Language: en-us, en
X-DIRO-MailScanner-Information: Please contact the ISP for more information
X-DIRO-MailScanner: Found to be clean
X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0,
requis 5)
X-MailScanner-From: guy.steele at sun.com
Marc,
I received some comments about Scheme from Prof. Jonathan Shapiro
and I am forwarding them to you, with no recommendation pro or con
from me. I am doing this not in my capacity as a member of the
Scheme Steering Committee, but simply as someone who happens to
know that you are the Editor in Chief and therefore the right person
to whom to forward such comments.
(Sorry to seem so stiff---I'm just trying to be clear for the record.
Keep up the good work.)
--Guy
Jonathan S. Shapiro wrote:
> On Thu, 2004-10-14 at 11:44, Guy Steele wrote:
>
>>CLTL2 was nailed down before the rise of Unicode...
>
>
> Since I note that you are on the R6RS working group, may I suggest that
> the absence of any method to specify character literals by code point
> should go on the list of things to be addressed?
>
> Also, could you pass along my observation to the group that the
> definition of characters in R5RS is unacceptably fuzzy in general. For
> example, section 6.3.5 of R5RS defines strings as character sequences
> contained within double quotes, but (so far as I can tell) does not
> anywhere define what constitutes a character nor does it define what the
> lexical representation of a character is.
>
> When I look at section 7.1.1. (Lexical Structure) I find that this
> ambiguity is compounded in both the definition of <character> and
> <string element> by reference to the term "any character", which is not
> a defined term in the grammar (or elsewhere that I can find).
>
> The only feasible extension I can see that might be compatible with the
> current language definition is to extend the space of defined things
> that may appear after '\' within a string. In abstract, one might adopt
> the C convention of \0 (backslash zero) or \0x, but this was an awful
> choice and the C convention imposes a predefined length restriction on
> the character code that won't survive over the long haul. My provisional
> suggestion as a starting point would be the following within strings:
>
> \bBBBB.
> \oOOOO.
> \hXXXX.
> \dDDDD.
>
> where BBB, OOO, XXX, DDD are (respectively) arbitrary sequences of
> binary, octal, hexidecimal, or decimal digits terminated by the period
> (which is consumed as part of the reading of the string-embeddded
> character). Note that this convention is also compatible with the
> definition of character literals:
>
> #\bBBBB
> #\oOOOO
> #\hXXXX
> #\dDDDD
>
> no trailing period is required on character literals, as they are
> already required to be followed by a delimiter. Note that this is
> unambiguous even in the presence of the continued legality of #\b, #\o,
> #\h, and #\d.
>
> I further suggest that R6RS should clearly identify that the collating
> sequence used by char-< be defined to match the unicode code point
> sequence (which behavior is backward compatible), that the current
> char-ci and friends be specified as using some particular
> backwards-compatible language interpretation, and that new operations
> unichar-ci< etc. and unichar-< be introduced that accept a language
> environment as an additional argument and implement language-appropriate
> lexical comparison.
>
> Technically, I suppose that if one did this char-< and char-ci and
> friends might be removed from the core language and turned into macros,
> as a standard encoding of language environments is required to support
> unichar-< in any case.
>
> Just random thoughts.
>
> shap
>
Jonathan S. Shapiro wrote:
> One last item concerning characters, also for the R6RS group if you see
> fit:
>
> The set of legal characters in identifiers *is* pretty carefully defined
> in R5RS. Unfortunately, it defines as legal both of the obvious
> character choices that might be used to distinguish namespaces (or
> modules) from identifiers within those namespaces (to my mind the
> obvious choices would be either '.' or ':').
>
> Question: what delimiter is Matt currently using in MzScheme, since that
> seems likely to be the final outcome? I do not see that this addressed
> in the current PLT Scheme manual, and it would be a significant mistake
> (IMO) to be unable to access a (possibly colliding) symbol name defined
> in some module.
>
> Suggestion: whatever character is used to separate module names from
> identifiers (including submodules) defined in the module should *not*
> remain a legal identifier character for other purposes.
>
>
> shap
>
------------------------------------------------------------------------------
Subject: Re: Trivial CLTL/Scheme question
From: "Jonathan S. Shapiro" <shap at eros-os.org>
To: feeley at iro.umontreal.ca
Cc: Guy.Steele at Sun.COM
In-Reply-To: <4176DB30.4050303 at Sun.com>
Date: Wed, 20 Oct 2004 18:07:37 -0400
X-DIRO-MailScanner-Information: Please contact the ISP for more information
X-DIRO-MailScanner: Found to be clean
X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel,
SpamAssassin (score=0.1, requis 5, RCVD_IN_SORBS 0.10)
X-MailScanner-From: shap at eros-os.org
Marc:
A correction on the note I sent to Guy:
I subsequently realized that there is an error in one of my suggestions.
Contrary to what I said, the character used to separate module name from
identifier name *must* be a legal character in a symbol name, else
programs as data become broken.
shap
On Wed, 2004-10-20 at 17:40, Guy Steele wrote:
> You raise some interesting suggestions. I have forwarded them
> to Marc Feeley, the editor-in-chief of the current effort to
> revise the Scheme standard. (I am a member of the Scheme
> Steering Committee, which does managerial oversight of the
> editorial team but does not take part in the technical
> decision-making. If you have any other comments about Scheme,
> you may want to send them directly to him at feeley at IRO.UMontreal.CA .)
>
> --Guy
------------------------------------------------------------------------------
From: Mitchell Wand <wand at ccs.neu.edu>
Date: Wed, 27 Oct 2004 17:09:14 -0400
To: Marc Feeley <feeley at iro.umontreal.ca>
Subject: Comments received so far (2)
Sender: Mitchell Wand <wand at ccs.neu.edu>
X-DIRO-MailScanner-Information: Please contact the ISP for more information
X-DIRO-MailScanner: Found to be clean
X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0,
requis 5)
X-MailScanner-From: wand at ccs.neu.edu
This is a digest, 2 messages, MIME encapsulation.
--sjVxzASjkg
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
From: Per Bothner <per at bothner.com>
To: Mitchell Wand <wand at ccs.neu.edu>
Subject: Re: Scheme Language Standardization Process: R6RS Progress Report
Date: Tue, 26 Oct 2004 14:26:23 -0700
Message-ID: <417EC0FF.4060000 at bothner.com>
As an implementor of a Scheme dialect with a module system,
I have some experience and opinions on module systems. I also
have some implementation constraints since in the Kawa world
a module is compiled to a Java class. I really would appreciate
seeing the proposed module design and being able to comment on it.
I've looked at (but not studied closely) the module chapter in
the MzScheme manual. Presumably the standard module facility
will be a simplification, but it's hard to comment until I see
the proposed standard. For example the "module path" and "module
name resolver" mechanism is over-general and not suitable for R6RS.
The Kawa module system is minimalistic, in that it identifies a
module with a source file, but it supports the minimum features:
namespace management and separate compilation. I hope the R6RS
module facility will be amenable to Kawa-style separate compilation.
--
--Per Bothner
per at bothner.com http://per.bothner.com/
--sjVxzASjkg
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Torben AEgidius Mogensen <torbenm at diku.dk>
To: Mitchell Wand <wand at ccs.neu.edu>
Subject: Re: [Prog-lang] Scheme Language Standardization Process: R6RS Progress
Report
Date: Wed, 27 Oct 2004 13:33:41 +0200 (MEST)
Message-ID: <Pine.LNX.4.58.0410271316390.1199 at pc-032.diku.dk>
On Tue, 26 Oct 2004, Mitchell Wand wrote:
> I am pleased to announce that the Scheme Language Editors Committee
> has produced its first progress report. This report details the
> progress made from appointment of the committee in January, 2004,
> through its meetings at ICFP in September, 2004.
>
> The progress report can be found at
> http://www.schemers.org/Documents/Standards/Charter/
Looks good.
One small suggestion for something that I would like to see in the new
standard for Scheme: an arity function. This would return the arity
of a function value, so (arity (lambda (x y) (+ x y))) would return 2
and (arity (lambda () 17)) would return 0. Variable arity could be
marked with negative numbers, where the absolute value minus 1 is the
minimum required number of parameters. So (arity (lambda x (car x)))
would return -1, while (arity (lambda (x1 x2 . xs) ...)) would return
-3 and so on. Alternatively, there could be two functions: arity,
that returns the minimum number of arguments and a varargs? predicate
that determines if the function supports a variable number of
arguments.
Since Scheme is required to check arity at function calls, any
functional value will already include the required information.
Hence, it should be simple to add to any existing (and conforming)
implementation of Scheme. But in the current standard, there is no
way of obtaining this information.
The main applications would be various forms of meta-programming such
as tracing, debugging, meta-interpreters, normalisation by evaluation,
etc.
Torben
--sjVxzASjkg--
More information about the R6RS
mailing list