[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haskell-cafe
Subject:    Re: [Haskell-cafe] selectively allow alternatives in a sum type
From:       David Feuer <david.feuer () gmail ! com>
Date:       2022-08-31 22:25:32
Message-ID: CAMgWh9vwxVh6RxgswhC3yc6eyi3kPLLAnJ8raz3LBOR4xF=LAw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


To avoid actually realizing those boring fields in memory, use an unlifted
newtype.

type VoidUnit# :: TYPE ('TupleRep '[])
newtype VoidUnit# = VoidUnit# VoidUnit#

absurd# :: VoidUnit# -> a
absurd# (VoidUnit# v) = absurd# v

Unfortunately, GHC's pattern checker isn't smart enough to see by itself
that VoidUnit# is uninhabited, even though that's pretty obvious to a human.

TTG also has coercion problems thanks to the type families. *Sigh*

On Wed, Aug 31, 2022, 4:48 PM Olaf Klinke <olf@aatal-apotheke.de> wrote:

> > Trees that grow is essentially this, but using type families.
> >
> >     data Foo ksi
> >         = LeftFoo !(XLeftFoo ksi) !A
> >         | RightFoo !(XRightFoo ksi) !B
> >
> >     type family XLeftFoo ksi :: Type
> >     type family XRightFoo ksi :: Type
> >
> > Then you can define
> >
> >     data Both
> >     type instance XLeftFoo  Both = ()
> >     type instance XRightFoo Both = ()
> >
> > or
> >
> >     data OnlyLeft
> >     type instance XLeftFoo  OnlyLeft = ()
> >     type instance XRightFoo OnlyLeft = Void
> >
> > ---
> >
> > Third option is to simply have parametrized data:
> >
> >    data Foo b
> >        = LeftFoo !A
> >        | RIghtFoo !b
> >
> >    type FooBoth = Foo B
> >    type FooOnlyLeft = Foo Void
> >
> > ---
> >
> > Sometimes I prefer a higher-kinded data approach, especially if there is
> > very little variants needed, and they are "uniform" (e.g. second variant
> > doesn't have some fields).
> > Yet, sometimes simple parameterized data is simplest approach
> > (especially as you get stuff for free by deriving Traversable!).
> >
> > On the other hand, if type is big and have many uniform extension points
> > (even if there are few different combinations), then HKD becomes
> > boilerplate heavy as well.
> > The drawback of TTG, is that writing polymorphic code (i.e. which work
> > for any or some `ksi`s) is not very fun: a lot of equality constraints
> etc.
> >
> > - Oleg
>
> So I re-discovered Trees that Grow sans the trick of using type
> families to name particular combinations of parameters. Hooray Najd,
> and thanks Oleg for bringing this up.
>
> Olaf
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

[Attachment #5 (text/html)]

<div dir="auto"><div dir="auto">To avoid actually realizing those boring fields in \
memory, use an unlifted newtype.</div><div dir="auto"><br></div><div dir="auto">type \
VoidUnit# :: TYPE (&#39;TupleRep &#39;[])</div><div dir="auto">newtype VoidUnit# = \
VoidUnit# VoidUnit#</div><div dir="auto"><br></div><div dir="auto">absurd# :: \
VoidUnit# -&gt; a</div><div dir="auto">absurd# (VoidUnit# v) = absurd# v</div><div \
dir="auto"><br></div><div dir="auto">Unfortunately, GHC&#39;s pattern checker \
isn&#39;t smart enough to see by itself that VoidUnit# is uninhabited, even though \
that&#39;s pretty obvious to a human.</div><div dir="auto"><br></div>TTG also has \
coercion problems thanks to the type families. *Sigh*<br><br><div class="gmail_quote" \
dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Aug 31, 2022, 4:48 PM Olaf \
Klinke &lt;<a href="mailto:olf@aatal-apotheke.de">olf@aatal-apotheke.de</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Trees that grow is essentially \
this, but using type families.<br> &gt; <br>
&gt;        data Foo ksi<br>
&gt;              = LeftFoo !(XLeftFoo ksi) !A<br>
&gt;              | RightFoo !(XRightFoo ksi) !B<br>
&gt; <br>
&gt;        type family XLeftFoo ksi :: Type<br>
&gt;        type family XRightFoo ksi :: Type<br>
&gt; <br>
&gt; Then you can define<br>
&gt; <br>
&gt;        data Both<br>
&gt;        type instance XLeftFoo   Both = ()<br>
&gt;        type instance XRightFoo Both = ()<br>
&gt; <br>
&gt; or<br>
&gt; <br>
&gt;        data OnlyLeft<br>
&gt;        type instance XLeftFoo   OnlyLeft = ()<br>
&gt;        type instance XRightFoo OnlyLeft = Void<br>
&gt; <br>
&gt; ---<br>
&gt; <br>
&gt; Third option is to simply have parametrized data:<br>
&gt; <br>
&gt;      data Foo b<br>
&gt;            = LeftFoo !A<br>
&gt;            | RIghtFoo !b<br>
&gt; <br>
&gt;      type FooBoth = Foo B<br>
&gt;      type FooOnlyLeft = Foo Void<br>
&gt; <br>
&gt; ---<br>
&gt; <br>
&gt; Sometimes I prefer a higher-kinded data approach, especially if there is<br>
&gt; very little variants needed, and they are &quot;uniform&quot; (e.g. second \
variant<br> &gt; doesn&#39;t have some fields).<br>
&gt; Yet, sometimes simple parameterized data is simplest approach<br>
&gt; (especially as you get stuff for free by deriving Traversable!).<br>
&gt; <br>
&gt; On the other hand, if type is big and have many uniform extension points<br>
&gt; (even if there are few different combinations), then HKD becomes<br>
&gt; boilerplate heavy as well.<br>
&gt; The drawback of TTG, is that writing polymorphic code (i.e. which work<br>
&gt; for any or some `ksi`s) is not very fun: a lot of equality constraints etc.<br>
&gt; <br>
&gt; - Oleg<br>
<br>
So I re-discovered Trees that Grow sans the trick of using type<br>
families to name particular combinations of parameters. Hooray Najd,<br>
and thanks Oleg for bringing this up. <br>
<br>
Olaf<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" \
rel="noreferrer noreferrer" \
target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br> \
Only members subscribed via the mailman list are allowed to \
post.</blockquote></div></div>


[Attachment #6 (text/plain)]

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic