[Ocaml-lib-devel] Re: Purely fonctionnal enums and ExtLib proposals

[Brian H. <bh...@sp...>]

On Thu, 29 Jul 2004, Nicolas Cannasse wrote:

> > > - maximum compliance with current enums : the "applicative enums" (let's
> > > call them purely functional) proposal is not going this way since it's
> > > modifying quite a lot current enums
> >
> > In other words, functional enums are never, ever, going to be acceptable.
> 
> That's not exactly what I said (see below).

Exactly how much compatibility is required?  My position on this is that I 
want a clear idea of where the line is drawn.  At which point I will 
consider wether it's worth my while to write the code.  I have better 
things to do than to throw code against a wall and see if it sticks.

> The exception/option problem you're raising is - if I remember correctly -
> the fact that "Enum.create" ask an unit -> 'a next method eventualy raising
> an exception while the "Enum.get" is returning a 'a option. IMHO, this
> really makes sense for performances reason and also because the people
> creating the enums and the people using them are "most of the time"
> different : for exemple you'll not rewrite your List/Array enum bindings,
> but simply blindly use them, so you only need the best performances,
> whatever the tricks of the implementation.

Yep.  You've hit the nail on the head- and here is where we part company.  
I will gladly sacrifice a fair bit of performance for design cleanliness.

The *ONLY* argument in favor of the current exception/option switch (which 
is exactly what you think it is) is performance.  So how much wriggle room 
do I have on performance?  Note that the proposal I've given actually 
makes getting the current element *faster*- IIRC from the benchmarks I did 
on the first go around, a try block cost 2.5 times as much as 
allocating a Some block- so allocating 2 Some blocks is about 4/7th the 
cost of a try + one Some block (the current implementation).  But my 
implementation allocates a new enumeration every step- which slows that 
part down.

Total slowdown?  I don't know.  But the last time we went around this 
block, the answer came back that any slow down was unacceptable.  
Performance at all costs.  Fine.  Except now we know what one of the costs 
is- people aren't using enums, and instead are using long lists, because 
they value correctness over wringing that last ounce of performance out 
of the code.

> I'm sorry I you took that remark badly, it was not the goal.
> It's actually my way of programming : when some difficult problem arise -
> and enums are a difficult problem or we wouldn't be talking now - the best
> is often to try to implement it, and see how it works. I did that first time
> with Enums, and later with IO. Then for IO I realized my design was not
> apprioriate so I made the changes : it was better when done so I was
> satisfied.

"Plan to throw one away" isn't a bad idea.  I've already thrown one away.  
The lessons I've learned lead me to beleive that were I to implement this 
idea, it'd get thrown away too.

> 
> I don't think we should keep strict backward compatibility, so if I was sure
> that purely functionnal enums would correct all the problems so I'ld say
> let's go for it ! but I'm not sure, maybe because I didn't try to implement
> them this way. I don't have a lot of time but I might try to do so, I was
> just here making the proposal that you provide us working sources that we
> can directly have a look at the impact of the changes on the API and how it
> works better.

Feel free to steal my ideas and implement the code.  The three main areas 
of improvement (in rough order of importance) are:
1) Functional, not impertive, semantics
2) Get rid of the exception/option switch
3) Seperate the "move within in the enum" behavior from the "get the head 
element of the enum" behavior.

> 
> Concerning some code you previously posted, I don't remind I said 'no' to
> some piece of code that would have stuck perfectly in ExtLib. If you or
> other people here think I didn't took enough time to watch some proposal,
> then please remind me and post it again. But since right now I'm kind of
> "benevolent dictator of ExtLib" (although I dislike the expression) I
> sometimes end up making the choices of not including some code unless I'm
> convinced, because I think it's better for ExtLib not to grow uncontrolled.
> 

Has you position that modules are bad changed?  Or would I be submitting 
the code just to have it bounce again?  Under what circumstances would 
code *not* be bounced for using modules?  Compatibility with an existing 
standard library?  Because the semantics of one or more operations stand 
to benefit from them (by enforcing ordering, etc)?  Because the author of 
the library felt that they were a good interface?  Or never?

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian