<div class="gmail_quote">Tambet;</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">It started from getters-setters and evolved into properties.<br>
<br></blockquote><div><br></div><div>I suppose? I don't really know what kind of thing this new "likely" proposal is.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
ChucK lacks almost all features of nowadays language and that's sad - it does a real innovation in one aspect, but is 10 years outdated in many others ..</blockquote><div><br></div><div>Oh, it's outdated 50 years in some respects :-D.</div>
<div><br></div><div>You are right, in a way, but we should also ask whether this huge range of features of some typical modern systems doesn't also make those systems less accessible. The bits that we do have do work and they fit together. ChucK does work quite effectively for sound and instruments. It's accessible, and it's fun. "hello world" is written as "<<<"hello world">>>;" we lack the power that configuring a specific output and method of writing would give but on the bright side; there is no need to configure one either.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I would really like to see that the language design is seriously reworked and all kinds of syntactic sugar introduced - especially lambdas and better forms of iterators.<br>
</blockquote><div><br></div><div>What would you use a lambda for, concretely? What kind of iterator?</div><div><br></div><div>I do -for example- see a issue with how we can't some things to arrays without knowing their type. For example; you could randomise or reverse the order of elements in a array without knowing it's type as that wouldn't matter, but ChucK doesn't permit this. I feel that's more of a issue of arrays and the type-system than a lack of -say- (map) and (lambda).</div>
<div><br></div><div>In the past few weeks I wrote quite a bit of Scheme; I'm certainly not opposed to lambda or to iterating in some quite specific way that fits the current context and aim, but I still wonder how things like that would be used concretely in ChucK.</div>
<div><br></div><div>I still suspect that a big cleanup of the type-system, syntactic sugar for easy global objects and ways of overloading the chuck operator would give us most of the power that we need. Probably not the literal features of other languages, but we don't need those. We need the power that comes from those languages. C lacks most of the features of Scheme and Scheme lacks most of those of C; I don't think either C or Scheme coders are losing much sleep over that.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>But stability and functionality should not traded off for that - having really good virtual machine is more important as there could be different languages designed to it and that would be only good to ChucK (as long as those can cooperate).<br>
</blockquote><div><br></div><div> Well; ChucK programs get parsed, then compiled, then run in the VM. That should mean you could write a new parser and compiler and hook those up. However; there are (or should be....) links between these in ChucK so once this materialises we should be able to update parts of a running program. Exactly in what phase that plan is is a bit unclear but that might cause issues with your idea as the concept of scope might be wildly different between ChucK and the language you would like to add to such a eco-system. Scope would be quite a important aspect to realising this plan.</div>
<div><br></div><div>Yours,</div><div>Kas.</div></div>