R6RS mail archives, formal comments, next r6rs draft
d...@cs.indiana.edu
1. Shortly after we began our work, we created a mailing list for our
discussions and agreed that the mailing list archive should be made
public at some point after the R6RS was published. During our
September 12, 2006 meeting, we voted to make the archive public
immediately. It has taken us a while to get around to it, but the
archive is now available at http://www.r6rs.org/r6rs-editors/.
2. During our October 19, 2006 meeting, we committed to providing a
formal response by December 15, 2006 to all formal comments submitted
by November 15, 2006. The timing of our formal responses to formal
comments submitted after that date will be decided at a later time.
For more information on the formal review process, see
http://www.r6rs.org/process.html.
3. Also during our October 19th meeting, we committed to producing a
new draft of the R6RS by January 15, 2007, which will take into account
comments and suggestions made by November 15, 2006. LaTeX source code
will also be provided for the drafts.
We appreciate the response to date from members of the Scheme
community.
Kent Dybvig
Benedikt Rosenau
[...]
> We appreciate the response to date from members of the Scheme
> community.
There were few comments on this group so far. I wonder what the
opinion of the community and especially the implementors is.
Benedikt
Ray Blaak
Well, I for one am impressed by their caliber. I am interested in these
archives and will slowly be digging into them, looking for reasons for
particular decisions, discussion of tradeoffs, etc.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
bunn...@gmail.com
A desaster, that's what the current R6RS draft is. It breaks with
fundamental ideas of Scheme by introducing bloat and redundancy.
Traditional niches where Scheme is used as an embedded
scripting language (or as a minimalistic language for embedded
systems) are abandoned by making the full numeric language tower
mandatory and requiring full unicode support.
Adding the politically correct macro- and module system was somehow
to be expected, though. R6RS completely disregards de-facto standards
like SRFI-1, yet looks like a device to push one particular persons'
pet-SRFIs... Further brain-damage like hardcoding UNIXisms, specifying
the
unspecified and introducing the hilarious ASSP makes it
complete.
andreas...@googlemail.com
bunn...@yoho-gmail.com schrieb:
> Benedikt Rosenau schrieb:
>
> > d...@cs.indiana.edu wrote:
> >
> > [...]
> >
> > > We appreciate the response to date from members of the Scheme
> > > community.
> >
> > There were few comments on this group so far. I wonder what the
> > opinion of the community and especially the implementors is.
>
> A desaster, that's what the current R6RS draft is. It breaks with
> fundamental ideas of Scheme by introducing bloat and redundancy.
It seems there are rather two Schemes needed? A base version and a
premium version.
The base version featuring things like
* macros at compile time
* module system
And the premium version adding
* numeric tower
* macros at runtime
* unicode
Well, this is how Chicken seems to handle it.
William D Clinger
> A desaster, that's what the current R6RS draft is. It breaks with
> fundamental ideas of Scheme by introducing bloat and redundancy.
Criticisms of the draft R6RS are welcome. I hope you will
participate in the ongoing informal discussion or by making
making formal comments. See http://www.r6rs.org/
> Traditional niches where Scheme is used as an embedded
> scripting language (or as a minimalistic language for embedded
> systems) are abandoned by making the full numeric language tower
> mandatory and requiring full unicode support.
The draft R6RS proposes portable mechanisms that would allow
embedded programs to exclude Unicode support and to specify
certain subsets of the numeric tower, e.g. fixnums only or
fixnums and flonums only. For embedded systems, this would
represent a distinct improvement over the R5RS.
Support for embedded systems could be improved further.
Improvements to the draft R6RS will become more likely if
those who understand the issues take part in the discussion.
Will
J. Winter
> A desaster, that's what the current R6RS draft is. It breaks with
> fundamental ideas of Scheme by introducing bloat and redundancy.
> Traditional niches where Scheme is used as an embedded
> scripting language (or as a minimalistic language for embedded
> systems) are abandoned by making the full numeric language tower
> mandatory and requiring full unicode support.
Well, I agree and then don't agree. Scheme was intended to be as much as
possible complete without putting a heavy burden on implementation
details and numerics. I agree, that numeric tower is needed, hygienic
macros etc. are needed. As a matter of fact I accept all new proven
ideas which may extend Scheme language expressiveness without expanding
the language if there is possibility to put matters simply to macros or
libraries. The line is thin: if we cross it we could forget Scheme and
move to ML (and it's inkarnations).
- jw
bunn...@gmail.com
> The draft R6RS proposes portable mechanisms that would allow
> embedded programs to exclude Unicode support and to specify
> certain subsets of the numeric tower, e.g. fixnums only or
> fixnums and flonums only. For embedded systems, this would
> represent a distinct improvement over the R5RS.
R6RS pretty clearly states:
"Implementations are required to implement the whole tower of
subtypes..."
and
"Implementations are required to support exact integers and
exact rationals of practically unlimited size and precision."
Thus, to be R6RS compliant, and implementation could not
restrict itself to supporting only a subset of the numerical
types.
Larry Elmore
I fail to see why this would prohibit an implementation from excluding
those features from a program.
--Larry
bunn...@gmail.com
> bunn...@yoho-gmail.com wrote:
> >
> > Thus, to be R6RS compliant, and implementation could not
> > restrict itself to supporting only a subset of the numerical
> > types.
>
> I fail to see why this would prohibit an implementation from excluding
> those features from a program.
>
That's not the point (even though I have trouble understanding what
you mean by "excluding features from a program"). The point is
that it is impossible to be R6RS compliant (for an implementation)
without providing support for all number types (or complete
UNICODE case-conversion, for that matter).
William D Clinger
> Thus, to be R6RS compliant, and implementation could not
> restrict itself to supporting only a subset of the numerical
> types.
That is true, but an implementation that is intended
primarily for embedded computing, and which intends to
provide efficient support only for fixnums, or only for
fixnums and flonums, can still satisfy the requirements
of the R6RS by using the reference implementation of the
tower, with no attempt to optimize any part of it.
That takes approximately zero effort.
There are far more serious problems with the R6RS,
even for embedded systems, even for the arithmetic
that would be used in embedded systems. For example,
those who care about embedded computing would do well
to design suitable subsets of the (r6rs) library for
that class of applications, and to propose those subsets
as standard libraries. While it is true that the R6RS
provides facilities that individual programs could use
to implement those libraries themselves, standardization
would promote portability and make it easier for systems
to link together only the code that is needed.
We should discuss the real problems, not the illusory
ones.
Will
William D Clinger
> That's not the point (even though I have trouble understanding what
> you mean by "excluding features from a program"). The point is
> that it is impossible to be R6RS compliant (for an implementation)
> without providing support for all number types (or complete
> UNICODE case-conversion, for that matter).
In a previous message, I addressed the issue of support for
all number types.
The Unicode case conversion, category, and normalization
procedures are isolated within the (r6rs unicode) library.
The rationale for that isolation is that programs shouldn't
have to pay for Unicode features they don't use. (The
reference implementation of the (r6rs unicode) library
includes over 100 kilobytes of tables, which would be
a significant overhead for embedded programs.)
For implementors, the cost of providing R6RS-compliant
support for Unicode case conversion and normalization
is approximately zero. They can just use the reference
implementation, without changing it in any way.
Will
bunn...@gmail.com
>
> For implementors, the cost of providing R6RS-compliant
> support for Unicode case conversion and normalization
> is approximately zero. They can just use the reference
> implementation, without changing it in any way.
That is nonsense, as especially an implementation targeted
towards system with severe memory or performance
constraints would need a native, tuned implementation
to work satisfactorily.
William D Clinger
On the one hand, you seem to be saying the R6RS should
not require support for Unicode case conversion. On the
other hand, you seem to be saying Unicode is so important
that the reference implementation, which will be good enough
for Larceny to use without any changes whatsoever, won't be
efficient enough to work satisfactorily.
I don't understand your argument.
Will
Tom Lord
William D Clinger wrote:
> We should discuss the real problems, not the illusory
> ones.
Something seems wrong about the unicode stuff
if it comes out that integer->char must reject
surrogates. I've only skimmed so far but I think
something went wrong.
-t
Marcin 'Qrczak' Kowalczyk
> Something seems wrong about the unicode stuff
> if it comes out that integer->char must reject
> surrogates. I've only skimmed so far but I think
> something went wrong.
Either choice (Unicode code points: 0..0x10FFFF, and Unicode scalar
values: code points except surrogates) makes sense.
Either choice has drawbacks. With code points not every string is
encodable as correct UTF-{8,16,32}, and more semantically meaningless
strings can be represented. With scalar values malformed UTF-16
strings (which may appear as Windows filenames) cannot be represented
as Scheme strings, and certain low-level operations on UTF-16 code
units or on Unicode character database require them to be processed
as integers rather than characters.
I made the other choice for my language, but generally either choice
makes sense.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
bunn...@gmail.com
I'm not at all saying that unicode is important. What I'm
trying to show is that to be R6RS compliant, full unicode
case-conversion
must be supported (according to the current draft), which may be too
much
on a constrained platform (or a platform that is intended to be small).
Moreover I consider your argument that one could
just drop in the reference implementation invalid, as this would not
solve
the original problem: running in an constrained environment. It would
be (an insufficient) solution to provide unicode on a non-R6RS
compliant
implementation.
Full unicode support (and the full numeric tower) should be an option,
and should not be required for an implementation to be R6RS compliant.
Benedikt Rosenau
[...]
> Adding the politically correct macro- and module system was somehow
> to be expected, though. R6RS completely disregards de-facto standards
> like SRFI-1, yet looks like a device to push one particular persons'
> pet-SRFIs... Further brain-damage like hardcoding UNIXisms, specifying
> the unspecified and introducing the hilarious ASSP makes it complete.
I marvelled at the selection of SRFIs, too. But I definitely look forward
to the formal semantics of the specified unspecified value.
Benedikt
Benedikt Rosenau
> Criticisms of the draft R6RS are welcome. I hope you will
> participate in the ongoing informal discussion or by making
> making formal comments. See http://www.r6rs.org/
It seems that many original contributors are withdrawing from
the process. Is it a sign of blind faith in the results, or
is something else going on?
Benedikt
Andre
> A disaster, that's what the current R6RS draft is. It breaks with
> fundamental ideas of Scheme by introducing bloat and redundancy.
I understand where you are coming from, but perhaps you may
influence some of the things with which you are unhappy via the
forum (unless you think it is completely a lost cause).
As someone who has participated in some of the r6rs srfis and in the
r6rs forum, I can attest to the fact that the editors are not immune
to persuasion and constructive criticism. Some of the editors have
been known to welcome it, and quite a number of shortcomings have been
modified based on such criticism. It also goes the other way: I have been
persuaded that I was wrong on more than one occasion, or at the very
least gained a better appreciation for the motivation of design
decisions I might not have agreed with or understood fully at first.
The editors are doing a difficult and largely thankless job, and a
certain amount of give and take is inevitable given the varied
constituency.
Regards
Andre
Abdulaziz Ghuloum
bunn...@yoho-gmail.com wrote:
> Full unicode support (and the full numeric tower) should be an option,
> and should not be required for an implementation to be R6RS compliant.
Why is R6RS-compliance such an important thing for implementations that
run under severely restricted environments such as the ones you
describe? If I'm writing a Scheme implementation that should run in an
RCX brick, I can simply pick the parts of the standard that make sense
in this environment. Since this implementation won't support unicode
for example, I won't provide the (r6rs unicode) libraries and state
that the implementation is R6RS minus unicode. This makes it clear for
users of the implementation that any program or library that uses
unicode will not run under this implementation. If, however, a larger
RCX brick is available, I can then use Will's unicode library as a
drop-in.
The alternative that you seem to advocate is that unicode should not be
part of the standard because it does not make sense under some
implementations/environments. Well, that's true for any feature, isn't
it? For example, IO ports may not make sense in an internet router,
yet that does not mean it should be dropped from the standard. Yes, an
implementation that runs in a router will not be R6RS-compliant, but is
that important?
If every feature that cannot be supported under some implementation is
dropped, then what's the purpose of R6RS? How would people write
portable and useful Scheme code in that case?
Aziz,,,
Abdulaziz Ghuloum
I completely agree with Andre here. And let me add that R6RS will
happen, implementations are going to support it, and users are going to
demand it (like it or not). It is far better for implementors to
contribute to the R6RS process, to voice their concerns, and attempt to
steer the process to where they think is the right direction.
Protesting/boycotting R6RS is not very constructive at this point IMHO.
Aziz,,,
Abdulaziz Ghuloum
J. Winter wrote:
> Well, I agree and then don't agree. Scheme was intended to be as much as
> possible complete without putting a heavy burden on implementation
> details and numerics. I agree, that numeric tower is needed, hygienic
> macros etc. are needed. As a matter of fact I accept all new proven
> ideas which may extend Scheme language expressiveness without expanding
> the language if there is possibility to put matters simply to macros or
> libraries. The line is thin: if we cross it we could forget Scheme and
> move to ML (and it's inkarnations).
I don't get your remark. What's wrong with ML as far as language
definitions are concerned?
Aziz,,,
J. Winter
>
>
>
>
> I don't get your remark. What's wrong with ML as far as language
> definitions are concerned?
>
> Aziz,,,
>
>
Nothing, ML is better for many reasons.
- jw
William D Clinger
> > Criticisms of the draft R6RS are welcome. I hope you will
> > participate in the ongoing informal discussion or by making
> > making formal comments. See http://www.r6rs.org/
>
> It seems that many original contributors are withdrawing from
> the process. Is it a sign of blind faith in the results, or
> is something else going on?
I hope it isn't a sign of blind faith in the results,
and I don't think it is. Some original contributors
have moved on to other things, while many newcomers
have stepped up and are making valuable contributions.
The members of the steering committee (Alan Bawden,
Guy Steele, and Mitch Wand) are very much involved
of the process, but their role precludes advocacy
during the period of public comment.
I have spoken with a number of people who express
interest in the R6RS process but have not yet
participated in the public debate. Some have not
yet had time to study the draft R6RS in detail,
some do not care to participate in public debates
but are participating in private ways, and so on.
There are many different ways to contribute.
Will
bunn...@gmail.com
It isimportant to see the advantages of a *small* core language:
As it is easier to grasp, to teach and to implement. This makes R5RS
Scheme
an excellent language for learning programming and has driven the
research on implementation techniques for functional and dynamic
languages to interesting and unexplored areas (exactly because a small
language simplifies such an implementation effort).
There is absolutely no need for another large lisp dialect, and Scheme
traditionally took care of being minimal. I see this idea being lost
with
the new R6RS draft (and hear with horror that more stuff is envisioned
for later revisions of the standard).
If you need libraries for writing portable and useful code (which, in
case
you haven't noticed, is already done in R5RS Scheme), then take a look
at the SRFI process which already addresses this issue, and is the
right
approach (Unfortunately, most SRFI discussions tend to end in trench
warfare, but that shows just the state of the Scheme community and is
likely not to change, which means we have to live with it).
We have a device for adding all those sorts of extra functionality to
core
Scheme, and implementors *are* respecting it (or not, and then they
probably
have pragmatic reasons for not doing so). R6RS can help here
by adding support to package and integrate existing and
yet-to-be-created
libraries (based on the wonderful fact that nearly every language
extension
can be implemented as a library) by providing a module system and
extended macros.
Yet, the R6RS comittee has chosen to just throw everything into the
pot,
disregarding both options of splitting the standard into a core and an
(optional) library part or building on existing work (i.e. the SRFI
process,
and specifically widely used SRFIs).
>From now on R6RS can only grow, which defeats the very purpose of
Scheme.
If every feature that is required for every sort of useful program is
integrated
into the standard, you end up with exactly the situation where the
Common
Lisp community is: a standard that is too big, still incomplete
(naturally),
and which encumbers more than it provides, and which makes change
nearly
impossible.
If I need networking support to write portable and useful programs,
would I
have to wait for R7RS? Will GUI support be included? No, what am I to
do, then?
Can I talk portably to the parallel port? Databases? I2C? Do we get
that
in R8RS? Probably not, so I'm stumped anyway. No, we need a small but
open
and standardized core language and a process of specifying extensions
to that
standard (side note: a standard FFI would be vastly more useful than
adding
pointless features like enumerations or gratuitious I/O layers)
Scheme is not Python, or Perl, or Ruby: in a single-implementation
language you
just have whatevery is there, or what happens to be included on the
next release.
But Scheme isn't a single-implementation language (and this is an
incredible
advantage) and needs a different approach. We are in the fortunate
situation
that we have it (SRFI), yet it's democratic and so likely to get bogged
down in
discussions and flamewars, but it hasn't failed completely.
So a multi-implementation language can not be both portable and
useful, since "usefulness" must take every use and every user into
account.
You are also unlikely to need unicode support on your RCX brick, yet
you are
likely to have some sort of I/O system (even if it just is for
debugging). That internet
router might stub I/O routines completely, but R5RS provides such a
minimal
set that it doesn't matter.
bunn...@gmail.com
>
> I completely agree with Andre here. And let me add that R6RS will
> happen, implementations are going to support it, and users are going to
> demand it (like it or not).
"We'll show them stubborn implementors, right?"
I wonder whether you are representative of what users demand and what
not.
Personally, I'm trying very hard to understand what they demand and
have
come to the conclusion that it is: ease of use, easy integration with
operating
system features, standard build-tools and third-party libraries and
easy packaging of extensions. I may not have been completely successful
at this, but will try as much as
is possible for me.
(I'm just saying this to emphasize that I am a user of Scheme myself,
using it
in all sorts of ugly environments and interfacing to all sorts of
things, having
participated in implementing a user-centric Scheme system, and have
apparently
a different notion of what other users demand: it is likely they want
(say) portable GUI support,
and that right at this moment, instead of waiting for R24RS. I
claim that users are likely to want this much more than (say)
unicode-aware case
conversion - you see: what is demanded depends on the user, not your
idea of it).
> It is far better for implementors to
> contribute to the R6RS process, to voice their concerns, and attempt to
> steer the process to where they think is the right direction.
> Protesting/boycotting R6RS is not very constructive at this point IMHO.
As I already tried to point out, the problem is philosophically, the
details just
being an indicator towards a fundamental direction change in the design
of Scheme. R6RS leads completely into the wrong direction, it's
creators having
forgotton (or ignore) what Scheme originally was all about.
Nils M Holm
> It isimportant to see the advantages of a *small* core language:
> As it is easier to grasp, to teach and to implement. This makes R5RS
> Scheme
> an excellent language for learning programming and has driven the
> research on implementation techniques for functional and dynamic
> languages to interesting and unexplored areas (exactly because a small
> language simplifies such an implementation effort).
I think you make some excellent points here. Why don't you post your
concerns to the R6RS discussion mailing list? This is too important
to not give it a try.
BTW: One thing I already miss in R5.91RS are the "optional" and
"library" qualifiers. Restoring them and maybe adding "optional library"
would definitely make the language easier to learn and more portable.
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
Abdulaziz Ghuloum
> It isimportant to see the advantages of a *small* core language:
> As it is easier to grasp, to teach and to implement. This makes
> R5RS Scheme an excellent language for learning programming and has
> driven the research on implementation techniques for functional
> and dynamic languages to interesting and unexplored areas (exactly
> because a small language simplifies such an implementation
> effort).
I agree that a small core language promotes learning,
experimentation, and research. Should Scheme stop at that? My
guess is that you'd agree that people do find Scheme a useful
language for writing real software. Now to write anything useful in
Scheme, one has to rely on implementation-specific extensions that
are often incompatible across implementations; so, people pick an
implementations and stick (or get stuck) with it. Now I agree with
you that R6RS is unnecessarily too big and contains many features
that are not essential (enumerations?). We also agree that many
useful features are not in R6RS (IPC and other system operations?).
> There is absolutely no need for another large lisp dialect, and
> Scheme traditionally took care of being minimal. I see this idea
> being lost with the new R6RS draft (and hear with horror that more
> stuff is envisioned for later revisions of the standard).
Now R6RS is structured into two parts: the language and the standard
libraries (pages 58 and above). Do you think both parts are
bloated? Or is it just the standard libraries?
> If you need libraries for writing portable and useful code (which,
> in case you haven't noticed, is already done in R5RS Scheme), then
> take a look at the SRFI process which already addresses this
> issue, and is the right approach.
Yes, and some of the features in some SRFI ended up being *standard*
enough to be included in the standard. Additionally, R6RS does not
replace the SRFI process. Maybe I am missing the point?
> We have a device for adding all those sorts of extra functionality
> to core Scheme, and implementors *are* respecting it.
With R6RS, people will write more portable libraries that can be
used out-of-the-box (or so is the intention). As I see it, R6RS
compliments the SRFI process nicely.
> R6RS can help here by adding support to package and integrate
> existing and yet-to-be-created libraries (based on the wonderful
> fact that nearly every language extension can be implemented as a
> library) by providing a module system and extended macros.
Agreed.
> Yet, the R6RS comittee has chosen to just throw everything into
> the pot, disregarding both options of splitting the standard into
> a core and an (optional) library part or building on existing work
> (i.e. the SRFI process, and specifically widely used SRFIs).
All widely used SRFIs (the two of them) can be packaged nicely into
R6RS libraries. They lose none of their functionality and
usefulness. Again, maybe I'm missing the point.
> From now on R6RS can only grow, which defeats the very purpose of
> Scheme. If every feature that is required for every sort of
> useful program is integrated into the standard, you end up with
> exactly the situation where the Common Lisp community is: a
> standard that is too big, still incomplete (naturally), and which
> encumbers more than it provides, and which makes change nearly
> impossible.
I agree here and was not at all advocating including every single
useful feature. The question remains: based on what should features
be included? (I posted a similar question to the r6rs-discuss list.)
> If I need networking support to write portable and useful
> programs, would I have to wait for R7RS? Will GUI support be
> included? No, what am I to do, then? Can I talk portably to the
> parallel port? Databases? I2C? Do we get that in R8RS? Probably
> not, so I'm stumped anyway. No, we need a small but open and
> standardized core language and a process of specifying extensions
> to that standard (side note: a standard FFI would be vastly more
> useful than adding pointless features like enumerations or
> gratuitious I/O layers)
I agree here (in spirit at least). I just don't know what "small
but open and standardized core language" is. For example, I don't
see requiring a full numeric tower as a bloat at all.
> Scheme is not Python, or Perl, or Ruby: in a single-implementation
> language you just have whatevery is there, or what happens to be
> included on the next release. But Scheme isn't a
> single-implementation language (and this is an incredible
> advantage) and needs a different approach. We are in the fortunate
> situation that we have it (SRFI), yet it's democratic and so
> likely to get bogged down in discussions and flamewars, but it
> hasn't failed completely.
> So a multi-implementation language can not be both portable and
> useful, since "usefulness" must take every use and every user into
> account.
Yes, "usefulness" is relative to particular uses. But is there a
general guideline? I mean, we all agree that closures and pairs are
generally useful in almost all environments. Yet there is no
feature that is universally and unconditionally useful.
> You are also unlikely to need unicode support on your RCX brick,
> yet you are likely to have some sort of I/O system (even if it
> just is for debugging). That internet router might stub I/O
> routines completely, but R5RS provides such a minimal set that it
> doesn't matter.
Yes, of course. It's also silly to think that I can run any R6RS
program on an RCX brick or an internet router. So, an RCX Scheme
implementation can pick the parts of R6RS that make sense and drop
what doesn't make sense; and by intentionally dropping some
libraries, the implementation is declaring that it will not run
those programs that require such libraries. The way I currently see
it, it's just how you label it: Do you want to say "Implementation A
is R6RS plus unicode plus numeric tower plus records plus hash
tables ..." or do you want to say "Implementation B is R6RS minus
I/O"?
Aziz,,,
Michael Sperber
Nils M Holm <before-2...@online.de> writes:
> BTW: One thing I already miss in R5.91RS are the "optional" and
> "library" qualifiers. Restoring them and maybe adding "optional library"
> would definitely make the language easier to learn and more portable.
I don't know your argument applies to the "optional" qualifier. As to
"library": What the primitives are in any given Scheme implementation,
and what's built in terms of the primitives, varies greatly from
system to system. The R5RS and previous reports seems to have assumed
some specific implementation structure that was, however, not
published as part of the report. You will find few real-world Scheme
system that are structured in the same manner. (This is also the
reason why the base library is not a "semantic core" language. But I
digress.)
I have my doubts that this distinction every helped teach the
language. As to portability, the R6RS will come with reference
implementations for most of what's described there, and that reference
implementation will also assume (and does, to the extent that it's
already in place) some kind of layer structure with primitives at the
bottom. I expect some implementors will choose to adopt it, some will
choose their own layering. I think that the reference implementations
will do more to help portability than any specific mode of description
in the report.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
bunn...@gmail.com
>
> > There is absolutely no need for another large lisp dialect, and
> > Scheme traditionally took care of being minimal. I see this idea
> > being lost with the new R6RS draft (and hear with horror that more
> > stuff is envisioned for later revisions of the standard).
>
> Now R6RS is structured into two parts: the language and the standard
> libraries (pages 58 and above). Do you think both parts are
> bloated? Or is it just the standard libraries?
The former is bloated, or on the very limit. The latter is mostly
unneccessary.
>
> > If you need libraries for writing portable and useful code (which,
> > in case you haven't noticed, is already done in R5RS Scheme), then
> > take a look at the SRFI process which already addresses this
> > issue, and is the right approach.
>
> Yes, and some of the features in some SRFI ended up being *standard*
> enough to be included in the standard. Additionally, R6RS does not
> replace the SRFI process. Maybe I am missing the point?
See below.
>
> > We have a device for adding all those sorts of extra functionality
> > to core Scheme, and implementors *are* respecting it.
>
> With R6RS, people will write more portable libraries that can be
> used out-of-the-box (or so is the intention). As I see it, R6RS
> compliments the SRFI process nicely.
Well, apparently it doesn't, for example by ignoring SRFI-1 and
SRFI-4 (both of which are widely supported). What sense makes
the SRFI process, if implementors have to support yet another
way of peeling the banana?
> > Yet, the R6RS comittee has chosen to just throw everything into
> > the pot, disregarding both options of splitting the standard into
> > a core and an (optional) library part or building on existing work
> > (i.e. the SRFI process, and specifically widely used SRFIs).
>
> All widely used SRFIs (the two of them) can be packaged nicely into
> R6RS libraries. They lose none of their functionality and
> usefulness. Again, maybe I'm missing the point.
Redundancy through aliasing and re-implementation, which is pointless
and makes the language less coherent. When we have de-facto
standards (admittedly a weak form of standard, but the Scheme community
is small...) we should use them, and not endlessly fuss about yet
another
set of names and semantics for "fold", "every", "u8vector->list" or
"hash-table-ref".
>
> > If I need networking support to write portable and useful
> > programs, would I have to wait for R7RS? Will GUI support be
> > included? No, what am I to do, then? Can I talk portably to the
> > parallel port? Databases? I2C? Do we get that in R8RS? Probably
> > not, so I'm stumped anyway. No, we need a small but open and
> > standardized core language and a process of specifying extensions
> > to that standard (side note: a standard FFI would be vastly more
> > useful than adding pointless features like enumerations or
> > gratuitious I/O layers)
>
> I agree here (in spirit at least). I just don't know what "small
> but open and standardized core language" is.
R5RS is a good start, don't you think so?
> For example, I don't
> see requiring a full numeric tower as a bloat at all.
Ok, but I do.
> > So a multi-implementation language can not be both portable and
> > useful, since "usefulness" must take every use and every user into
> > account.
>
> Yes, "usefulness" is relative to particular uses. But is there a
> general guideline? I mean, we all agree that closures and pairs are
> generally useful in almost all environments. Yet there is no
> feature that is universally and unconditionally useful.
Exactly. But there is a solution: provide only a minimum and make
it possible to introduce extensions (again, Scheme is able to do
that better than most other languages). The Scheme community has done
so since the days of the RABBIT, why stop and go the
"hey-let's-add-that
other-thing-over-there-someone-might-have-use-for-it"?
(I spare you usual citations of St. Exupery/Occam/Einstein - you should
get
the idea by now)
>
> > You are also unlikely to need unicode support on your RCX brick,
> > yet you are likely to have some sort of I/O system (even if it
> > just is for debugging). That internet router might stub I/O
> > routines completely, but R5RS provides such a minimal set that it
> > doesn't matter.
>
> Yes, of course. It's also silly to think that I can run any R6RS
> program on an RCX brick or an internet router.
Why is that silly, if R5RS can do that?
> So, an RCX Scheme
> implementation can pick the parts of R6RS that make sense and drop
> what doesn't make sense; and by intentionally dropping some
> libraries, the implementation is declaring that it will not run
> those programs that require such libraries.
It wouldn't be standard compliant. It may be just a label for you, but
is
important to me.
> The way I currently see
> it, it's just how you label it: Do you want to say "Implementation A
> is R6RS plus unicode plus numeric tower plus records plus hash
> tables ..." or do you want to say "Implementation B is R6RS minus
> I/O"?
I guess you know my answer to that.
Ray Dillinger
<Scheme-numerics rant deleted. Trying to be more neutral
in tone and make a constructive contribution>
Different people have different ideas of what numerics ought
to be and do. Different implementors subscribe to or promulgate
these ideas, and in R5RS and earlier there was freedom to do so.
This may be a good thing if your goal is to provide a small
standard *some* version of whose language can be made to run
on a small or new device with little trouble.
But it left scheme numerics with a *bewildering* variety of
restrictions which, after several tries, I cannot even list
and describe all of without flaming again so I'm not going
to go there.
Worse yet, the only way software had of discovering these
restrictions was getting and detecting wrong answers. But
if you wrote code to get and detect such wrong answers, many
implementations refused to give them to you, instead invoking
error-handling code that you couldn't include in anything
portable because it only *exists* on one implementation -
thereby defeating the very hope of writing simple portable
code.
<deep breath ... must continue without flaming ....>
I am not satisfied with the R6RS numerics requirements. I
do not believe that *unlimited* bignums and rational
representations based on them are a good thing to require,
since that will cause a large class of simple programs
to behave very badly on any finite hardware unless a non-
obvious (to a mathematician, not a programmer) thing is
done to prevent it. Nor do I believe that a standard ought
to ever, under any circumstances, require particular
mathematically wrong answers in the form of specific
roundoffs or wraparounds. I do not believe that the
proposed standard has adequately addressed the errors that
result from the range mismatches between exact and inexact
numbers in most implementations, and leaves in place a set
of requirements where information about numeric *values* will
be inappropriately lost or in some cases changed by very
large factors when information about numeric *exactness*
is converted.
But if you ask me would I rather try to write numeric code
to R6RS conformance or to R5RS conformance-not-required
implementations, I will pick R6RS every time, because at least
with R6RS I know a set of behaviors that is expected and can
check for numeric errors without invoking implementation-
specific code.
I am starting to have a very strong idea of what is the
Right Thing with regard to numerics, not that very many
other people, concerned with "type equations" and "efficiency"
would agree. But as I see it:
* Bignums (including big rationals) ought to be a separate
type with a distinct read/write syntax, used only by
programmers cognizant of the care required to prevent
calculations from "blowing up" rather than invoked by
default. Calculations with any non-bignum argument
ought to return a non-bignum answer (possibly an infinity
or NAN error object).
* Integers ought to be limited to nothing smaller
than N bits, where N is decided as each standard version
is revised, and rationals should use that set of exact
integers as numerator and denominator, and mantissa+exponent
representations ought to use that set of exact integers as
the mantissa.
* It would be nice (but not really necessary) for there to be
a mantissa+exponent representation where the exponent were
powers of ten instead of powers of two, because it would
increase the number of "common" calculations for which exact
results could be returned.
* There ought to be a one-to-one correspondence between
representable exact values and representable inexact values.
This implies a requirement to detect rounding in operations
on "exact" versions of mantissa+exponent represented numbers.
Operations on exact numbers, if rounding must occur to return
a number in the set of exact/inexact values, ought to return
an inexact value.
* Restricted subsets of numeric values (for example float32's
and float64's) should be provided by a set of operations that
return values which are members of that restricted subset -
exact if possible without rounding/truncating, inexact
otherwise or if operating on inexact arguments.
* Integers and blobs are separate types. Blobs should have their
own read/write syntax. Logical AND and logical OR, etc, only
make sense in terms of objects with a particular bit width and
a definite binary representation. Integers have neither of
these things, although particular hardware representations of
them may. Conversion operators should be well-defined, but we
should not make "portable" code presume particular binary
widths and representations for integers.
* Pseudo-mathematical operators with wraparound errors or
undetected floating point roundoffs should be defined only
on blobs (NOT on integers) and permitted only by a set of
routines that bind names to hardware-specific primitives,
rather than pretending to exist in "portable" form. The
semantics of these operations presume a particular bit
width and a particular binary representation, and those
are properties of blobs, not properties of integers.
Mathematical functions must return an "Infinity" value rather
than allowing bit width of the representation to otherwise
affect the answer.
Bear
Nils M Holm
> Nils M Holm <before-2...@online.de> writes:
>
> > BTW: One thing I already miss in R5.91RS are the "optional" and
> > "library" qualifiers. Restoring them and maybe adding "optional library"
> > would definitely make the language easier to learn and more portable.
>
> I don't know your argument applies to the "optional" qualifier. As to
> "library": What the primitives are in any given Scheme implementation,
> and what's built in terms of the primitives, varies greatly from
I agree that the distinction between procedures and library procedures
is rather arbitrary in R5RS. In R6RS, which provides real libraries,
it would become more interesting, though, because it would make the
following distinction possible:
procedure optional procedure
library optional library
By marking a single procedure optional, you would leave it to the
implementor whether she wants to include it or not. By marking a
whole library optional, you would apply the "optional" qualifier to
every procedure in that library.
No matter for what reason the qualifiers existed in R5RS, I think it
would be a good idea to keep them in R6RS, because it would allow
implementors to omit procedures and/or whole libraries without
losing R6RS compliance.
There are environments where things like the full numeric tower,
Unicode support, etc simply do not make sense, and implementors
should be free to omit them.
It worked for R5RS, which was even smaller. Why not keep it in R6RS?
> I have my doubts that this distinction every helped teach the
> language. [...]
When I learned R4RS Scheme (yes, using the report), I was glad that
some parts of the language where marked "essential", so I could
concentrate on these first. Even if that distinction was arbitrary,
it helped a lot.
I think, the entry barrier should be as low as possible and a
small core language does help.
> As to portability, the R6RS will come with reference
> implementations for most of what's described there, and that reference
> implementation will also assume (and does, to the extent that it's
> already in place) some kind of layer structure with primitives at the
> bottom. I expect some implementors will choose to adopt it, some will
> choose their own layering. I think that the reference implementations
> will do more to help portability than any specific mode of description
> in the report.
The reference implementation is a great thing, no doubt about it.
However: the implementor should /still/ be free to omit features.
matteo d'addio 81
Nils M Holm ha scritto:
Can a library (or feature) be considered required for implementation
based
on some specific hardware and optional for other implementations based
on more modest hardware? or considered required for implementations
with a particular intent and optional for implementations with another
different intent? Will it be meaningful or feasible?
matteo
Nils M Holm
> Can a library (or feature) be considered required for implementation
> based
> on some specific hardware and optional for other implementations based
> on more modest hardware? or considered required for implementations
> with a particular intent and optional for implementations with another
> different intent? Will it be meaningful or feasible?
I think that the implementors should have the freedom to decide
which non-optional features they want to include. Tying features
to specific environments would not only limit that freedom but
IMO it would also be far beyound the scope of a language standard.
Tom Lord
> Either choice (Unicode code points: 0..0x10FFFF, and Unicode scalar
> values: code points except surrogates) makes sense.
I think so, too, which is why I don't like this aspect of the R6RS
draft: it permits only one of the two choices.
It is natural to say that (integer->char #xd800) is an
error if you are implementing on, say, a third party VM
that has a native character type which doesn't include
surrogates.
It's also natural to say that (integer->char <n>) should
work for any <n> up to, say, 2^32.
I would hope that R6RS would be artfully agnostic on
the issue rather than specifying that #xd800 may not
be converted to a character (at least in "the usual way").
-t
Benedikt Rosenau
> I completely agree with Andre here. And let me add that R6RS will
> happen, implementations are going to support it, and users are going to
> demand it (like it or not).
I heard similar claims about PerL/vI. What is the argument this time?
Benedikt
Abdulaziz Ghuloum
You mean Perl6's support for R6RS?
Aziz,,,