Re: [Ocaml-lib-devel] Enum API change: export next

[Brian H. <bri...@ql...>]

Blech.  I just realized that many (most?) of you are in France- like 6-7 
hours ahead of me.  And that by the time I submitted anything on Friday 
you had all gone home for the weekend.  My apologies- I'll unroll the 
changes.

On Mon, 21 Apr 2003, Nicolas Cannasse wrote:

> > We're already exporting count, export next as well.  Why I want this will
> > be clear in a moment...
> 
> Ok, but I don't agree :
> 
> I do understand that you want to remove 'magic' calls from the ExtList, but
> actualy, the problem is that we are already doing magic calls in setcdr, so
> why would we need to add a primitive to Enum for that ? But that's not the
> main problem... The problem is that WE SHOULD NOT export next since :
> 
> 1) its semantic it is not really defined, and Enum.next does not make sense
> since 99.9999% of the time you're applying the same function to all elements
> of the Enum.

The other 0.0001% of the time, you're screwed?  And I think it's more like 
99.9%/0.1% of the time- the difference is important, it's rare but it 
happens.  As for the semantic being not really defined, a) I thought it 
was obvious, and b) this is a problem.  If I, joe ocaml programmer, don't 
know what the semantics of next is, then I can't define a new Enum.  Which 
means I can't define a new Enum of my new data structure.  Personally, I 
don't think the semantics of next are *that* complicated, and should be 
that hard to define.

> 2) I don't want beginners start programming using  while Enum.has_more e do
> let x = Enum.next .... done because it's really a BAD WAY ( Java like ) of
> working with enumerations (and it's involving a call to count each time ! )

a) I actually had an idea for this: have Enum.make take three functions- 
next, count, and has_next.  This cleans up a lot.  Especially a lot of 
places where we need to catch exceptions to detect the end of the list.  
This at least gets rid of calling count each time we call has_next.  As it 
stands, has_next is nigh unto useless.

b) So, being Java like in calling extensible arrays Vectors is good, but 
allowing Java like Iterator code is bad?   Of the two, I'll take the 
iterator code.

> 3) There is big problems of exception scoping !! that's the major fact why I
> hided Enum.next :
>     for example an user could do Enum.map with a function that is using
> Enum.next, and then call for example Enum.iter on it... if the user-defined
> map function raises No_more_elements ( because the user didn't check
> properly for it, or because he simply wants to catch the exception at an
> upper lever ) then this exception will be catched by Enum.iter which will
> simply ignore it and stop.... Serious problem here for debugging big piece
> of codes !

Having an efficient has_next allows us to move away from using exceptions 
to detect the end of the list.  So, Enum.iter could then be defined as:

let iter f e =
    while (has_more e) do
        f (next e)
    done
;;

Now, the exception really does mean an exceptional event has happened- 
either has_more lied to us, or we have some sort of race condition and 
some other thread read the last element between our calling of has_more 
and our calling of next.  Both rare occurances.  And should, for whatever 
stupid reason, f raises No_more_elements the exception gets passed along.

But I'm not too worried about f raising No_more_elements.  I find that 
unlikely.

> Sorry not to have talked about theses points before, but please revert the
> changes since I'm feeling really about this addin' :)

I will.  I'm not giving up the debate however! :-)

Brian