Re: R6 Counterproposal
- From: Anton van Straaten <anton@xxxxxxxxxxxxxxxx>
- Date: Fri, 01 Jun 2007 00:29:08 GMT
Tom Lord wrote:
Therefore, the features will be useful for writing
standard implementations of things like syntax-case
or PLT modules. For example, the reference
implementation in a SRFI could reasonably use these
features. People will be able to play around with
the features in interpreters that support them and
can decide, in their own implementations, to provide
the SRFIs but not the very dynamic features themselves.
That doesn't sound very attractive: you're addressing the inherent weaknesses of these features by saying that implementors might want to avoid using them to actually build on. So they don't really achieve what they're purporting to achieve: to eliminate the need to define e.g. a module system as core features of the language.
An interesting question is whether there can be
implementations that contain both an interpreter
and a compiler such that if code does make "crazy"
use of fexprs the compiler just gives up (and the
interpreter takes over) but if code uses only,
say, syntax-case macros and PLT modules an optimization
pass eliminates all fexprs and first-class environments
from that code.
The usual way such interesting questions are dealt with is that someone builds or extends an implementation to explore them. Nothing stops anyone from doing that today, with almost any Scheme system.
It seems to me that Scheme's history is unduly
influenced by a period of time when it seemed very,
very important to benchmark serious Scheme compilers
against languages like C. So, there
was a lot of sentiment to make sure that the core,
standardized language was 100% compilable (c.f., the
resistance to EVAL).
I think that that emphasis on compilation is, more
than anything, what has all but killed Scheme's
real-world successes.
This perspective misses an important characteristic of Scheme, which is also very relevant to this discussion: that one of the major drivers of Scheme's development has been research. Some of that research has been compiler research (and very good compiler research, at that), but there's been plenty of research in other areas, too.
In that context, behavior such as the resistance to EVAL is not driven only by a desire for efficient compilation, but also by the desire for coherent and tractable theories of programs -- the desire to understand programs better, which enables better language implementations, and better programs.
It's lots of fun, as a hacker, to just smoosh up all the stages of a program's evaluation into nearly a single phase, and damn the consequences. Some languages and implementations have done something along those lines, and had some success with it (Lisp, Smalltalk, Self, and the modern descendants of scripting languages). But it's not as though this is the final word in language design. In fact, those languages have all also run into the problems with the approach in various ways, ranging from intractability to performance.
A big part of Scheme's research story has been exploring these kinds of problems. As I argued in a recent exchange with Pascal Costanza in the "Vote on R6RS" thread, that research has focused on solving some of these problems in ways that are more tractable than the simple, highly dynamic solutions. Often, in this process, some properties are given up in exchange for others, and it can take more research and time to regain those properties, if that's considered desirable (it isn't always).
I agree that this process has been a big factor detracting from Scheme's suitability as a mainstream programming language (whether that's important, good, or bad is a separate question), but characterizing this as an "emphasis on compilation" is, I dunno, like characterizing the space program as having "an emphasis on rockets".
Research into the relationship between source code and running programs does tend to result in principled techniques to transform the one to the other, part of which is called "compilation", so yes, there's some emphasis on that.
And, tragically: if you want to just hack in a high-level
language, innovating freely, not terribly concerned
about performance, and often adding features by *in
effect* building domain specific languages (one of
Scheme's alleged strengths) -- evidence on the ground
is that you're best off using Lua, Ruby, Perl, PHP,
Python, or any of similar ilk. Those languages
are, each every one of them, filled with horrible warts
compared to Scheme but they have this strength:
millions of programmers can well-enough grok how they
work, and they work flexibly enough, to experiment with
"gross" hacks that get a job done (e.g., ActiveRecord in
Ruby, objects in Lua, etc.) It's as if Schemers look
at what's going on in those languages, correctly decide
"that's the wrong way to do it," but then mysteriously
and sadly conclude "there must be no *right* way to do
it."
There are right ways to do it, implemented in Schemes today, backed by the research I was talking about. But if you're convinced that you need, say, FEXPRs to do the sort of hacking you want, then few of the available choices are going to look right to you. I'd suggest that's a question of perspective, not a problem with Scheme.
BTW, I'm not sure that there's much stopping anyone from taking an existing Scheme, implementing a nice metacircular interpreter on it (see EIOD), and getting the sort of functionality you want. It ought to be possible to do that quite portably. Perhaps integration between the interpreter and the host would need careful handling, but it should be doable.
Scheme's historic strength is to provide a very wide
range of functionality out of just a few, parsimoniously
chosen features.
Sure, but it doesn't follow that any such feature is automatically a good choice for Scheme. There are reasons that the features you mention have traditionally been treated with caution, at best.
I see no parsimony in things like module systems and
macro systems, especially when they are so complex,
so limited, so arbitrarilly chosen from among the options,
and so overlapping in what underlying (but unsurfaced)
concepts they rely on (such as syntactic environments).
They're building blocks of a different kind from, say, lambda or first-class continuations, and there are reasons for the differences. I'll respond on the parsimony issue separately, in the next few days. (This also overlaps with Alex Shinn's summary of controversial R6RS features.)
Fexprs and environments surface the underlying concepts
in a practical way, directly, allowing not only the presently
considered macro and module systems but much more beyond.
Fexprs and environments, in an interpreted setting, put
Scheme (and its advantages) in the game against already-
flexible interpreted languages like Lua, Ruby, et al.
Scheme is already in that game, in better shape than the competitors you mention *from a technical perspective*. Where Scheme has a challenge is in catering to the "millions of programmers [that] can well-enough grok how they work, and they work flexibly enough, to experiment with "gross" hacks that get a job done". But I think you underestimate the strength of the connection between the languages that you see as being "filled with horrible warts compared to Scheme", and their support for "gross hacks".
Are you really sure that you want Scheme to be a language designed to support and encourage gross hacks? When a new users asks about using EVAL, do you think the answer should be "sure, go ahead, knock yourself out," or isn't there some value in pointing out that there are more elegant and precise ways to solve whatever problem is being asked about, and in explaining those approaches, and in being able to point to books and papers that describe them?
I think Scheme is going to go in the more dynamic direction
on its own. It's just too simple and correct an idea.
A number of Scheme implementations have put effort into supporting dynamic features, and in that sense are becoming more dynamic, but they're taking different approaches to the ones you favor. This discussion involves more than a single dimension of more/less dynamic.
In some sense, the only question is whether or not the
revised report series will remain a legitimate source of
authority on Scheme.
Any revised report which is accepted and followed by enough implementors to be useful will, of course, continue to be relevant.
The role of the revised reports as a "legitimate source of authority" on Scheme is often misunderstood. One only has to compare R5RS to what Scheme implementations actually do, to get a hint of the issues here.
As Will pointed out recently, R6RS adds a new paradigm for portable code (or at least can usefully be seen as such), but it's no more the comprehensive arbiter of what Scheme implementations can and will do than R5RS was, except in certain well-defined and encapsulated areas.
Anton
.
- Follow-Ups:
- Re: R6 Counterproposal
- From: Ray Dillinger
- Re: R6 Counterproposal
- Prev by Date: Re: R6 Counterproposal
- Next by Date: Re: Why R6RS is controversial
- Previous by thread: Re: R6 Counterproposal
- Next by thread: Re: R6 Counterproposal
- Index(es):
Relevant Pages
|
