hydra
hydra copied to clipboard
CategoricalData
Transformations transformed
The `UnitType` type in Hydra Core is, unlike its siblings `IntegerType`, `MapType`, etc. not used exclusively in type definitions. The one and only instance of this type is the unit...
Hydra currently distinguishes between **product types**, which apply to unlabeled / integer-indexed tuples, and **record types**, which apply to records with labeled fields. Similarly, Hydra has **sum types** and also...
Hydra uses Hindley-Milner type inference, but its actual type grammar has moved on from Hindley-Milner to System F. Rather than inferring type schemes, Hydra must now infer forall types --...
Hydra's `Name` and `FieldName` types are currently newtypes which wrap `string`. The fact that they are newtypes rather than type aliases adds complication to the codebase (particularly in Java) for...
Hydra, while a mostly faithful implementation of the LambdaGraph spec, never quite made the leap from Hindley-Milner -style type schemes to System F -style universal types. Its type inference is...
Hydra's type inference implementation started with the minimal Algorithm W implementation in Stephen Diehl's "Write You a Haskell", then diverged heavily in order to accommodate the idiosyncrasies of Hydra, including...
The type name on `hydra/core.RowType` is not part of the LambdaGraph spec, but it is present in Hydra for historical reasons. It is redundant with the element name unless there...
Historically, Hydra has considered the name/term bindings which make up the top-level structure of the graph to be distinct from the name/term bindings found in let-expressions. In LambdaGraph, however, these...
While Java's `Byte` type has the right bit precision for Hydra's `uint8` type, by using it we are breaking with the convention of using either unsigned-and-equal, or signed-and-larger carrier types...
Hydra's kernel sources are currently littered with type annotations, due to previous limitations of Hydra type inference. We can't remove all of the annotations (after #103 is landed) because there...