General questions about design of elm-bridge
- Langage dominant
- Elm
- Étoiles
- 107
- Forks
- 28
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
I'm extending this library to auto-generate Elm API wrappers based on Servant type-signatures [1]. I've pretty much wrapped my head around the internals, but am scratching my head over the following:
1. The philosophical / conceptual difference between `ETypeDef` and `EType`. It seems to me that `EType` is some sort of Elm-compatible subset of `TH.Type`, but I'm not so sure about `ETypeDef`.
2. `deriveElm` uses TH to generate instances for `IsElmDefinition`. However, there are no `IsElmDefinition` instances for things like `String` or `Bool`. It this because you don't want to have "global" Haskell <=> Elm type-mappings forced upon users of this library, allowing them, instead, to make a choice on a case-by-case basis by using `makeModuleContentWithAlterations` infra?
3. Even then, if as an end-user, I **want** to define an `IsElmDefinition` for my app, how would I do that for something like `String` / `Bool`? How does one write a sensible implementation for `compileElmDef :: Proxy a -> ETypeDef`? What value should this function return? The only _possible_ option is `ETypePrimAlias`, but I'm not sure how that would work? (this should give you some context about why I'm asking the very first question).
[1] Btw, are you open to a PR for this functionality? I don't see the point in releasing yet another elm <=> haskell library.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Évaluation
Cette issue n'a pas encore été évaluée.