[chuck-users] "Or"

Kassen signal.automatique at gmail.com
Fri Sep 3 19:27:09 EDT 2010


Tambet;

It started from getters-setters and evolved into properties.
>
>
I suppose? I don't really know what kind of thing this new "likely" proposal
is.


> 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 ..


Oh, it's outdated 50 years in some respects :-D.

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.


> 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.
>

What would you use a lambda for, concretely? What kind of iterator?

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).

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.

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.


>
> 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).
>

 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.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100904/fff044bd/attachment.htm>


More information about the chuck-users mailing list