packages feed

purescript-0.14.0: tests/purs/publish/basic-example/output/Data.Field/docs.json

{"reExports":[],"name":"Data.Field","comments":null,"declarations":[{"children":[{"comments":null,"title":"field","info":{"declType":"instance","dependencies":[{"constraintAnn":[],"constraintClass":[["Data","EuclideanRing"],"EuclideanRing"],"constraintArgs":[{"annotation":[],"tag":"TypeVar","contents":"a"}],"constraintKindArgs":[],"constraintData":null},{"constraintAnn":[],"constraintClass":[["Data","DivisionRing"],"DivisionRing"],"constraintArgs":[{"annotation":[],"tag":"TypeVar","contents":"a"}],"constraintKindArgs":[],"constraintData":null}],"type":{"annotation":[],"tag":"TypeApp","contents":[{"annotation":[],"tag":"TypeConstructor","contents":[["Data","Field"],"Field"]},{"annotation":[],"tag":"TypeVar","contents":"a"}]}},"sourceSpan":{"start":[41,1],"name":"../../../support/bower_components/purescript-prelude/src/Data/Field.purs","end":[41,63]}}],"comments":"The `Field` class is for types that are (commutative) fields.\n\nMathematically, a field is a ring which is commutative and in which every\nnonzero element has a multiplicative inverse; these conditions correspond\nto the `CommutativeRing` and `DivisionRing` classes in PureScript\nrespectively. However, the `Field` class has `EuclideanRing` and\n`DivisionRing` as superclasses, which seems like a stronger requirement\n(since `CommutativeRing` is a superclass of `EuclideanRing`). In fact, it\nis not stronger, since any type which has law-abiding `CommutativeRing`\nand `DivisionRing` instances permits exactly one law-abiding\n`EuclideanRing` instance. We use a `EuclideanRing` superclass here in\norder to ensure that a `Field` constraint on a function permits you to use\n`div` on that type, since `div` is a member of `EuclideanRing`.\n\nThis class has no laws or members of its own; it exists as a convenience,\nso a single constraint can be used when field-like behaviour is expected.\n\nThis module also defines a single `Field` instance for any type which has\nboth `EuclideanRing` and `DivisionRing` instances. Any other instance\nwould overlap with this instance, so no other `Field` instances should be\ndefined in libraries. Instead, simply define `EuclideanRing` and\n`DivisionRing` instances, and this will permit your type to be used with a\n`Field` constraint.\n","title":"Field","info":{"fundeps":[],"arguments":[["a",null]],"declType":"typeClass","superclasses":[{"constraintAnn":[],"constraintClass":[["Data","EuclideanRing"],"EuclideanRing"],"constraintArgs":[{"annotation":[],"tag":"TypeVar","contents":"a"}],"constraintKindArgs":[],"constraintData":null},{"constraintAnn":[],"constraintClass":[["Data","DivisionRing"],"DivisionRing"],"constraintArgs":[{"annotation":[],"tag":"TypeVar","contents":"a"}],"constraintKindArgs":[],"constraintData":null}]},"sourceSpan":{"start":[39,1],"name":"../../../support/bower_components/purescript-prelude/src/Data/Field.purs","end":[39,51]}}]}