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.