Mike

1 => foo;

this is sane,

Agreed.

but this isn't:

1 => foo => bar;

foo(1) is the same as 1 => foo

foo => bar is the same as bar(foo)

Yes... But look at this;

60 => Std.mtof => my_osc.freq;

That's good ChucKian form, I'd say. It's compact, it's coherent and it's very readable, almost like a chronological sentence, like "I put on my coat and went outside"

however, I was suggesting that I could assign the object/function foo to reference bar this way:

foo @=> bar;

which means this:

1 => bar;

would now return 3 because bar is now a reference to the same function foo is a reference to.

see what I mean?

Yes, I do, but when functions become objects then the code becomes ambiguous for overloaded to take both functions and integers as parameters. If my_osc.freq above would be overloaded to also take functions as a argument then that line become a bit like "I was walking my dog when I met a girl, then I brushed her hair.". That sentence might mean I brushed my dog or I might have brushed the girl's hair. You and me would probably never use a sentence like that because it's asking for misunderstandings, but it's perfectly fine English. Formal languages should really not have that sort of sentence, I feel, and I don't see how we can get around this with your plan as it stands.

I'm certainly not saying here that I think functions as objects or as arguments are inherently a bad idea, in fact I think it might be a very good one. As it stands, though, I think your proposal has some issues and I wouldn't like to break or lovely feature of chaining function-calls into single lines of code where that makes sense.

Are we on the same page again? Am I still misunderstanding something?

Yours,

Kas.