c2hs produces crashing Enum instances for any non-contiguous enum

[merijn]

The enum instances generated by c2hs only define "toEnum :: Enum a => Int -> a" and "fromEnum :: Enum a => a -> Int", relying on the built-in definitions of succ, pred and enumFromTo, however all these built-in functions assume that an Enum matches a contiguous range of Int.

C enums on the other hand don't have this requirement. As a result the generated instance will crash for the Enum instances generated for any such enum. Simple example:

enum HaskellCrasher {
Foo = 1,
Bar = 3,
Baz = 5
};

Trying to call "toEnum 2", will crash. As a result, so will "enumFromTo Foo Baz".

[ian-ross]

Any thoughts on how to deal with this? It's a case where C enums and Haskell Enums don't really match up very well...

[merijn]

Well, the simple solution is to generate a more verbose Enum instance. i.e. instead of generating just:

instance Enum HaskellCrasher where
    toEnum 1 = Foo
    toEnum 3 = Bar
    toEnum 5 = Baz

    fromEnum Foo = 1
    fromEnum Bar = 3
    fromEnum Baz = 5

c2hs should also generate implementations for the function that are potentially partial, i.e.:

    succ Foo = Bar
    succ Bar = Baz

    pred Bar = Foo
    pred Baz = Bar

   enumFrom Baz = [Baz]
   enumFrom x = x : enumFrom (succ x)

   enumFromTo Bar Foo = []
   enumFromTo Baz Foo = []
   enumFromTo Baz Bar = []
   enumFromTo x Foo =
      case x of
         Foo -> [Foo]
         _ -> x : enumFromTo (succ x) Foo

   enumFromTo x Bar =
      case x of
         Bar -> [Bar]
         _ -> x : enumFromTo (succ x) Bar

   enumFromTo x Baz =
      case x of
         Baz -> [Baz]
         _ -> x : enumFromTo (succ x) Baz

This doesn't fix enumFromThen and enumFromThenTo, which can probably be implemented non-crashing, but I can't be arsed to think of how at the moment.

[ian-ross]

That's a sensible approach, but it still makes me a little uncomfortable, for a number of reasons. (Mostly because I can't but feel that Haskell Enum and C enum just aren't that great a match.)

It might make more sense if there were two Haskell classes, a superclass for types with only nullary constructors where there's a well-defined mapping from constructors to integer "values", and a sub-class representing values for which the arithmetic sequence constructs make sense. Even in this case, things aren't that great. C enums support aliases, i.e. multiple names for the same integer value, which means that fromEnum isn't bijective and also makes it unclear how to define Eq and Ord instances for these things. If the C enum defines two names for the same value, should the corresponding Haskell constructors compare equal or not? That even makes defining good versions of succ and pred difficult, of course. Given the C enum (abstracted from an example from the cuda library):

enum foo {
  A = 1,
  B = 2,
  C = 2,
  D = 3
};

what should succ A return? Or equivalently pred D?

I also worry that 'enumFromTo' and friends don't make sense for a lot of C enums: think of the common case where the C enum values are bit flags, defined as

enum foo {
  BAR = 1 << 0,
  BAZ = 1 << 1,
  ...
};

