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

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



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


--





.