Re: Enums vs. Algebraic Datatypes

> client code if EXIT/NO_NOTHING/HIDE are not predefined:
>     w.addWindowListener(windowClosing: WindowEvent evt => System.exit(0));
> 
> client code if they are predefined with type WindowEvent -> void:
>     w.addWindowListener(windowClosing: EXIT);
> 
> I personally think that the third version (without setDefaultCloseOperation) is
> the best design. And it also encourages people to utilize the open class /
> multimethod features of Nice.

I agree, this looks like a good and simpler design.

> So I don't think you can say that enums are closed unions; they may be closed
> for extension by other packages but the original author can always extend them.

That's what is meant by closed: that other packages cannot add other cases. In 
many situations, that is an issue, either because you are not the author and you 
cannot change the original package, or because the extension only makes sense in 
a particular context, and you want to share the base code with other 
projects/contextes.

> That is what makes switch a problem. It seems to work well for ML because ML
> systems have their linking done (primarily) statically so it easy to find client
> code that needs to be recompiled when an algebraic datatype is extended. I don't
> think it would work well for JVM-based languages because the final linking is
> done dynamically and so such errors wouldn't be detectable until runtime. But, I
> guess that is not any different than the same situation you have with Nice's
> normal method dispatch. 

Right, it's the same situation.

>>>My attempts to use enumerations in my Nice program have been thwarted by
>>
>>their
>>
>>>limitations: (1) Enumeration types cannot extend an existing class
>>>
>>
>>We might be able to allow that. On the other hand, it seems it would 
>>prossibly create interoperability problems wih Java 1.5 code.
>>
>>
>>>and (2)
>>>Enumeration types are not full algebraic datatypes in the sense that they
>>
>>are
>>
>>>not "simply" descrimined unions but rather a fixed set of constant values.
>>> 
>>>
>>
>>Could you precise what you mean by this? Is it the absence of a 
>>switch-like (match in OCaml) statement?
> 
> 
> I was speaking of basically the ability to do this (from the wiki):
> 
> class Expression = 
>     Variable { String name; }
>   | Lambda   { String var; Expression body; }
>   | Apply    { Expression function; Expression arg; }
>   ;
> 
> In particular, the ability to give different fields to different labels of the
> enum. And then instantiate e.g. "Apply" multiple times with different values for
> "function" and "arg".

OK. It should be possible to support that too. That does not seem to be in the 
Java proposal, so interoperability would again be a question.

Keep in mind that enums in Nice are rather new, so they still need maturing. 
Proposals and contributions are welcome.

On the other, it's true one can discuss if their presence is justified. If you 
see them as a special notation to declare many related classes or instances, 
they don't complexify the language too much (as they can be explained by their 
translation), and they come in handy in some situations. From the Java enum 
proposal:
   public enum Rank { deuce, three, four, five, six, seven, eight, nine, ten,
                      jack, queen, king, ace }
might be a good example, no?

Daniel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn