Re: R6 Counterproposal
- From: Joe Marshall <eval.apply@xxxxxxxxx>
- Date: 31 May 2007 17:08:41 -0700
On May 31, 9:41 am, Tom Lord <l...@xxxxxxx> wrote:
On May 30, 10:38 pm, Anton van Straaten <a...@xxxxxxxxxxxxxxxx> wrote:
Right, I don't think every Scheme implementation
wants to be constrained to the choices that SCM
has made here.
My proposal would not constrain implementations
that way. Fexprs, environments, and fully general
reader extensions should be strictly optional
features: portable code can not rely on their
presence.
My poor brain can't keep up here. I'm still confused
over what aspects of fexpr's you want.
But if you are suggesting purely optional features,
why on earth are you calling this a `counterproposal'?
It doesn't seem to have anything to do with r6rs.
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 won't argue how it seems to you, but this is not the case.
The emphasis has never been on performance, but on the
ability to reason about the code. One would *like* to
assign a semantics to the code that is a little more
predictive and useful than just `run it and see what
it does'. Some language features complicate the semantics,
but are generally useful. An example is typed objects
such as integers and strings. Other features may add
more complexity to the semantics than is worth it. Object
systems come to mind here.
Features like FEXPRs and certain implementations of
first-class environments (like the ability to extract
the environment from any arbitrary closure) completely
*obliterate* the semantics. In general, *anything* can
be mutated or changed at any time and there is no
way to reason about the program *except* by running it
and seeing what happens.
The key point is this: if the semantics cannot be
reasoned about, you cannot compile the language.
This should be obvious. The compiler reasons (naively)
about the code.
What is less obvious is that the *programmer* also
must reason about the code. He can usually reason
much more effectively than the compiler can, but he
often reasons much less accurately. The human
programmer often employs a simplified model of the
evaluation process in his reasoning.
This leads to the converse of the point above: if
you cannot compile the language, the semantics cannot
be reasoned about.
It *might* be possible to apply a little human
intuition to the program, but you are asking a lot
from the programmer. There are some really smart
people that work on program language design and on
teaching. The consensus among them is that if the
*compiler* cannot figure out what is meant, then a
*human* has no hope at all.
This is why features like FEXPRs and general first-class
environments have fallen out of favor.
Scheme's historic strength is to provide a very wide
range of functionality out of just a few, parsimoniously
chosen features.
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).
I don't know why not. Macros give you syntactic abstraction
like FEXPRs, but since they can be expanded away in a
separate phase, they add little semantic overhead. *That*
is parsimonious.
I don't like syntax-case that much because it greatly
complicates macros without adding a whole lot in the way
of features. You can get *most* of what you want with
syntax-rules.
I have not read the modules proposal.
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.
I don't recall there being a competition. What's the prize?
.
- Prev by Date: Re: Why R6RS is controversial
- Next by Date: Re: R6 Counterproposal
- Previous by thread: Re: Why R6RS is controversial
- Next by thread: Re: R6 Counterproposal
- Index(es):
Relevant Pages
|
