...where DIE = Divergent Implicit Expansion.

While looking at the DIE issue with mapping Enumeration values
https://issues.scala-lang.org/browse/SI-5534

I noticed that one quick fix is to make Value no longer Ordered.

My question is whether the "id" or "ordinal" for Enumeration.Values should
be internal detail.  By extension, we can remove Ordered.  I moved the
Ordering[Value] to a related companion class.

As an example, Reporter.Severity is a Value used just as an int wrapper. I
had to add Ordered back to Severity for INFO < ERROR tests.

I reread the DIE page of the spec, combed through the -Yinfer-debug, and
more/less understand what's intended by the newCBF for SortedSet.  However,
my understanding is only 66% so far on the implicit problem, so I don't
want to suggest that this is the optimal fix.

Also of interest, ValueSet uses an underlying BitSet, so you lose a bit of
range:
https://issues.scala-lang.org/browse/SI-6094
but probably ValueSet doesn't want to create sparse BitSets with huge
ranges anyway and should switch to a different representation after a
relatively small topId - bottomId.

If ids were only ordinals, with bottomId always zero, the conceptual model
would be as simple as it really is.

scala.Enumerations have caused nothing but trouble as far as I can think
back ... I wonder when it is finally enough and Scala will just use the
JVM's/Java's enums. Maybe macros will get us a lot closer to some sane,
interoperable solution by synthesizing the appropriate methods, just like
javac does.

On Sat, Oct 20, 2012 at 3:03 PM, Simon Ochsenreither <

I should add that while I understand this point of view, in the subject
line I was only being flippant (which I hope has nothing to do with
flipping off, but one can't be sure about French terms).  Or maybe the word
is glib.  Let's say, flib, which is a flub that went over the top.

I actually like Enumeration as a showcase module.
http://www.artima.com/pins1ed/abstract-members.html#20.8

It's been hard to get exactly right, but only in a good way.  The last
issue was, "Enum doesn't know how to compare two ints."  Enumeration really
deserves its own section on Scala Puzzlers.  As the other thread on enums
and case objects shows, there should be a whole other section on enum
alternatives.

I was kind of surprised that paulp hasn't taken a big hammer to
Enumeration, but I just checked the history and there's a "Fix for
Enumeration" followed shortly thereafter by a 'Revert "Fix for
Enumeration".'   Just because a task is difficult and thankless, doesn't
mean it's not worth trying.

In the current issue, the set of values became a sorted set, and the code
was made to imitate BitSet (which it happens to use under the hood).
BitSet works nicely as a SortedSet[Int], but ValueSet as SortedSet[Value]
demonstrates this glitch.  (Because Value is Ordered, and Pair[Ordered, _]
picks up the implicit that seems to DIE.)

For me, the motivation is to understand implicits, the Ordering apparatus,
and how to extend collections.  I think that may rate a puzzler.

On Sun, Oct 21, 2012 at 12:03 AM, Simon Ochsenreither <

You can use Java enums. But Scala will never have them.

I have to repeat my mantra once more here: My intention is to make Scala a
simpler language, with fewer features, not more. Most of the discussion on
the Scala lists goes the other way, where everyone is rooting for just one
more essential feature. That's only natural. But I have by now developed a
high level of resistance to most of these proposals.

Cheers

 - Martin

Hi Martin,

I think we are in perfect agreement on that!

I just assumed that Scala absolutely needed some native, Java-enum-like
replacement. If that's not the case and using Java for this purpose is
considered fine, forget about my considerations on how to implement
Java-compatible enums in Scala without introducing new features.

Let's deprecate scala.Enumeration in 2.11 and guide people either towards
Java's enums or Scala's ADT-like approach.

One feature less, less bugs, less confusion on what to use (see
https://groups.google.com/d/topic/scala-user/2g-qzsfE0Us/discussion,
https://groups.google.com/d/topic/scala-user/2ZiLW92ieq4/discussion),
better interop and no need to duplicate APIs for Java/Scala enums.
(Considering the usage on scala.Enumeration in the wild, it seems people
already voted with their feet, too.)

Thanks and bye,

Simon

On Sun, Oct 21, 2012 at 1:10 AM, martin odersky <martin.oder...@epfl.ch>wrote:

This seems like a questionable example of people rooting for one more
feature; the primary thing being rooted for when it comes to
scala.Enumeration is its removal. I thought leveraging java's existing and
satisfactory solutions where possible was scala's thing.

Particularly since 2.10 is meant to include exhaustiveness checks for Java
enums too.

Best,
Ismael

I think Enumeration works fine for what it's supposed to do: Provide
enumerations without the overhead of one class per value. It beats the
alternative of defining numeric constants, for sure.

Cheers

 - Martin

On Sun, Oct 21, 2012 at 12:05 PM, martin odersky <martin.oder...@epfl.ch>wrote:

Two classes per value, usually, not that case objects are the only
imaginable alternative.  But "works fine" is one of those subjective
things.  I like my scala features to work at least as well as the java
feature they are reimplementing.  By that standard it does not rise to the
level of fine.

zero). Enumerations in Java are quite enormous, similar in complexity to,
say, traits in Scala.  Is the convenience really worth it?

Cheers

 - Martin

As far as I have understood it, people in this thread are arguing to get
rid of scala's bug-ridden, non-interoperable implementation in favor of
just using Java's enums, not about changing Scala-the-language to add
anything to it.

The convenience of not having to deal with scala.Enumeration and the poor
souls who fell into the trap using it has no impact on the language
footprint, but imho a lot of positive impact on people learning Scala.

On Sun, Oct 21, 2012 at 3:05 PM, martin odersky <martin.oder...@epfl.ch>wrote:

class per value. It beats the alternative of defining numeric constants,

Well, occasionally I suppose it does.  It's integer-only (numeric constants
are not), boxed (numeric constants are not), and allows (at compile-time)
but breaks on repeated values (numeric constants allow repeats and do not
break):

    object Wrong extends Enumeration { val a,b = Value(2) }

It can't check for complete pattern matches (unlike the case where classes
are used), and admits various weird usages that fail at runtime:

    object Okay extends Enumeration { val c = Value }
    object Uhoh extends Enumeration { val d = Okay.Value }

And although it doesn't add to the _language_ complexity, it does add to
the _library_ complexity.  It's amazing that it works at all, but even so
it doesn't work very well.

In practice, between needing byte and short and floating point constants,
and needing pattern matching, and needing bitmasks for which Enumeration
generates the wrong progression, I hardly use it at all.

I would use it more if it was something like

class Incrementable[T](val zero: T, val inc: T => T) {}
abstract class Enumeration[T: Incrementable] { ... }

  --Rex

Yeah, that's been my experience as well. Ugly-but-verbose numeric
constants are reliable, represent the (unboxed) values and types I
need, and be be easily inlined if that's what I want.

-- Erik

Enumeration comes with a usage pattern. If you use it wrongly, it breaks. I
do not see much that's wrong with that. If you use the wrong numeric
constants (ie the same one twice) your program will break as well. And that
is usually harder to guard against than just writing

  val a, b, c = Value

To each their own. People who do not like enumeration do not need to use
it. Sometimes numeric constants are better. But if you do not want to watch
out for duplicate values manually,
and you do not need utmost performance, enumerations are nice.

Cheers

 - Martin

Note that java enums only map to ints as well.

But to

--
Martin Odersky
Prof., EPFL <http://www.epfl.ch> and Chairman, Typesafe<http://www.typesafe.com>
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

Hi,

Enumeration comes with a usage pattern. If you use it wrongly, it breaks. I

I honestly can't remember scala.Enumeration's "right" usage without looking
it every time I considered using it. That alones leaves a very bad taste.
Java managed to completely prevent this problem of "wrong usage patterns".
To this day, I haven't seen a definition of Java's enum which both compiled
_and_ broke at runtime.
Why would we consider less than this acceptable for Scala?

