search

ku-fpg / hermit-shell

HERMIT with GHCi shell
BSD 3-Clause "New" or "Revised" License
2 stars 0 forks source link

Clarify Structural Distinctions Between Effect Classes #24

Closed ecaustin closed 9 years ago

ecaustin commented 9 years ago

All:

I'm trying to push through the last changes for returning values from server to client and I'm getting repeatedly bit by overloading issues.

Right now we have several classes of effects, ShellEffect, KernelEffect, Transform, Rewrite, etc., some of which are structurally distinct and some of which aren't, e.g. Rewrite is just a type synonym of Transform.

Even though we have very distinct ways of interacting with these effects, apply, query, etc., in the interest of providing a nice UI we use type classes to overload central functions that attempt to pick the appropriate interaction based on the type of the effect class. I'm specifically talking about the Repl class and the Run class.

This works great, provided that all interactions have a shared return type, i.e. Shell (). As soon as you try and change one or more effects to have a different return type from the others things go to hell.

Specifically, how do we compute the appropriate return type for transformations (Transform a b => b), rewrites (Transform a a => ()), and paths (Transformation a LocalPath => ())? There's not a strong enough distinction between the types of these effects to avoid ambiguity.

There's two possible solutions that I see:

  1. Make these effects distinct by separating rewrites and path computations using new data types.
  2. Change apply and setPath to return a value corresponding to the return type of their Transformation argument.

I have my own list of pros/cons for each choice, but I wanted to hear everyone's unbiased opinions on this issue before I say anymore.

ecaustin commented 9 years ago

Andy's changes to the implementation of return values has made this a moot issue.