Re: Enums vs. Algebraic Datatypes

> >Just came across a situation where it would have been nice to define
> >an enum that extended an enum

> That's another issue and more difficult. What would the typing
> relation between the enums be?
> The extending enum can't be a subtype of the base enum because then
> you could pass elements of the extending enum to a method expecting
> element of the base enum which would be unsafe.

Maybe this is just a case of someone trying to use previous programming
habits without understanding if they were appropriate in Nice, and then
suggesting a change to the language :-)

By accretion I've developed a preference for matching on objects rather
than strings. 

If I choose to match on strings in Nice multi methods then there's no
need to have an enum or therefore to extend an enum in subclasses. If I
want to control what strings can be used with the object then I can
provide a method interface for selecting particular strings (which can
then be extended by subclassing, and extended by adding external
methods). In short, what I was doing would be a lot more extendable
without using enums.

> I agree with more emphasis on the features most users are not
> familiar with (at least in the documentation).

Maybe this goes to the heart of language design suggestions as well. 
Without experience of working with multi methods and external methods,
the suggestions we make about language features are part of our
response to deficiencies in some other language - maybe the first
respone should be "How would you do that with multi methods?"

So it's more than education, it's about how we position Nice, what
design styles are made easy, what design styles are deprecated.
 
> > some of it has to do with development priorities
> We don't have a list with priorities it depends on the amount of work
> to implement/fix something and user feedback is a big factor.

Maybe it would be better to have a top 5 development priorities


> What are your obstacles in using Nice? 

documentation, documentation, documentation ;-)

Maybe confusion about what kind of language Nice is - a Java 1.6, an
OO/Functional hybrid, a multi method language - there are too many
themes. It would help to understand what position Nice takes compared
to other languages - Java 1.5, Multi Java, Scala, Groovy.

> And which features would you give a high priority?
- visibility controls
- type system (understanding/removing limitations)
- performance of multi method dispatch? (don't know if it's good or
bad, but if we're to use multi methods it needs to be good)
- type system (local type inference)
- type system (extending checks on option types)

(which is to repeat what Brian said "play to your strengths" - multi
methods, MLsub)

best wishes, Isaac

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/


-------------------------------------------------------
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