If you use the wrong numeric constants (ie the same one twice) your program

The issue, as far as I have understood it, is that people actually choose
to go back to some less expressive and less semantically exact code instead
of using Scala's Enumeration.
The only "static final int"s I see in Java are pre-enums. It seems that
Scala's Enumeration didn't even manage to solve this basic requirement in a
way people would actually want to use it.

To each their own. People who do not like enumeration do not need to use

Sometimes numeric constants are better. But if you do not want to watch out
and you do not need utmost performance, enumerations are nice.
With type aliases and value types there are even more options for safe,
declarative code, but I think that's besides the point.
scala.Enumerations doesn't seem to solve any actual issue and has all the
drawbacks of not being a java.lang.Enum (like in annotations).
People who want to use enumerations should use Java enums, they don't
deserve that we waste their time with scala.Enumeration. So can we get rid
of scala.Enumeration, please?

Thanks and bye,

Simon

On Sun, Oct 21, 2012 at 5:38 PM, Simon Ochsenreither <

Can we try rewriting it first, taking advantage of the huge increase in
experience with writing reliable Scala library code and experience with the
difficulties of the existing version?

Or maybe wait until we have a proper units system--if we're going to get
one--so that we can leverage that for type-safety?

  --Rex

That's what I proposed in the first comment, but that was shot down. Also,
I don't see how we could make scala.Enumeration a Java enum without tons of
macro magic. In the end, it would be more like some Scala-like DSL where
the macro would completely rewrite the tree of the "enum declaration". This
couldn't be done with method-level macros, we would probably need macro
types or macro annotations for that.

Well, you proposed a specific rewrite for it, which was basically to use
macros to mimic Java enums, which was shot down.  Even without going that
far, one could make some significant improvements--not to Java interop, but
to robustness, flexibility, speed, etc. (not all at once--one would need to
decide what to target).

  --Rex

On Sun, Oct 21, 2012 at 6:04 PM, Simon Ochsenreither <

If the rewritten scala.Enumeration isn't compatible with Java enums, why
even bother rewriting it? I prefer a useless implementation with known bugs
to a useless implementation with unknown bugs.
There is a reason why practically no-one uses scala.Enumeration and
"incompatible with the platform' idea of enums" and "buggy" rank pretty
high on my list of suspects.

Nothing against a bit of NIH, but there is only one valid definition of
"enum" and that's the one of the JVM. If the JVM tells me "no, that's not
an enum, I won't allow you to use this in an annotation" I don't care about
Scala's reason for failing to work as expected.

Thanks and bye,

Simon

On Sun, Oct 21, 2012 at 6:56 PM, Simon Ochsenreither <

So you don't think it's possible to write less buggy/non buggy code?  Why
write anything?

Okay, so, kind of a straw man--I take it that you mean that platform
compatibility is an essential requirement for you.

