CategoricalData
Transform variable types to Haskell typedefs
While Hydra currently does not support typedefs (in contrast to newtypes / wrappers), the new data model specification which Hydra has been migrating to does have constructs which could be considered as typedefs. E.g. in Description := string, the name "Description" would currently be bound to TypeLiteral LiteralString in Hydra, while for User := Person the name "User" would be bound to TypeWrap $ Nominal (Name "Person"). This asymmetry exists because names and variables were not unified until recently, so a type expression like TypeVariable (Name "Person") was not possible. Wrappers were essentially a workaround for this limitation.
Wrapper types and terms have not yet been fully migrated to the new data model specification. Once they are, we will have two options for binding "User" to "Person". One is more like a typedef: TypeVariable (Name "Person") and the other is more like a newtype: TypeWrap $ TypeVariable (Name "Person"). The Haskell DSL will need to distinguish between the two (most likely using the wrap helper function for the latter case), and the Haskell coder will be able to generate one as an actual typedef, and the other as a newtype into Haskell. Since Java does not support typedefs, these will either need to be turned into newtypes by the adapter framework, or we can manifest them using subclasses (which would give you a kind of one-way typedef). Note that it will also be possible to manifest typedefs in Haskell which bind type parameters to concrete types, e.g. GeoPolygon := Polygon GeoPoint would be realized using the application type constructor.
This ticket is very old. Hydra does cleanly distinguish between wrappers and type aliases now, although the Haskell coder still translates both into newtypes. Keeping the ticket open for that reason. The Haskell coder should really translate only wrapper type definitions into newtype expressions, and type alias definitions into type expressions. There is just a lot of code to migrate in order to carry out this change.
This issue is being felt more and more often the closer we get to closing the loop in Haskell. Needs to be fixed.