Kassen wrote:

2010/9/3 Rebecca Fiebrink

...

OR, because it's chuck and therefore more fun than your average language:

Ok, that's it. Let's have "probably" and "perhaps" at 75% and 25% as well. Everyone loves "maybe" so much, we might as well have more of it.

Does English have single words describing indeterminate times and/or durations that aren't already reserved or would be confusing? We talk about "in a bit" or "in a while" but those sound like they would be cause for confusion. "soon" might be a good one?

I like this. Maybe soon as a keyword and later as a function? soon => now; Std.later(dur max) => now; Std.later(dur min, dur max) => now; michael

2010/9/3 Robert Poor

How about likely(n) ... where 0 <= n <= 1.0, which will return true with a probability of n. Even better, just make n an optional arg to maybe().

I feel that the downside to that is that the charm of "maybe" comes from it being a single word that will look exactly like "true" or "false" in syntax hilighted code. it's the apparent "self-evident-ness" of a keyword that's that unusual that creates the appeal to me. That said; we could also use a library of random functions that generate random values with certain distributions. A lot could be written on the subject of randomness and distributions in electronic music (John Ffitch's article in the CSound Handbook is nice) yet that's a area that hasn't received that much attention in ChucK yet. Of course; unlike keywords a library for random number generators could be written in ChucK itself. Yours, Kas.

Joe;

If we made 'likely' (and 'unlikely') chuckable that would make it nice:

.70 => likely; /* also sets 'unlikely' to .30 at the same time */

Ok, and this would be system-wide? So I could do this in one shred and have it affect others? I quite like this idea. It's a new sort of thing, in that it would be a key-word that would act as both a variable and a function... but it's simple, intuitive and versatile. It would probably be great for live control over generative pieces with random component, where we could sort of crossfade between two kinds of behaviour. I'd like to have this. Actually I'd like to be able to build this sort of thing myself, within ChucK. Yours, Kas.

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.

Hans; It is not having a type system that is causing problems, but that it often

is a bit underdeveloped.

Yes, and malnourished. >:-)

For example, if one wants dynamic typing, that can be done by having a type by which the other types can be derived dynamically. Then the problems like the one above cane be done by introducing a new type.

We can do that for non-primitives, but we can't ask a given object "Hey, what's your type?". Exactly that is high on my wishlist. Kas.

No, Java has the class member and instanceof operator, which would take care of this problem. These are missing in ChucK. /Stefan On Sat, Sep 4, 2010 at 6:12 PM, Hans Aberg wrote:

On 4 Sep 2010, at 17:46, Kassen wrote:

It is not having a type system that is causing problems, but that it often

...

is a bit underdeveloped.

Yes, and malnourished. >:-)

For example, if one wants dynamic typing, that can be done by having a type by which the other types can be derived dynamically. Then the problems like the one above cane be done by introducing a new type.

We can do that for non-primitives, but we can't ask a given object "Hey, what's your type?". Exactly that is high on my wishlist.

That may already have it by its implementation. When looking into the sources, I think I saw a base class object from which all others were derived. If so, it is the Java grammar imposed on top that restricts it.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!

Hiyo, Until likely and such get incorporated into the ChucK source, try this... fun int likely() { return (maybe || maybe); } fun int unlikely() { return (maybe && maybe); } It won't let you set likely or unlikely to a certain value, but as some have posted, there really is no exact value for these special words. likely() does give you a higher chance of hitting (getting true) and unlikely() has a lower chance of hitting so it does the job for me. If you want to specify how likely or unlikely something is you can also include these functions.... fun int likely(int howLikely) { maybe => int answer; for (0 => int i; i < howLikely; i++) answer || maybe => answer; return answer; } fun int unlikely(int howUnlikely) { maybe => int answer; for (0 => int i; i < howUnlikely; i++) answer && maybe => answer; return answer; } The argument passed makes the function more or less likely to return true (e.g. setting howLikely to 3 results in 93% hits, while setting howUnlikely to 3 results in 6% hits). Again, results will deviate a little over time, but I think that's desired if you're throwing words likely likely, maybe, and unlikely into your ChucK programs. I'm attaching a file that includes these methods and tests that run these methods several times, printing out the number of hits. Sorry about the copy-and-paste abuse. Below is a transcript of the log the program prints for 100,000 trials using different variations of the above methods. Best, mark RUNNING TESTS WITH 100000 TRIALS "Test 1: likely()" : (string) % hits = 0.749730 "Test 2: unlikely()" : (string) % hits = 0.251870 "Test 3: likely(1)" : (string) % hits = 0.751820 "Test 4: likely(2)" : (string) % hits = 0.876520 "Test 5: likely(3)" : (string) % hits = 0.938420 "Test 6: unlikely(1)" : (string) % hits = 0.248220 "Test 7: unlikely(2)" : (string) % hits = 0.127460 "Test 8: unlikely(3)" : (string) % hits = 0.061980 On Sep 3, 2010, at 11:48 AM, Kassen wrote:

Joe;

If we made 'likely' (and 'unlikely') chuckable that would make it nice:

.70 => likely; /* also sets 'unlikely' to .30 at the same time */

Ok, and this would be system-wide? So I could do this in one shred and have it affect others?

I quite like this idea. It's a new sort of thing, in that it would be a key-word that would act as both a variable and a function... but it's simple, intuitive and versatile. It would probably be great for live control over generative pieces with random component, where we could sort of crossfade between two kinds of behaviour.

I'd like to have this. Actually I'd like to be able to build this sort of thing myself, within ChucK.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users