On Thu, 2009-10-15 at 15:47 -0700, Arthur A. Gleckler wrote:
> On Thu, Oct 15, 2009 at 3:28 PM, Thomas Lord <[email protected]> wrote:
> > It's conservative and incremental because it just floats
> > some existing elements of the semantics into first-class
> > values. It's practical because, well, it's been done more
> > than once.
>
> That's not conservative. Once such things are first-class values,
> they're hard to remove, even if there's a strong consensus that they
> were a mistake. And I thought that there already was reasonable, but
> not perfect, consensus that they were a mistake.
First, I do NOT believe that scheme standardization is the proper
place to work out these issues. There needs to be an experimental
dialect first that tests whether these things can in fact, as I
suspect, be done in a sane and productive way that does not end
in a great monument to cyberentemology.
I've read the papers that concluded they were a mistake, and
what I came away convinced of is that they'd been done wrong
the first time.
Doing them without meticulous attention to the association of
correct environments with each parameter, even in compositional
lazy forms, was definitely a mistake. Flambda, etc, did not
make any provision for preserving the association of each
argument with its respective environment and this, I believe,
was the primary cause of the bugs and intractable problems to
which it was given.
FEXPRs were still very raw and unrefined when abandoned in favor
of macrology; the macrology then was pretty raw too, in some
cases reexpanding every time it was executed or modifying the
representation of program source during runtime. But we've learned
and refined it over the intervening years. Still, we reach this
point where expand-time macros have some problems which, although
not very severe, may be fundamentally intractable problems when
combined with modules.
In my opinion, it is time to look and see if the learning
we've acquired and the insights of the current generation can
refine FEXPRs and first-class environments to a point more
consistent than the best we seem to be able to do with macros.
And I'm doing that. In a project unrelated to the scheme
standardization effort.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss