[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] Function:next <=> Function:value?



Hi Julian, James, and Scott,

  I think I agree that we should not do it.  I think having functions
behave differently inside an event from inside a pattern definition is
just too confusing.

  Instead, we could add a convenience method Function:p or Function:pat to
wrap it in a Pfunc.

 But I do wonder if making the change would break a lot of code  It would
actually be interesting to know where Functions get called with next.

RJK
> Hi Ron,
>
> ok, I see. Actually I have the feeling that this could break a lot of
> code and be very hard to track down. One other disadvantage is that
> you can't pass functions as objects in patterns any more, or as you
> say, you have to create new function instances all the time due to
> wrapping.
>
> When I implemented embedInStream for Ref, I later thought it may have
> been a bad idea for the same reason, and always thought, well we
> still have function..
>
>
>
>>Hi Julian,
>>
>>   The question was: should Function:next by made the same as
>> Function:value?
>>
>>   The advantage is it eliminates the need for Pfunc.
>>
>>   The disadvantage is that Patterns that define streams of functions
>>need to be wrapped with another brace.
>>In particular,  if you want to bind a key to a function in Pbind it
>>requires two sets of braces, not one set.  This has
>>some nuances - function/streams get the event as an argument;
>>function/stream values execute within the context of the
>>event.
>
> ther are a couple of nuances currently:
>
> Pfunc
> Pfuncn
> Plazy
> PlazyEnvir
> PlazyEnvirN
>
> they seem to have equal relevance somehow, depending on the context.
>
> I tend toward keeping the difference between "next" and "value"
> despite the need for explanation.
>
>
>>
>>
>>  RJK
>>
>>
>>PS:   This led to the larger question of when is next not the same
>>as value?  By default, they are the same for both Objects and
>>Streams. The best example I found was crucial's Position where value
>>returns the current position and 'next'
>>advances to the next Position.
>>
>>   But there are a number of classes that redefine next and leave the
>>default value that I did not have the time to look at in detail.
>>It would be worth munging through to see where else the distinction
>>is significant.
>>
>>RJK
>>
>>On Dec 21, 2007, at 8:00 AM, Julian Rohrhuber wrote:
>>
>>>>Hi Scott,
>>>>
>>>>   Since there have not been objections, shall we do this?
>>>
>>>sorry, could you describe again what you are up to?
>>>
>>>I couldn't follow the thread and I don't know what the conclusions were.
>>>--
>>>
>>>
>>>
>>>
>>>
>>>.
>>>_______________________________________________
>>>Sc-devel mailing list
>>>Sc-devel@xxxxxxxxxxxxxxx
>>>http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>>>
>>
>>_______________________________________________
>>Sc-devel mailing list
>>Sc-devel@xxxxxxxxxxxxxxx
>>http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>
>
> --
>
>
>
>
>
> .
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>
>