On Sun, 2009-09-06 at 14:55 -0700, Joe Marshall wrote:
> I guess we'll first have to narrow down what we mean by `first-class
> environments'
> If you can only obtain a first-class environment by an explicit call to
> `the-environment', then you have fewer problems. But if you can call
> `procedure-environment' on any procedure, you've pretty much opened up
> the entire world.
In the first place this is wandering afield for a standards discussion.
We haven't seen and experienced enough of first-class environments to
standardize them. I would consider them a thing that people should be
experimenting with and gaining experience, not a thing that is well
enough understood to standardize.
I think they should *eventually* be in the scheme standard; the first
steps have been taken starting when eval was standardized requiring
an environment argument. But our knowledge and experience has not
yet proceeded so far that the last step of standardization should
be done now.
> If you can eval `define' in a first-class environment, that can change
> the binding
> contours. If you wish to restrict how that works, then there are
> fewer problems.
such as, for example, meroon's define-object which defines numerous
procedures with names derived from its arguments in the environment
from which it's called? It seems useful and straightforward to me;
I consider it a shame, and a reflection of an arbitrary limitation
in the language, that it requires a global program transformation
to work.
> >> The reason the compiler cannot compile the code is because the
> >> code cannot be statically reasoned about. If the *compiler* can't
> >> reason about the code, a human has no hope.
Have you been keeping track of what the JIT and hotspot systems are
doing these days? It's not too uncommon now for there to be multiple
paths, one or more of which are optimized for cases the compiler
understands and one of which punts to runtime for other cases.
In some systems, the runtime system *assumes* things it cannot
prove to produce an optimized path, and then inserts code to
monitor those things and redo the compilation of that path if
they turn false during runtime.
Again, I'm not saying that we should pull the trigger and add this
highly dynamic feature right now, but static phase separation and
static reasoning about programs as structures rather than processes
is, like static type systems, increasingly a thing of the past in
dynamic languages.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
