search

liqula / react-hs

A GHCJS binding to React based on the Flux design. The flux design pushes state and complicated logic out of the view, allowing the rendering functions and event handlers to be pure Haskell functions.
32 stars 10 forks source link

Get rid of explicit Proxy arguments #15

Open tysonzero opened 7 years ago

tysonzero commented 7 years ago

Since we have more or less established that we are taking the TypeApplications approach, I personally think it makes sense to completely eliminate the need to ever import Data.Proxy(Proxy).

For example transformStore, where we can go from:

 transformStore @MyStore Proxy ...

or

transformStore (Proxy :: Proxy MyStore) ...

to:

transformStore @MyStore ...
fisx commented 7 years ago

I do not think this has a high priority, but I would appreciate a pull request. (As long as it does not reveal any technical problems with TypeApplications; e.g., you cannot pass a type argument to a function if the only place the type variable occurred in the function signature was in the Proxy argument).

tysonzero commented 7 years ago

There is a chance we will need -XAllowAmbiguousTypes, but it seems like a function why the type variable is only mentioned as an argument to a non-injective type family is just as ambiguous as a type variable that isn't mentioned at all, so it seems like it shouldn't be all that much worse than existing usages of it.

tysonzero commented 7 years ago

Yeah it looks like there are already a few uses of -XAllowAmbiguousTypes, so such a change should be no more questionable than existing usages of type applications.

fisx commented 7 years ago

That would make me slightly more skeptical about this issue yet. I don't have a strong case against it, but there is a chance that we will trigger ghc errors that we are so far unaffected by, and using the library will require more ghc knowledge.

Who has to turn on AllowAmbiguousTypes? The user of the library, or the library? Or both?

For the record: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#ghc-flag--XAllowAmbiguousTypes

fisx commented 7 years ago

Yeah it looks like there are already a few uses of -XAllowAmbiguousTypes, so such a change should be no more questionable than existing usages of type applications.

Ah, ok, fair enough. (-:

I would still prefer to go into the direction of simplifying the interface, though, not cementing its complexities.

tysonzero commented 7 years ago

The user doesn't need to enable it as far as I am aware. And IMO foo @a ... is a pretty darn nice interface, I mean I don't think it can get much better than that. Do you have a better idea?

fisx commented 7 years ago

No better idea, I just think there are more immediate issues with this library than polishing the syntax.

fisx commented 7 years ago

related: #20.