[chuck-users] wishlist for the new year

[mike clemow]

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 at 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>


-- 
http://michaelclemow.com
http://semiotech.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100111/cd3cd60a/attachment.html>