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

Re: [Sc-devel] Function:next :asStream

Hi Scott,

That is a good question!  I thought I knew the answer, but decided it would take poking around to see what is actually being done.

The general answers that came to mind:

Currently there are no implementations of 'next' that take more than one argument.
'next' is part of the Stream interface.  
If Function:next were the same as Function.value then Function.embedInFunction should probably be { | ev | ^this.value(ev).yield }
This makes it marginally more difficult to define a pattern whose values are Functions. (You would need to add another set of braces
around each function.)

Here is some data from munging around in the class library:

There are 92 classes that implement 'value', almost all use Object's implementation of next.  Here are the exceptions (class that defines value followed
by class that defines next):

[ Ref, Maybe ]
[ MXHIDSlot, MXHIDRelSlot ]
[ Editor, EnvEditor ]
[ Editor, Editor ]
[ MXHIDSlot, MXHIDSlot ]
[ Position, Position ]
[ Instr, Instr ]
[ Thread, Thread ]
[ MXHIDSlot, MXHIDLedSlot ]
[ Ref, Ref ]
[ Routine, Routine ]
[ Stream, Stream ]
[ Ref, FuncProxy ]

Of these, only Position and Instr do anything out of the ordinary.  Position is advanced by next while value returns the current position.
Instr expects an array of arguments for value (almost certainly an error since it also responds to valueArray).

(i haven't had the heart to go look at all the other classes that implement value to see what is going on there.)

Below is a list of classes that implement 'next' and what class implements 'value'.   The first 9 do not conform in some more or less significant way
to the convention that next is equivalent to value.

[ Object, LinkedListNode ] // next is a link
[ Object, Tempo ] // next streams the tempo
[ Object, Meta_Tempo ] // ditto for Tempo.default
[ Object, Meta_UniqueID ] // ID allocators
[ Object, PowerOfTwoBlock ]
[ Object, SerialPort ]

[ Position, Position ] // next advances the position, value returns current position
[ Instr, Instr ] // value expects an array of args, next doesn't
// possible mistake as there is valueArray as well
[ Thread, Thread ] // explicitly set to return Thread in response to value

[ Object, Event ] // these return a copy in response to 'next'
[ Ref, RefCopy ]

[ Object, Object ] // these all conform to the next <=> value convenntion

[ MXHIDSlot, MXHIDSlot ]
[ Routine, Routine ]
[ Editor, Editor ]

[ Stream, NAryOpStream ]
[ Stream, BinaryOpXStream ]
[ Stream, EventStreamPlayer ]
[ Stream, CollStream ]
[ Stream, UnixFILE ]
[ Stream, StreamClutch ]
[ Stream, OneShotStream ]
[ Stream, BinaryOpStream ]
[ Stream, UnaryOpStream ]
[ Stream, EmbedOnce ]
[ Stream, FuncStream ]
[ Stream, PauseStream ]
[ Stream, Stream ]
[ Stream, CleanupStream ]

[ Ref, Ref ]

Here is how I looked for them:
a = Class.allClasses.collect { | c | 
var m;
m = c.findRespondingMethodFor('value');
if (m.notNil)
{ m.ownerClass }
{ Object };

b = a.collect { | c | 
var m;
m = c.findRespondingMethodFor('next');
if (m.notNil)
{ m.ownerClass }
{ Object };

On Dec 19, 2007, at 8:06 AM, Scott Wilson wrote:

When learning SC I'd thought that 'next' was mostly just intended to be a semantically suggestive synonym for 'value'. (Routine doc suggests this...)  What is the distinction between the two? I can see cases like in Event, where you get a copy with next but not with value.


On 18 Dec 2007, at 22:05, ronald kuivila wrote:

Hi guys,

One argument for the current policy is to claim that next and embedInStream should describe similar sequences.
Function:embedInStream needs to return the function rather than its value. If not, patterns could not define sequences
 of functions.

Of course, embedInStream defines a one element sequence while next returns an infinite sequence, so 'next'
and 'embedInStream' are already different.

And Functions cannot embed other Streams (you need a Routine), so it is already a special case.

I find it tempting....


On Dec 18, 2007, at 11:45 AM, James Harkins wrote:

I think next should do the same thing as value against functions.

Among other benefits, you wouldn't need to write Pfunc() all the time.

Pbind(\freq, { ...})

That would make some things a whole lot easier for me.


On Dec 18, 2007 10:27 AM, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
Is there a reason why Function:next should not be a synonym for
'value'? (Something to do with the need for FuncStream?)

I've just come across the issue of when next and value are really
interchangeable in a chapter for the book.

Similarly, Function:asStream returns the function itself.

James Harkins /// dewdrop world

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman
Sc-devel mailing list

Sc-devel mailing list

Sc-devel mailing list