more purity

[Ingo60]

I have two questions/suggestions:

1. Can we make types that have superclass Enum pure by default? And generate an Eq instance, maybe?

2. If a class is marked as @FunctionalInterface, the data definition should also be pure. The method, of course, is not affected by this, e.g:

   data EventHandler e = pure native javafx.event.EventHandler where
   native handle :: EventHandler e -> e -> IO ()

[mmhelloworld]

Hi Ingo,

1. native-gen already creates subclasses of Enum as pure. For example, for java.nio.file.AccessMode, it creates the following:

module java.nio.File where


data AccessMode = pure native java.nio.file.AccessMode where

  pure native read "java.nio.file.AccessMode.READ" :: AccessMode
  pure native write "java.nio.file.AccessMode.WRITE" :: AccessMode
  pure native execute "java.nio.file.AccessMode.EXECUTE" :: AccessMode

  pure native valueOf "java.nio.file.AccessMode.valueOf" :: String -> AccessMode

  native values "java.nio.file.AccessMode.values" :: () -> STMutable s (JArray AccessMode)

derive Serializable AccessMode

 The missing thing is the `Eq` instance which I think should be possible.

2. Yes, we should do this.

[Ingo60]

Sorry for bothering .... just noticed that FregeFX was made with native-gen but all Enums are mutable native unfortunately.

It also turns out that things that used to work when generated code employed raw types only don't work anymore now. One example is

EnumSet<E extends Enum<E>>

when this is used in a function that needs a wrapper like:

native contains :: Mutable s (EnumSet e) -> e -> ST s Bool

the compiler generates wrong Java code, because it doesn't know about the type bound:

static<E,S> Func<S,Boolean> contains(EnumSet<E> arg1, E arg2) { ... }

It complaints like:

The type 𝓔 is not a valid substitute for the bounded parameter <E extends Enum<E>> of the type EnumSet<E>

So this is something I have to resolve before going beta with 3.24

But then, the specification of native methods and classes will become a real pain, so I plan also to support automatic type derivation for native methods and classes. I hope you don't mind, since this will necessarily duplicate native-gen functionaity. But in the case of Util.fr we have already seen and are confirmed in FregeFX that the native-gen approach is barely maintenable anymore for big things.
When we do it in the compiler, we can perhaps be much more lazy, generating only what is actually used by the user. (Just checked, for Util.fr alone there are 500MB worth of class files generated, Most of it is never used by any code. And the 300MB in Util.class is mostly just a different encoding of information availabe via reflection.)

[mmhelloworld]

so I plan also to support automatic type derivation for native methods and classes. I hope you don't mind, since this will necessarily duplicate native-gen functionaity.

Not at all, that would actually be better. Thanks for asking. We can deprecate this project once it is done and eventually close it.