Nim: Introduce a keyword for pure enumerations

[GooRoo]

I really like that there is a distinguish between "pure" and "regular" enums in Nim. However, I don't like that one of them is made with pragma 'cause it looks ugly:

type
  Layer {.pure.} = enum
    Background, Foreground, Overlay

Seeing this {.pure.}, I feel like the language is not mature enough to spend my time on it :) Probably that's because of similarity of situation with Haskell where are lots of language extensions which can be turned on by pragmas, but the language standard has not been adopted to these changes yet. And as a user, I don't know which one will be accepted as an official part of the language and which one will not.

In my opinion, there is no reason to remove "pure" enumerations from the language ever, is it? So why not to create an additional separate keyword for this? (Especially considering the fact that "many keywords" is Nim's philosophy).

type
  Layer = pure enum
    Background, Foreground, Overlay

Choose any variant which is appropriate for you:

• pure enum (or pureenum)
• scoped enum (scopedenum – looks like some conjuration or curse in Latin)
• closed enum (?)
• enum! (Ruby-style name)
• enum class (please, no)
• whatever else comes into your mind

As for me, I would prefer to use enum! because this exclamation mark adds some strictness to the code look instantly. But I do not expect to see this in Nim as we have neither keywords with special characters nor postfix operators.

P.S. Sorry if this is a duplication of some existing issue. I believe, someone had to ask about this already.

[ghost]

As the manual states:

Pragmas are Nim's method to give the compiler additional information / commands without introducing a massive number of new keywords.

If you think this way, not liking the "cosmetics" and believe that the language ought to change to suit your "taste". Then you might not be mature enough to open issues.

Seeing this {.pure.}, I feel like the language is not mature enough to spend my time on it :)

[Yardanico]

Pure enums can be accessed without specifying enum name anyway

[Yardanico]

@GooRoo it's not good to have a lot of keywords in the language, that's why there are a lot of pragmas.
And your definition of a mature language is.. strange

[dom96]

Pure enums can be accessed without specifying enum name anyway

Really? I've seen you mentioning this once already and I remember @Araq implementing this. But it just sounds like a really bad new development to me. If that's the case then pure enums lose their use case completely!

[mratsim]

Please don't add an exclamation point !, symbols add visual noise and are difficult to google.

Also ! usually means something unsafe or non-trivial is going on (in Rust: macros, in Julia: in-place modification), pure enums shouldn't use that.

If anything I believe a qualified pragma or keyword would be better than pure.

[GooRoo]

@konqoro Yeah, maybe I'm not. But obviously Nim as a language is immature indeed as well: there is no version 1.0, no big community, no support from big company, bla-bla-bla…

I was talking rather about feeling than about the fact. In my opinion, the worst issue in any product is a user experience issue. Now, I'm the user of the language and I have some concern. For you as a contributor of the language, it's always more productive to understand the concern instead of taking offense.

You should understand that people are not coming to Nim from vacuum: they have some experience behind. I do as well: C++, Python, Haskell, etc. I already gave an example of Haskell's situation with pragmas, and in C or C++ it is not much better. In many languages _pragma is an indication that something non-standard gonna happen._ And natural reaction to this would be to avoid non-standard things in order to stay aside from some porting issues, for example.

Yes, I do know that Nim is different in this aspect because it has user-defined pragmas. But I can't get rid of my past experience so easily. That's why I'm talking about the feeling. It's more a psychological thing. And I created the issue in order to provoke the discussion.

Another questions which come to my mind are the following:

• Are there any reasons to have not-scoped enumerations at all (except similarity to C)?
• Why are not-scoped enums used by default?

I'm not the only one with such thoughts. I believe, this issue is quite similar to mine.

While in most cases it's really better to keep using pragmas, for "pure" enumerations we need an explicit syntax and compiler support IMHO.

@Yardanico Yes, I agree that "many keywords" is also bad. But Nim already has a bunch of quite doubtful ones.

@mratsim Yes, indeed. ! wouldn't look natural in Nim (at least in it's current state). I guess, qualified enum is one of the best proposals so far.

[GooRoo]

Just taken a look at @Araq's explanation of his vision of enums (in IRC):
if the {.pure.} enum can be used without prefix then it has to be the default and we definitely do not need not-{.pure.} enumerations at all. And I would really like to have such kind of unification.

[kobi2187]

The color of the bike shed should be green. wait, what are we talking about?

[GooRoo]

@kobi2187 people judge by appearance first.

I know lots of developers who don't want to learn Nim only because they don't like proc keyword.

[Yardanico]

@GooRoo that's their problem, and "function" is wrong in mathematical sense anyway.

[GooRoo]

@Yardanico I never claimed they are right.

[andreaferretti]

@dom96 I was confused as well by @Yardanico statement "Pure enums can be accessed without specifying enum name anyway", so I tried and it seems to be false (fortunately, otherwise I would nto understand the point of pure)

[Yardanico]

@andreaferretti did you test it on devel?

[andreaferretti]

Actually, I didn't. I now see that the following runs fine

type Color {.pure.} = enum Red, Green, Blue

proc print(c: Color) = echo $(c)

print(Red)

although one can reuse the identifiers as expected - the following runs fine as well

type Color {.pure.} = enum Red, Green, Blue

proc print(c: Color) = echo $(c)

proc print(s: string) = echo s

let Red = "hi there"

print(Red)

but the following fails as expected

type Color = enum Red, Green, Blue

proc print(c: Color) = echo $(c)

proc print(s: string) = echo s

let Red = "hi there"

print(Red)

So it seems that the rule is that pure enums can be used without qualification unless there is a conflict with another identifier.

I am not sure I like this, the previous way aws more clear, but I see how it can be a little more conveniente

[dom96]

@andreaferretti we discussed this on IRC. Araq has decided to essentially remove pure enums. You can see the beginning of the discussion here (I wasn't too happy about this decision either, but I must admit that it does fit the rest of the language).

So based on that I think we can close this issue.

[GooRoo]

Just to sum everything up:

My current understanding is that eventually it is planned to have something like this:

type
  Brightness = enum
    Low, Moderate, High

  Size = enum
    Small, Moderate, Big

echo Brightness.Low       # works as expected
echo Size.Small           # the same
echo Low                  # also works
echo Brightness.Moderate  # obviously works
# but
echo Moderate             # compile time error because of ambiguity

• pragma {.pure.} will have gone
• prefix with fully qualified enumeration name will be optional unless there is no ambiguity
• no distinction between pure and impure enums anymore (and that's awesome I believe)

Please, correct me if I'm wrong. Close the ticket otherwise (or should I do that?).

[dom96]

Maybe @Araq can confirm.

[trustable-code]

What GooRoo described, would be my preferred solution.

[Araq]

I can confirm what @GooRoo said.