On Sep 10, 2009, at 2:44 AM, Eduardo Cavazos wrote:
Aziz,
Thanks for the reply. I agree with you that there are multiple
interpretations that make sense.
My question comes as a result of discussions with jao. They got me
thinking about what barriers to a highly dynamic development runtime
are inherent in R6RS. It appears that there actually aren't that
many, if any; it's mostly up to the implementor.
In my view, R6RS-style libraries/modules *allow* (but does not
require) implementations to be static at run time.
Abdulaziz Ghuloum wrote:
Why would that be absolutely necessary? Or did you mean reload the
library when you said recompile the library?
Hmmm. I thought recompilation would be necessary in the case of
procedures that depend on the changed procedure. But if reload would
do the job, then cool.
There's nothing special about procedures. At run time, there are
variables (some of which might be bound to procedures) and there are
values (some of which are procedures). The compiler may "inline"
anything it can (including procedures), and inlining procedures is
just a special case of copy propagation.
then recompile any currently loaded dependent libraries (and in a
*really* dynamic environment, update any currently running threads/
applications which depend on the changed library).
If you're going this far, you might as well start a new ikarus
instance, no?
Well, I'm not necessarily lobbying for this behaviour in Ikarus. But
this is a litmus test for the hardcore dynamic lanuage folks. I.e.
can they make a source change and have a running application reflect
the change. Smalltalk and Factor do this for example.
Dude, you can set! a variable, set-car! a pair, or vector-set! a
vector, and its effect is immediate everywhere, no? I don't get what
this test is all about.
I know of one particular argument in favor of this behaviour.
Sometimes you have to get your program into a certain state in order
to test some code change. It's nice to get your program to that
state interactively, then make code changes until you see the
behaviour your want.
No, that's not nice. :-)
As opposed to maybe writing a script which gets your program to that
state, and using it each time you want to test the code change.
This is more reusable, reliable, and predictable. You can add that to
your test suite and run it every time you make a change. I mean, a
text file doesn't cost money, right? Why is it nicer to type things
in rather than load them from a file?
Or take for example one of the graphics demos; it's nifty to get it
running and then notice the effects of changing the code in a live
fashion. So live coders (the performance art sort) would want this
sort of thing.
This is a different thing. This is not development and debugging.
This is performance art. (Karate folks can break bricks with their
heads, but that doesn't mean you should walk around smashing your head
to every wall you see!) And yes, you can already do all of this with
very little or no change to your programs and libraries.
Aziz,,,