You could certainly write definitions of enumFromThen and enumFromThenTo for these arbitrary Enum types (I guess you'd have to apply succ repeatedly to the "from" value to find how many steps it is to the "then" value), but would they be useful?

On one other point, I think that in your first example toEnum 2 should crash: the Haskell type should also be an instance of Bounded, and the standard says that toEnum should throw an error for bounded enums when given a value that doesn't correspond to any of the type's constructors. C2HS doesn't define Bounded instances for these things at the moment, but it could (and probably should).

Anyway, I'm happy to add code to generate more comprehensive definitions for the Enum instances if we can come up with some agreed way to do it. I have a related bug (#79) I'm going to fix in a minute and I'll have more of a think about the options while I do that.

[merijn]

I certainly agree, in fact, I even proposed to add "foreign enum" to GHC to have safer and saner way of dealing with enum, but this was shot down as being to "niche" a use case, feel free to support my proposal: http://www.haskell.org/pipermail/ghc-devs/2014-April/004690.html

[merijn]

I also worry that 'enumFromTo' and friends don't make sense for a lot of C enums: think of the common case where the C enum values are bit flags, defined as

In my OpenCL bindings there are bit flags to and I like specifying them as a list of constructors on the haskell side and then having the bindings & all the bit flags together, having "enumFromTo" makes sense here since you can write list comprehensions if you want all flags.

[ian-ross]

I saw your proposal, and I'm slightly in two minds on it. On the one hand, I don't buy the "niche use case" dismissal. If that was a factor, GHC would probably be about half the size it currently is. On the other hand, this does seem like something that ought to be fixable within the existing language with the right tooling.

I think the basic fact to take on board first is that Haskell Enum and C enum are quite different things despite their superficially similar names. I was wondering whether there ought to be a CEnum type class in Foreign.C.Types to deal with this case, perhaps with just fromCEnum, toCEnum and allValues methods (the latter for use in list comprehensions). That would remove the illusion that C enums have anything to do with arithmetic sequences or the Haskell Enum class. C2HS and other tools could generate instances of this class, and there would never be any trouble with succ, pred, enumFromThenTo, etc.

It's not a very pretty solution, I'll grant you, but it does have the virtue of being extremely simple to implement and understand!

[nh2]

+1 for the CEnum. Enums in Haskell better be contiguous, while C ones are usually not.

Right now I'm writing these two functions:

-- | @loop start end f@: Loops from @start@ to @end@ (inclusive), executing @f@
-- on each iteration. Same as @forM_ [start..end] f@.
--
-- Uses `succ` inside, which does a bounds (overflow) check.
loop :: (Enum e, Eq e, Monad m) => e -> e -> (e -> m ()) -> m ()
loop start end f = go start
  where
    go !x | x == end  = f x
          | otherwise = f x >> go (succ x)

-- | Same as `loop`, but without bounds (overflow) check.
--
-- This circumvents the implementation of `succ` for the @Enum@ type
-- and uses @toEnum . (+ 1) . fromEnum@ instead, so it will break
-- on Enums that are not contiguous.
unsafeLoop :: (Enum e, Eq e, Monad m) => e -> e -> (e -> m ()) -> m ()
unsafeLoop start end f = go start
  where
    go !x | x == end  = f x
          | otherwise = f x >> go (unsafeSucc x)
    unsafeSucc = toEnum . (+ 1) . fromEnum

and as you can see, the same problem arises.

I'd find it good practice to keep them separate, and would probably even say Enum should have a "law" that states instances should map to contiguous Ints..

[jimcrayne]

The convention for generators, which cannot really assume the use case, should probably be something like the following:

1. Go ahead and generate a contiguous version of the enum as a simple sum type and make it an instance of Enum, Show,Read, Eq, Ord,Bounded. Make sure the Constructors are ordered from least to greatest, but skip constructors for entries that c would consider == to ones already used. This is mostly an internal type, don't bother marshalling it in function parameters. But it may be nice to export for debug usage etc. If the version of ghc is high enough create pattern synonyms so that code can use the alternative names of values which had aliases. Call this the element type.

2. Choose an appropriate container type, this is just something which has enough bits to hold the largest concievable value. Could be bytestring, Cint, CWord32, whatever..

3. Create something like BitSet. (See http://hackage.haskell.org/package/bitset-1.4.8/docs/Data-BitSet-Generic.html#t:BitSet).

4. There should be a convenient type class for things that came from enums in c. Call it CEnum which has only two methods, fromCEnum, toCEnum, which translates the bitfield values to their sum type equivalents and back. Make the BitSet a member, but this is actually a more general suggestion not specific to c2hs, for the purpose of providing binding writers a saner alterantive to Enum and also adapting existing code out there.

[ian-ross]

PR #91 by @Philonous fixes this, giving non-crashing Enum instances. We should probably still think about CEnum or something like it at some point in the future though.