1. 19
  1. 5

    Just started learning nim, and this looks like it solves a few of the gripes i have with the language. I’m still missing a good way of chaining iterators in a functional way without allocating a sequence for each step.

    1. 3

      I’m still missing a good way of chaining iterators in a functional way without allocating a sequence for each step.



    2. 1

      Does it have real enums and pattern matching yet?

      1. 3

        What do you mean by “real” enums? How are Nim enums deficient? (I ask as someone with only passing knowledge of the language.)

        1. 2

          Basically the “sum type” or “tagged union done right” style used by OCaml, Haskell, F#, Rust, and others. There’s nothing in them you can’t do with a C-style enum and union, but they are incredibly handy.

          1. 2

            That’s not a “proper enum”. An enum is what C and Nim call an enum, the thing you mean is (as you now correctly said) a sum type.

            Anyway, Nim has object variants.

            1. 1

              Rust calls it an enum, so that’s the first connection my brain makes. It has also been called an algebraic data type. “Sum type” is a term that only makes sense if you know the math and the particular analogy the term comes from. Long story short, there are many names for it and they all suck ass.

              Object variants do appear to be more or less what I want, done less well, so it has yet another bad name for the same feature. No pattern matching, though, so it’s like peanut butter missing the jelly. I’m actually quite fond of Nim, but I am always amazed by the ability of language designers making imperative-descended languages to entirely pass up some of the best innovations of functional language lineages.

              1. 4

                Enum stands for “enumerated”, a bunch of values associated with integers. It doesn’t make sense to use this name for sum types.

            2. 2

              Does the explanation in this article under caveats jive with your critique?


              Consider a slightly more complex sum data type in which more that one constructor carries a value, for example

              data Pair = PI Int | PD Double

              in our implementation it would correspond to:

              /* Data constructor names */
              enum pair_const {PI, PD};
              /* Actual sum data type */
              struct pair {
                      enum pair_const type;
                      union data {
                              int i;
                              double d;
                      } data;

              This is not safe, nothing prevents us from accessing .d even if type is PI, because the fields of the union are always accessible. This is what distinguishes our implementation from classic sum types in Haskell for example, in which they are safe.


              Apologies for the formatting.

              Thank you so much, @roryokane! You are too kind! Getting proper formatting on mobile was a huge pain. This looks so much nicer.