Monomorphisation about scoria HOT 2 OPEN

It seems to me that this is actually really crucial to having a decent EDSL front-end. A big part of FP is the ability to easily write polymorphic code like the examples you've shown! (:

from scoria.

Agreed! And if we can do this we can definitely implement the supervisor pattern you mentioned earlier.

I just had a meeting with @koengit where we talked a bit about this. Just appending type information might not be enough. We can describe issues and fixes like this:

Scenario 1

f = box "f" ["r"] $ \r -> do
  v <- deref r
  assign r (v + 1)

+ is overloaded so it can work for any numerical type. We solve this scenario with the system I described above, by recording types.

Scenario 2

f = box "f" ...
g = box "f" ...

Here we have an issue since we have two different functions in Haskell, but we are naming them the same. Even if they are applied to the same types the bodies of the two functions might be different. We can fix this by having a plugin that makes sure the proper names are inserted (and clearly documenting that the brave programmer that wishes to do this without a plugin must make sure to name things uniquely. Crap like the above example is disallowed).

Scenario 3

f1 = f where f = box "f" ...
f2 = f where f = box "f" ...

Code above is not necessarily wrong by the recipe we gave above. We can solve this by having the plugin also insert the line/column-numbers in the function name (essentially grabbing the source location. The current plugin already does this, but in another context).

Scenario 4

f a = box "f" ["x"] $ \x ->
  do ... x ... something with a ...

Here a appears as a parameter to the Haskell function f. Essentially, the body of f 3 and f 17 will be different, even if their names and types are the same. Not clear how to fix this. I am envisioning that the programmer will just write stuff like

f x a = do
  ...

-- plugin takes the above and converts to this
f = box "f" ["x","a"] $ \x a -> do
  ...

So this issue would only arise for the brave programmer that used box manually?

Scenario 5

f = box "f" ["x"] $ \x ->
  do ... x ... ?a ...

I will show you the ImplicitParams extension today, where we can use variables like ?a. This variable does not appear in the definition at all, we just wildly use it. No idea how to tackle this, currently.

There are some semantic approaches we can take to monomorphizing also. When we see a function f with body b we can check if b matches the body we've seen before. Works perfectly for functions that are not recursive. For recursive ones there is no guaranteed way that this will work, but perhaps some heuristic is fine, such as traversing the function body to a depth of 5 or something?

Tryhard solution is to define every function that you can fork globally before calling your program, and then passing that in as some parameter to your program. This is not a solution I think is good, as it removes the nice function creation/application we have right now.

Something I don't know a lot about but which @koengit is familiar with is observational sharing, where you can have two functions

f = <expr>
g = <expr> -- same body as f

With observable sharing you can tell that f =?= f but not that f =?= g. I need to read up on this approach before I try to describe some examples in more detail.

from scoria.