Re: enum protocol suggestion

[Smelly Pooh <plop+goo@xxxxxxxxxxxxxxx>]

In reply to Jonathan Bachrach's flatulent wordings, 

> > Methods like now-key and now-setter do not belong in an enumerator.
> > They assume that you are dealing with a collection, which is not
> > necessarily the case (for example when using <range> as an enum)
> 
> perhaps this just argues for different classes of enums.  i was trying
> to not have too many classes.  i figured that they could go
> unimplemented for collections not supporting this bit of protocol. 

This brings me to something else I was thinking about.  With the
generic functions style of OO it's very hard to enforce a protocol at
the language level (since new generic functions can be added at any
time).  As goo's protocol family increases, how will one know what
methods need to be implemented and what methods don't to conform to a
protocol?  It makes me uneasy to half implement a protocol because I
don't know where it'll work and where it won't work

> > With a few minor changes enum could be used as a generic lazy iterator,
> > much like the stream type from ML or generators from python
> > (http://www.python.org/doc/2.2.2/whatsnew/node5.html)
> > 
> > I believe that an enumerator should simply be a thunk.  Each time the
> > thunk is called it returns the next item in the enumerator (keeping
> > state in a closure if necessary) until it reaches the end of the
> > enumeration, in which case an <enum-end> condition is signalled
> 
> i'm definitely sympathetic to this, but i too am reluctant to use
> conditions to signify end of enumeration.
> 
> perhaps a better solution is to introduce convenient syntax for
> defining these enums.  i haven't yet worked this out, but this has
> been the plan all along.

Perhaps a syntax for inner/anonymous classes?

(anon (<enum>)
  (dm fin? (_) ; code)
  (dm nxt (_) ; code)
)

which defines the methods fin? and nxt on anonymous class _
and returns an object of type _

I think nxt and now should be the one method unless there's a reason to
split them

(rep loop (enum)
  (unless (fin? enum)
    (nxt enum)
    (post "%s\n" (now enum)) ) )

is less elegant than

(rep loop (enum)
  (unless (fin? enum)
    (post "%s\n" (nxt enum)) ) )