These are all great ideas, but before we dazzle Ge and others with our brilliant extensions to ChucK, we might focus on getting one or two missing features implemented. :) :)
To name just one: the lack of super() results in contorted code. *Much* further down on my list are things like closures, duck typing and introspection.
I'm just sayin'...
- Rob
On Mon, Mar 22, 2010 at 07:53, Hans Aberg
<haberg-1@telia.com> wrote:
On 22 Mar 2010, at 15:07, Kassen wrote:
One of the main things that I like about Scheme is the REPL.
It struck me that the original plan for chuck --shell isn't completely unlike a REPL in how interaction might work for performance or rapid prototyping. We have some framework for that, in that our parser, compiler and VM all live in the same memory space so if we would want to update some function foo() the system should be able to find what bytecode was generated from the original foo() and replace that with the new one.
Sadly that idea hasn't received much attention in recent days, but in the Bad Old Days it was treated as rather central to ChucK.
Personally I'm more interested in the method of interaction than in the exact language used for it; I'd rather look into that stuff than into a more functional (in the CS sense of the word) syntax as such.
function1<integer, integer> inc("(lambda (x) (+ x 1))");
instead of the
symbol<integer> x("x");
function1<integer, integer> inc = x >>= x + 1;
Now a read-evaluation-print loop just has a line editor which reads input lines and passes it to some such function, and the prints back the resulting string. - There is a function display() by which any object can be made human readable, though not in a way that it can be converted back to Scheme code.
So perhaps ChucK might be made into some library, though it is great of not having to fiddle around with C/C++ programming. But having the option might be useful.