On Tue, 2009-02-24 at 21:06 -0500, Andrew Pochinsky wrote:
> A weak standard has a rather small value. If one can not expect
> support of language features beyond a small "portable subset", what's
> the point of the rest of the standard?
What "rest of the standard"?
I just want a cluster of documents and
some portability hints.
If I want to write, say, a very basic,
general math library portably, I stick
(perhaps) to the portability guidelines
for writing code for implementations that
support math well. If I want to write
code specific to one or a few implementations,
I do that instead. Some code will be highly
portable. Other code not portable much at
all. Some code will port freely among a
subset of implementations. What's wrong
with that scenario? In what sense is that
possibly a bad thing?
> It seems it is better to have a
> small well designed standard for the language core and to leave the
> rest to the library (defined by another standard perhaps,
We'd all like unicorns and such.
I don't believe there's any good choice of such a
core. I don't even see any good reason why to suspect
such a core might exist. The burden of proof isn't
on me.
> or a set of
> RFIs) than to have another CL-sized language with a caveat that most
> of it is optional to implementors. But maybe you are arguing the same
> point.
Bust it up. We don't need a "language standard".
We need a standard for the basics of values; the
basics of binding; the basics of lambda. We need
formal statements of popular approaches to more
arbitrary things like extensions to lambda, the semantics
of repls, macro systems, etc.
The universe is rich and complex. We need a basis
set of discourse around scheme, not a basis set that
confines scheme.
-t
> --andrew
>
> On Feb 24, 2009, at 4:59 PM, Thomas Lord wrote:
>
> >
> > Has anyone else noticed what a big deal
> > we make, in the society that surrounds Scheme,
> > about the "completeness" of implementations?
> >
> > It is as if the Report's main function is
> > to hand out a homework assignment to implementers
> > who then get an "A" for checking off all the
> > items on a list, a "B" if they only miss a few,
> > etc.
> >
> > I guess the intuition there is that the Report
> > strives to define "The Portable Subset of Scheme".
> >
> > Let me add some emphasis. We treat the Report
> > as if its purpose is to define "***THE*** Portable
> > Subset of Scheme."
> >
> > So much do we make a fetish of that definite
> > article ("***THE***") that we are willing to
> > ostracize people and implementations which take
> > a dissenting line. It is as if the society is
> > afraid that if we take away that "***THE***",
> > Scheme will cease to exist; dissolve in a sea of
> > chaos; simply Lose the historic battle among
> > programming languages.
> >
> > In the rest of the world, in regards to other
> > programming languages, we define "***THE***"
> > standard for a language for a simple economic
> > reason:
> >
> > The function of such standards is to lower the
> > price of implementer labor at the cost of
> > creativity and innovation.
> >
> > A budget manager for a programming project can
> > look at his yearly expenses for a C compiler
> > license and/or support. A snapping young
> > saleswoman from a competing compiler firm can
> > knock one day and say "Hey, I have a substitute.
> > Costs half as much, works just as well."
> >
> > It doesn't matter to the budget manager that the
> > C language, thereby, stagnates. It doesn't matter
> > that C compiler implementers are strongly economically
> > discouraged from innovating at the language design
> > level. The main thing is to keep costs down.
> >
> > So it was, too, with Common Lisp. The customers of
> > of the lisp vendors demanded CLtL after one too many
> > of them got burned spending 4 months instead of 1 month
> > moving code from one system to another. Those customers
> > were suspicious of an emerging pattern of "lock-in".
> > The implementers agreed among themselves that their
> > businesses would indeed do better - the market be larger
> > than otherwise - if a simple "commodity lisp" were
> > defined and, thus, we got CLtL.
> >
> > Now, to my eyes - Scheme is not much like this.
> >
> > We do indeed have a very, very small number of
> > what could be described "commodity implementations"
> > and, yet, the commercial market for those appears
> > quite small and customers there do not appear overly
> > agitated about lock-in and the need to make a commodity
> > of Scheme.
> >
> > Rather, time and time again progress comes because
> > an implementer goes off and innovates - and not always
> > with that much care for the standard.
> >
> > So is the society around Scheme and the "Scheme community"
> > deluding itself? What's our goal in trying to
> > declare ***THE*** standard?
> >
> > Perhaps one thought behind the likes of R6 is
> > the hypothesis that there must exist some nice little
> > core which, once set down, allows all subsequent innovation
> > to be pushed off to libraries or to new core types
> > and procedures. If there are people who believe that
> > (rather than merely act as if they believe it) I think the
> > burden of proof is on them: I don't believe such a core can
> > exist.
> >
> > Perhaps another thought behind the likes of R6 is a
> > kind of "if you build it they will come mentality."
> > You know, if we have a Scheme standard that is just
> > as robust (or more) and better than, say, the standard
> > for C or than CLtL: suddenly we'll all find jobs and
> > riches. Again, the burden of proof lies with those
> > who believe it: to me, that looks like "cargo cult"
> > thinking.
> >
> > I think that we need to deconstruct the whole notion
> > of a standard and come up with something better.
> >
> > In the days around R3 and R4 I remember having occasion
> > to use more than one implementation of Scheme and having
> > to port both my own and other people's code around between
> > implementations. I didn't do so a huge amount but I did
> > enough. It was never a trivial, effortless process - nor
> > was it ever very hard.
> >
> > I remember at one point - just for fun - reaching back
> > and porting *even Guy Steele's Rabbit Compiler*. Even
> > that exercise, for which the whole Report-as-standard
> > concept was irrelevant - didn't take long. (I can
> > report that the Rabbit compiler was messy in places,
> > slow, and buggy. :-)
> >
> > So, in that spirit - I don't think I need some document
> > telling some made-up, idealized "core" which "defines"
> > what Scheme is.
> >
> > It's nice to have a few words for reference that talk
> > about values in general. It'd be nice to have a
> > document talking about, say, cons-pairs in general.
> > Another about some general aspects of lambda and then
> > several others about various kinds of extensions
> > or variations people make.
> >
> > And, yes, it would be good to have a document describing
> > "best portable practices" (updated periodically) or
> > "best compilable practices" (reporting on the state of
> > what compilers these days are doing).
> >
> > There is no reason, even, to centralize anything other
> > than book-keeping authority. Are there 5 contradictory
> > descriptions of cons cells? Why not? Three different
> > portability guides, each offering different advice?
> > So what? Why make a fetish of "***THE***" definite
> > article?
> >
> > Subsets of the society around Scheme might want to
> > further define dialects. For example, a group of
> > compiler writers might gather among themselves to
> > define a dialect which each of their products compiles.
> > We would not say "That is ***THE*** definition of Scheme"
> > we would say "That is the definition of a Scheme language
> > which each of those compilers compiles."
> >
> > An outsider might look at the resulting mess of documents
> > and say "Ok, that's fine - but how is the language defined?
> > Where is Scheme defined?"
> >
> > We could all agree to say, to such an outsider: "It's all
> > in your head."
> >
> > -t
> >
> >
> >
> > _______________________________________________
> > r6rs-discuss mailing list
> > [email protected]
> > http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
>
> _______________________________________________
> r6rs-discuss mailing list
> [email protected]
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
