Redundant imports for Time(Posix)

[ShrykeWindgrace]

Even if my data types do not contain UTCTime fields (or any time-related types for that matter), the file Types.elm still contains a line import Time exposing (Posix)

elm-street:0.0.1, elm code generation is done exactly as described in its hackage page. If necessary, I can provide an MWE.

[chshersh]

@ShrykeWindgrace This is a known issue. In our code we always use UTCTime so it's a not a problem. But I understand that it might be desired to avoid redundant imports and functions in the general case. In order to implement this feature, generated Elm AST should be scanned first on the presence of time data types and then we should decide whether to add imports or not. It's not a trivial task to do because the generated code depends on the list of types passed to generateElm function.

Let me think what we can do here and I will get back to this issue later.

[ShrykeWindgrace]

I guess some navigation in the spirit of generic-lens (largely simplified) should do the trick even for recursive types, the derivation of Elm requires a Generic anyway.

[ShrykeWindgrace]

To elaborate further, I sketched (with some external help =) ) a solution here. Main idea is to recover a list of types used in all constructors, detect an "Interesting" type via a typefamily evaluating to 'Bool, then demote that 'Bool to a regular Bool.

[chshersh]

@ShrykeWindgrace Thanks for your work! It's very nice that you are trying to work on this issue 🙂We already use traversal of the generic tree (in the spirit of generic-lens) to provide custom compile-time errors, so the approach is not new. However, I noticed that you are using generics-sop library in your solution. I'm not completely agree on adding generics-sop to elm-street because:

1. It's less convenient for the end users, since they need to derive SOP.Generic typeclass as well in order to make the thing work.
2. It's an extra dependency.
3. It's not really needed, the same can be achieved using ordinary Generic.

I imagine the solution of this problem as follows:

1. Implement HasUtcTime type family that traverses generic representation and checks whether it has UTCTime inside or not. We already have examples of such functions, can be implemented pretty straightforward in my understanding.

   type family HasUtcTime (g :: k -> Type) :: Bool

2. Implement type-level version of the any function to check list of types:

   type family Any (f :: k -> Bool) (xs :: [k]) :: Bool

3. Keep a DemoteBool typeclass from your solution.
4. Calculate runtime value of Any (ComposeWith HasUtcTime Rep) ts (this will probably require to implement type-level composition function)
   

   elm-street/src/Elm/Generate.hs

   Lines 95 to 96 in 69a5740

   	generateElm :: forall (ts :: [Type]) . RenderElm ts => Settings -> IO ()
   	generateElm Settings{..} = do

5. Once we get Bool, it can be passed to appropriate rendering functions to decide whether to add Time imports or not.

[ShrykeWindgrace]

@chshersh Indeed, generics-sop is not a requirement, I picked it solely for a simple mapping Type -> [[Type]].