Reinforced by this point.  If you want Java enums, using Java is a pretty
sensible option.  But I don't personally miss being able to stick a Scala
Enumeration in a Java annotation.  >90% of my use cases is not creating new
annotations.  Unsafe numbering, namespace pollution, ints-only (see classic
java "Planets" example for what you can't do in Scala), etc. each chip off
a big fraction for me.  I'd be happy to have something better (c.f. "The
great is the enemy of the good.").

  --Rex

My point is that given the constraints it is obvious (imho) that
scala.Enumeration can't be fixed to justify its existence, not even
remotely.

What's the value added by not being compatible with the platform's idea of
enums?

I certainly don't miss scala.Enumeration. It does neither anything well nor
anything better than Java enums. It's usage is non-obvious and confusing.

Unsafe numbering, namespace pollution, ints-only (see classic java

Which of these points is not already adressed by Java enums? How is some,
potentially future version of scala.Enumeration improving on what Java's
enum did reliably and painfree for the last 8 years? Why or who would want
to wait for it at all?
I think the fact that people abandoned scala.Enumeration in favor of
integers and fields speaks lengths about the situation. Why not put an end
to this suffering, get rid of Scala.Enumeration and give an official
blessing to Java enums?

Every scala.Enumeration value having the same erasure, which for most
people is a discovery not to be made until after they've boxed themselves
in.

scala> object Foo extends scala.Enumeration { val A, B, C = Value }
defined module Foo

scala> object Bar extends scala.Enumeration { val A, B, C = Value }
defined module Bar

scala> def f(x: Foo.Value) = 1 ; def f(x: Bar.Value) = 1
<console>:9: error: double definition:
method f:(x: Bar.Value)Int and
method f:(x: Foo.Value)Int at line 9
have same type after erasure: (x: Enumeration#Value)Int
       def f(x: Foo.Value) = 1 ; def f(x: Bar.Value) = 1
                                     ^

I think the answer to this will one day come as an independent library
(maybe using macros) which will be used by the community. Something like
Akka for actors.

In our project we need to translate the enums - provide texts for the
values. In Java what we have to do is to add an extra line into enums,
like:

public enum AddressStatus implements EnumClass<AddressStatus>
{
    ...
    public static final EnumMetaClass<AddressStatus> meta =
EnumMetaClass.create(AddressStatus.class, "i18n.app");

This is something what can be done much better in Scala. You can't easily
add functionality to Java enums. So, to say "just use Java enums" is not a
good solution.

Second, we need to customize the enumerated value (add fields, not just one
string). This is something you can't do with scala.enum, but with java enum
you at least have to write the fields + constructor (assign fields). In
Scala this would look nicer.

Third, we don't need complex numbering, built-in ordinal as in Java enum is
just fine. Rest is done with fields - constructor params.

So, I took the enum from V. Klang and adapted it to our needs. I think, in
the meantime, there exist dozens of house-local enums out there.

My point is, I think there is a need for Scala enum, just not the current
one. I mean enum as library, not language built-in.

Regards,
Jan

On Mon, Oct 22, 2012 at 2:09 AM, Simon Ochsenreither <

I'd like to chime in on the anti- scala.Enumeration camp.

My point is slightly altered from others:  scala.Enumeration doesn't feel
like it belongs in Scala.

If you look at all the other instances of "just a library" for scala, like
beakables, actors, futures then you see a nice, elegant abstraction that
solves a domain well, is performant at runtime, and "fits" into the
language as if it were native.

Enumeration is not.  If you look at its usage pattern it is different from
any other thing in the standard library, violates many of the common scala
idioms.   While enumerations tend to do this in any language, I think those
in Scala's library are a good idea gone poor.

I believe Viktor Klang had a toy replacement that was far more *runtime*
safe and performant and unified with case classes.  This I could get behind
as more "regular", adding features that feel more natural.   Placing a
sealed set of case objects in another object is not as foreign as calling a
`Value` method to create one or more instances.  During training we often
have to wave our hands here and encourage folks to investigate later.

Here's the crux of the complaint against Enumeration:

(1) toString is not the common way of pulling *data* out of an object (I.e.
the name member).
(2) Cannot easily extend enumerated type with additional members.  All new
behavior in the containing object.
(3) Implementation practically requires you to use it as top level object,
not inside a class or trait.
(4) Does not feel like a set of case object/classes, the major pattern in
scala used with pattern matching.

Basically, enumeration always feels like something unnatural, both as a
library in the standard, and something the language would support.

I don't even care about java interop here.   I'm not about to say we need
compiler support.   However I think the current library is lacking.   If
you would entertain improvements, I think we could make them.

If the main goal was avoiding more classes, then perhaps we've succeeded.
However, when I have an ich I want to scratch with enumeration, the current
library is a thorny branch, when I just want a nice stick.   I seriously
think we should consider improvement here.
On Oct 21, 2012 4:22 PM, "martin odersky" <martin.oder...@epfl.ch> wrote: