A typed data library for Python on top of panproto. - panproto/didactic

Ah, so the difference is Constant :: (forall x. Monoid x => x) -> Lifted f a MkMonoidal :: ( Monoid a => a) -> Monoidal a so `MkMonoidal` takes a monomorphic argument. The consequence of this is that `Monoidal a` is the empty type when `a` is not already a monoid, whereas `Lifted f a` always has an inhabitant. I’ll experiment and see whether the monomorphic variant has any other drawbacks.

olf: > But `minBound :: Bounds ()` can be distinguished from `maxBound :: Bounds ()` by matching the `Bound` constructor and casting the value to another non-singleton type. That’s possible for your original `Constant` approach, but not for this `MkMonoidal`/`Bound` approach, because the latter doesn’t put the quantification inside the constructor.

Yes, that is exactly what I described as my work-around: `MkMonoidal = Constant`. It turns out the combinatorial explosion is not too bad, because one can reduce binary operations involving constants to unary operations `forall a. Monoid a => a -> a`. The only remaining downside is when there are specific class members that identify two constants: newtype Bounds a where Bound :: (Bounded a => a) -> Bounds a instance Bounded (Bounds a) where maxBound = Bound maxBound minBound = Bound minBound We have minBound == () == maxBound But `minBound :: Bounds ()` can be distinguished from `maxBound :: Bounds ()` by matching the `Bound` constructor and casting the value to another non-singleton type.

You’re bundling constraints with the values, thus requiring them upon construction but not destruction. If you impose constraints on the values instead, then you’ll need them upon destruction but not construction. That will allow you to produce these values without first matching on another: newtype Monoidal a where MkMonoidal :: (Monoid a => a) -> Monoidal a instance Semigroup (Monoidal a) where MkMonoidal x <> MkMonoidal y = MkMonoidal (x <> y) instance Monoid (Monoidal a) where mempty = MkMonoidal mempty

You’re bundling constraints with the values, thus requiring them upon construction but not destruction. If you impose constraints on the values instead, then you’ll need them upon destruction but not construction. That will allow you to produce these values without first matching on another: newtype Monoidal a where MkMonoidal :: (Monoid a => a) -> Monoidal a instance Semigroup (Monoidal a) where MkMonoidal x <> MkMonoidal y = MkMonoidal (x <> y) instance Monoid (Monoidal a) where mempty = MkMonoidal mempty

This reminds me of Kmett’s type classes vs the world (around 7:48): Edward Kmett - Type Classes vs. the World He uses the example of `fromInteger` which suffers from the same issue.

I am trying to define something similar to `Data.Monoid.Ap` but as GADT with constraints on the constructors: import Data.Monoid (Ap(..)) -- instance (Monoid a, Applicative f) => Monoid (Ap f a) data Lifted f a where Lift :: (Monoid a, Applicative f) => Ap f a -> Lifted f a One can have a `Semigroup` instance wherein the constraints are hidden: instance Semigroup (Lifted f a) where (Lift a) <> (Lift b) = Lift (a <> b) This works because by matching on the `Lift` constructor, the constraints necessary for the `Semigroup (Ap f a)` instance are brought into scope. However, this approach does **not** work for nullary operations like `mempty`, because there is nothing to pattern-match on. Can it be done nevertheless? Perhaps with proxies? A possible work-around would be to introduce a second constructor taking a rank-2 argument: data Lifted f a where Lift :: (Monoid a, Applicative f) => Ap f a -> Lifted f a Constant :: (forall x. Monoid x => x) -> Lifted f a instance Monoid (Lifted f a) where mempty = Constant mempty The drawback is combinatorial explosion in the definition of the semigroup operation (or any other n-ary operation). Instead of one case, it now must handle four. The class `Monoid` is only an example. My question applies to all classes of algebraic structures that have constants.

Four Signals — The Wire

A deep dive into implementing the 'tagless initial' pattern in Rust using enums and the never type to achieve zero-cost abstractions, demonstrated with optimized assembly output.

A deep dive into implementing the 'tagless initial' pattern in Rust using enums and the never type to achieve zero-cost abstractions, demonstrated with optimized assembly output.

Comments

That is essentially the approach I am testing currently. From the GHC.Generics module I extracted these key design points: 1. All constructors that you would normally put in a data family or GADT get their own data type, like `:+:` or `:*:`. 2. The helper class (`Generic` in that case) has an associated type family, which is not injective, but… 3. … still allows one to gain _some_ information about the source type by pattern matching on the constructors of the type family target. 4. Due to non-injectivity, all further derived instances (e.g. `Eq`) must work on the dedicated types from (1) 5. The _derived family instance_ can be implemented using the same mechanism that the `Generically` newtype is offering. This corresponds to your `MkTG` constructor. The only drawback is that this can pollute the type family target type with yet another newtype wrapper. AntC2: > I don’t pretend to understand what you’re trying to do My use case is a representation of an (externally specified) domain-specific language (DSL). There are more things to do with it, but the basic thing is evaluation: type Semantics DSL a = (a -> Bool) -- concrete semantics is irrelevant runDSL :: DSL a -> Semantics (DSL a) The naive approach would be to just encode the AST. newtype DSL a = DSLExpr {getAST :: AST} However, not all expressions might be valid for all types. Hence we must have typeCheckDSL :: AST -> Maybe (Semantics DSL a) If that sort of run-time failure is not desired, one would traditionally reach for a GADT. data DSL a where -- many GADT constructors typeCheckDSL :: AST -> Maybe (DSL a) runDSL :: DSL a -> (Semantics DSL a) -- now type safe Now the type mismatch can be thrown at parsing stage. However, the GADT is _closed_ while the basic library may not want to cover the DSL spec for _all Haskell types_. In contrast a type class is open and extensible. class RunDSL a where type DSL a typeCheckDSL :: AST -> Maybe (DSL a) runDSL :: DSL a -> (Semantics DSL a) My goal is now to provide instances for a wide range of types without much boilerplate. To that end, we provide re-usable `DSL a` building blocks as separate types, like the ones used in a Generic `Rep`. If we covered all `Rep` types in our DSL class, then we can have the desired derived instance: newtype GenericDSL a = GenericDSL (forall p. DSL (Rep a p)) If we now declare for a concrete type deriving via (Generically T) instance RunDSL T then the `DSL T` type would have the `GenericDSL` newtype wrapper as single constructor, witnessing the fact that we used a derived instance. But that is okay, since the main interface for construction is `typeCheckDSL` which can add this wrapper automatically. My implementation is not complete enough to see whether the non-injectivity of the `DSL` type family leads to road blocks that weren’t there with a GADT. Anyways, thanks a lot for giving so much thought to this problem of mine.

That is essentially the approach I am testing currently. From the GHC.Generics module I extracted these key design points: 1. All constructors that you would normally put in a data family or GADT get their own data type, like `:+:` or `:*:`. 2. The helper class (`Generic` in that case) has an associated type family, which is not injective, but… 3. … still allows one to gain _some_ information about the source type by pattern matching on the constructors of the type family target. 4. Due to non-injectivity, all further derived instances (e.g. `Eq`) must work on the dedicated types from (1) 5. The _derived family instance_ can be implemented using the same mechanism that the `Generically` newtype is offering. This corresponds to your `MkTG` constructor. The only drawback is that this can pollute the type family target type with yet another newtype wrapper. AntC2: > I don’t pretend to understand what you’re trying to do My use case is a representation of an (externally specified) domain-specific language (DSL). There are more things to do with it, but the basic thing is evaluation: type Semantics DSL a = (a -> Bool) -- concrete semantics is irrelevant runDSL :: DSL a -> Semantics (DSL a) The naive approach would be to just encode the AST. newtype DSL a = DSLExpr {getAST :: AST} However, not all expressions might be valid for all types. Hence we must have typeCheckDSL :: AST -> Maybe (Semantics DSL a) If that sort of run-time failure is not desired, one would traditionally reach for a GADT. data DSL a where -- many GADT constructors typeCheckDSL :: AST -> Maybe (DSL a) runDSL :: DSL a -> (Semantics DSL a) -- now type safe Now the type mismatch can be thrown at parsing stage. However, the GADT is _closed_ while the basic library may not want to cover the DSL spec for _all Haskell types_. In contrast a type class is open and extensible. class RunDSL a where type DSL a typeCheckDSL :: AST -> Maybe (DSL a) runDSL :: DSL a -> (Semantics DSL a) My goal is now to provide instances for a wide range of types without much boilerplate. To that end, we provide re-usable `DSL a` building blocks as separate types, like the ones used in a Generic `Rep`. If we covered all `Rep` types in our DSL class, then we can have the desired derived instance: newtype GenericDSL a = GenericDSL (forall p. DSL (Rep a p)) If we now declare for a concrete type deriving via (Generically T) instance RunDSL T then the `DSL T` type would have the `GenericDSL` newtype wrapper as single constructor, witnessing the fact that we used a derived instance. But that is okay, since the main interface for construction is `typeCheckDSL` which can add this wrapper automatically. My implementation is not complete enough to see whether the non-injectivity of the `DSL` type family leads to road blocks that weren’t there with a GADT. Anyways, thanks a lot for giving so much thought to this problem of mine.

That is essentially the approach I am testing currently. From the GHC.Generics module I extracted these key design points: 1. All constructors that you would normally put in a data family or GADT get their own data type, like `:+:` or `:*:`. 2. The helper class (`Generic` in that case) has an associated type family, which is not injective, but… 3. … still allows one to gain _some_ information about the source type by pattern matching on the constructors of the type family target. 4. Due to non-injectivity, all further derived instances (e.g. `Eq`) must work on the dedicated types from (1) 5. The _derived family instance_ can be implemented using the same mechanism that the `Generically` newtype is offering. This corresponds to your `MkTG` constructor. The only drawback is that this can pollute the type family target type with yet another newtype wrapper. AntC2: > I don’t pretend to understand what you’re trying to do My use case is a representation of an (externally specified) domain-specific language (DSL). There are more things to do with it, but the basic thing is evaluation: type Semantics DSL a = (a -> Bool) -- concrete semantics is irrelevant runDSL :: DSL a -> Semantics (DSL a) The naive approach would be to just encode the AST. newtype DSL a = DSLExpr {getAST :: AST} However, not all expressions might be valid for all types. Hence we must have typeCheckDSL :: AST -> Maybe (Semantics DSL a) If that sort of run-time failure is not desired, one would traditionally reach for a GADT. data DSL a where -- many GADT constructors typeCheckDSL :: AST -> Maybe (DSL a) runDSL :: DSL a -> (Semantics DSL a) -- now type safe Now the type mismatch can be thrown at parsing stage. However, the GADT is _closed_ while the basic library may not want to cover the DSL spec for _all Haskell types_. In contrast a type class is open and extensible. class RunDSL a where type DSL a typeCheckDSL :: AST -> Maybe (DSL a) runDSL :: DSL a -> (Semantics DSL a) My goal is now to provide instances for a wide range of types without much boilerplate. To that end, we provide re-usable `DSL a` building blocks as separate types, like the ones used in a Generic `Rep`. If we covered all `Rep` types in our DSL class, then we can have the desired derived instance: newtype GenericDSL a = GenericDSL (forall p. DSL (Rep a p)) If we now declare for a concrete type deriving via (Generically T) instance RunDSL T then the `DSL T` type would have the `GenericDSL` newtype wrapper as single constructor, witnessing the fact that we used a derived instance. But that is okay, since the main interface for construction is `typeCheckDSL` which can add this wrapper automatically. My implementation is not complete enough to see whether the non-injectivity of the `DSL` type family leads to road blocks that weren’t there with a GADT. Anyways, thanks a lot for giving so much thought to this problem of mine.

That is essentially the approach I am testing currently. From the GHC.Generics module I extracted these key design points: 1. All constructors that you would normally put in a data family or GADT get their own data type, like `:+:` or `:*:`. 2. The helper class (`Generic` in that case) has an associated type family, which is not injective, but… 3. … still allows one to gain _some_ information about the source type by pattern matching on the constructors of the type family target. 4. Due to non-injectivity, all further derived instances (e.g. `Eq`) must work on the dedicated types from (1) 5. The _derived family instance_ can be implemented using the same mechanism that the `Generically` newtype is offering. This corresponds to your `MkTG` constructor. The only drawback is that this can pollute the type family target type with yet another newtype wrapper. AntC2: > I don’t pretend to understand what you’re trying to do My use case is a representation of an (externally specified) domain-specific language (DSL). There are more things to do with it, but the basic thing is evaluation: type Semantics DSL a = (a -> Bool) -- concrete semantics is irrelevant runDSL :: DSL a -> Semantics (DSL a) The naive approach would be to just encode the AST. newtype DSL a = DSLExpr {getAST :: AST} However, not all expressions might be valid for all types. Hence we must have typeCheckDSL :: AST -> Maybe (Semantics DSL a) If that sort of run-time failure is not desired, one would traditionally reach for a GADT. data DSL a where -- many GADT constructors typeCheckDSL :: AST -> Maybe (DSL a) runDSL :: DSL a -> (Semantics DSL a) -- now type safe Now the type mismatch can be thrown at parsing stage. However, the GADT is _closed_ while the basic library may not want to cover the DSL spec for _all Haskell types_. In contrast a type class is open and extensible. class RunDSL a where type DSL a typeCheckDSL :: AST -> Maybe (DSL a) runDSL :: DSL a -> (Semantics DSL a) My goal is now to provide instances for a wide range of types without much boilerplate. To that end, we provide re-usable `DSL a` building blocks as separate types, like the ones used in a Generic `Rep`. If we covered all `Rep` types in our DSL class, then we can have the desired derived instance: newtype GenericDSL a = GenericDSL (forall p. DSL (Rep a p)) If we now declare for a concrete type deriving via (Generically T) instance RunDSL T then the `DSL T` type would have the `GenericDSL` newtype wrapper as single constructor, witnessing the fact that we used a derived instance. But that is okay, since the main interface for construction is `typeCheckDSL` which can add this wrapper automatically. My implementation is not complete enough to see whether the non-injectivity of the `DSL` type family leads to road blocks that weren’t there with a GADT. Anyways, thanks a lot for giving so much thought to this problem of mine.

olf: > As far as I understand, a GADT is like a closed data family. No that’s not a useful comparison. A Data Family is a function on type(s), returning a type. Data Familys that aren’t closed, are open in the sense you can freely add instances _providing they don’t overlap_. IOW what you’re trying to do is exactly what open TFs are deliberately designed to avoid. What do you think a default instance could do more than give an error message? And wouldn’t it be better for the compile to fail rather than seem to work but error at runtime? Note the `default` only gets activated providing there is at least an explicit `instance` declared for the type — even if it’s no more than the head. That doesn’t seem to fit what you describe. It seems you’re expecting separate modules/separate compilation. Then I suggest you first get your head around ‘orphan instances’, and assure yourself they could never happen in your scenario.

Related question from 2023: Choosing data representation based on type As far as I understand, a GADT is like a closed data family. I want to construct an _open_ data family, where the library user can add her own instances for concrete types that weren’t mentioned in the library. The data family is associated with a type class. Thanks to `DefaultSignatures`, we can provide default implementations for ordinary **class methods** like so: class Blah x where blah :: x -> Blubb default blah :: Generic x => x -> Blubb blah = -- implementation using the context Likewise, I would like to create a default or overlappable data family instance, but it seems to be rejected for reasons explained in the thread linked to above. Assume we have a data family `MyOpenFamily` and we are able to use `MyOpenFamily x` and `MyOpenFamily (Rep x ())` interchangingly. The goal is to default class Blah x where blah :: MyOpenFamily x -> Blubb I would like to give the library user the same convenience as with `DefaultSignatures`. * No need to declare an instance of `MyOpenFamily` provided a `Generic` instance can be derived. * No need to declare an implementation for `blah` provided a `Generic` instance can be derived. Ugly and potentially circular work-around (related to the `Generically` trick): Further wrap the open data family in yet another GADT with two constructors, like so: data MyFamilyWrapper x where DirectInstance :: MyOpenFamily x -> MyFamilyWrapper x ViaGeneric :: (Generic x, f ~ Rep x) => MyOpenFamily (f ()) -> MyFamilyWrapper x Then change the type of `blah`: class Blah where blah :: MyFamilyWrapper x -> Blubb For non-Generic types, the user provides a definition of `blah` that pattern-matches only on `DirectInstance`. Thanks to the constraint on `ViaGeneric`, we know that is a total definition. For Generic types, we can then have a default implementation: default blah :: (Generic x, Rep x ~ f, Blah (f ())) => MyFamilyWrapper x -> Blubb blah (ViaGeneric p) = blah (DirectInstance p) I wonder whether there is a more concise way of doing this, without `MyFamilyWrapper`. Using ordinary type families is out of the question because * the real class involves kinds `Type -> Type` and type families can’t be partially applied, * a default clause `type MyOpenFamily a = MyOpenFamily (Rep a ())` in a type family makes it closed.

A deep dive into implementing the 'tagless initial' pattern in Rust using enums and the never type to achieve zero-cost abstractions, demonstrated with optimized assembly output.