Kas,

No, you're not misunderstanding anything!  I got a little confused...  you can do two things with chaining in chuck.  one is a double-assignment (which is what I thought was happening):

1 => int i => int j;

the other is passing args to functions:

fun int foo(int i)
{
   return i+1;
}

1 => foo;  // returns 2

but, if we did like you suggested:

fun void bar(int b)
{
   <<< "hi", b >>>;
}

then this:

1 => foo => bar;

will print "hi 2".  but what i was missing was the fact that 1 => foo returns 2 and passes that to bar.  which is different from the double assignment.  if foo didn't return an int, the above wouldn't be possible.

for instance, if foo was changed to this:

fun void foo(int i)
{
    //return i+1;
    <<< i >>>;
}

then the line

1 => foo => bar;

would fail with this error:

[Untitled 2]:line(12): argument type(s) do not match:
[Untitled 2]:line(12): ... for function 'bar(...)' ...
[Untitled 2]:line(12): ...(please check the argument types)

All I was saying originally, however, was that we should overload @=> to be able to reassign functions themselves to other references.

fun void foo(int i)
{
   <<< i >>>;
}

foo @=> fun void foo2;

1 => foo2;  // prints 1


Sorry about the confusion--I think we agree, I'm just being lazy in my explanations.  ;-)  all work and no play makes mike a dull boy.  all work and no play...

Abort, Retry, Fail,
Mike

:)
2010/1/11 Kassen <signal.automatique@gmail.com>

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.

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




--
http://michaelclemow.com
http://semiotech.org