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
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.
The way Guile works, being a library, is that there are functions for interpreting code. So I implemented those functions into some class objects, so that one can write: function1
inc("(lambda (x) (+ x 1))"); instead of the symbol<integer> x("x"); function1 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.
Hans
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On 22 March 2010 16:35, Robert Poor
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. :) :)
I agree. What I am after here is still chiefly the updating of (some) running code without losing the value of variables and the state of processes around it. This has actually been on the wish-list since whenever. Priorities as I see them should be; * Filter-stability (or limiting of the main out). This should be on top as it can actually be a real medical danger on OSX with headphones, IMHO * The type-system muckups, This includes stuff like "Clemow's Bane", the type of objects of a type that extends another, especially as they affect being returned by functions, elements of arrays and so on. This is a whole set of related issues that can crash ChucK outright and that affects a LOT of non-trivial coding techniques. I believe this to be the main bottle-neck in more advanced ChucKing right now. This causes crashes, incorrect errors and on top ofthat we can't hope to talk about more advanced things without addressing this cluster of bugs. *Garbage Collection. Old as dirt, as a wishlist item, pun very much intended. We a) need this finished and b) the bits that are already in there need to stop collecting stuff that *does* have a reference (ie it's being returned by a function). items 2 and 3 are biggies (evidently) and I would never advocate -carefully- progressing towards more advanced stuff without those. if we'd even try there would be a mess of epic proportions, I predict. As far as I know 2 and 3 (particularly 3, which we have known about for longer) has actually been keeping up other features for a long time now. It might sound conservative to the point of being non-ChucKian, I know I'm being boring, but this is how I fear it is. Yours, Kas.
participants (2)
-
Kassen
-
Robert Poor