General questions about design of elm-bridge
- Linguagem predominante
- Elm
- Estrelas
- 107
- Forks
- 28
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Descrição
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.
Guia de contribuição
Nenhum guia de contribuição indexado para este repositório
Avaliação
Esta issue ainda não foi avaliada.