[prev in list] [next in list] [prev in thread] [next in thread]
List: haskell-cafe
Subject: Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?
From: Gábor_Lehel <illissius () gmail ! com>
Date: 2013-04-25 19:19:06
Message-ID: CAPNUp080GCfd4m3SBQtjAQo=JGaApE4w_O6ae-pVhHfGMamZHg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Good point, again. Is that the only problem with it?
On Thu, Apr 25, 2013 at 5:57 PM, Dan Doel <dan.doel@gmail.com> wrote:
> It is not completely backwards compatible, because (for instance) the
> declaration:
>
> newtype C a => Foo a = Foo a
>
> was allowed, but:
>
> newtype Foo a where
> Foo :: C a => a -> Foo a
>
> is an illegal definition. It can only be translated to a non-newtype data
> declaration, which changes the semantics.
>
>
> On Thu, Apr 25, 2013 at 10:35 AM, Gábor Lehel <illissius@gmail.com> wrote:
>
>> I've wondered this too. What would have been wrong with a simple
>> source-to-source translation, where a constraint on the datatype itself
>> translates to the same constraint on each of its constructors? Perhaps it
>> would be unintuitive that you would have to pattern match before gaining
>> access to the constraint? On a superficial examination it would have been
>> backwards-compatible, allowing strictly more programs than the previous
>> handling.
>>
>> On Thu, Apr 25, 2013 at 12:38 PM, harry <voldermort@hotmail.com> wrote:
>>
>>> If I understand correctly, the problem with datatype contexts is that if
>>> we
>>> have e.g.
>>> data Eq a => Foo a = Foo a
>>> the constraint Eq a is thrown away after a Foo is constructed, and any
>>> method using Foos must repeat Eq a in its type signature.
>>>
>>> Why were these contexts removed from the language, instead of "fixing"
>>> them?
>>>
>>> PS This is following up on a discussion on haskell-beginners, "How to
>>> avoid
>>> repeating a type restriction from a data constructor". I'm interested in
>>> knowing whether there's a good reason not to allow this, or if it's just
>>> a
>>> consequence of the way type classes are implemented by compilers.
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>>
>>
>> --
>> Your ship was destroyed in a monadic eruption.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
--
Your ship was destroyed in a monadic eruption.
[Attachment #5 (text/html)]
Good point, again. Is that the only problem with it?<br><br><div \
class="gmail_quote">On Thu, Apr 25, 2013 at 5:57 PM, Dan Doel <span dir="ltr"><<a \
href="mailto:dan.doel@gmail.com" target="_blank">dan.doel@gmail.com</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div dir="ltr">It is not completely backwards \
compatible, because (for instance) the declaration:<div><br></div><div> newtype C \
a => Foo a = Foo a</div> <div><br></div><div>was allowed, but:</div><div>
<br></div><div> newtype Foo a where</div><div> Foo :: C a => a -> Foo \
a</div><div><br></div><div>is an illegal definition. It can only be translated to a \
non-newtype data declaration, which changes the semantics.</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div \
class="gmail_quote">On Thu, Apr 25, 2013 at 10:35 AM, Gábor Lehel <span \
dir="ltr"><<a href="mailto:illissius@gmail.com" \
target="_blank">illissius@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div>I've wondered this too. What would have been wrong \
with a simple source-to-source translation, where a constraint on the datatype itself \
translates to the same constraint on each of its constructors? Perhaps it would be \
unintuitive that you would have to pattern match before gaining access to the \
constraint? On a superficial examination it would have been backwards-compatible, \
allowing strictly more programs than the previous handling.</div>
<div><div>
<div><br></div><div class="gmail_quote">On Thu, Apr 25, 2013 at 12:38 PM, harry <span \
dir="ltr"><<a href="mailto:voldermort@hotmail.com" \
target="_blank">voldermort@hotmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
If I understand correctly, the problem with datatype contexts is that if we<br>
have e.g.<br>
data Eq a => Foo a = Foo a<br>
the constraint Eq a is thrown away after a Foo is constructed, and any<br>
method using Foos must repeat Eq a in its type signature.<br>
<br>
Why were these contexts removed from the language, instead of "fixing" \
them?<br> <br>
PS This is following up on a discussion on haskell-beginners, "How to avoid<br>
repeating a type restriction from a data constructor". I'm interested in<br>
knowing whether there's a good reason not to allow this, or if it's just \
a<br> consequence of the way type classes are implemented by compilers.<br>
<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" \
target="_blank">Haskell-Cafe@haskell.org</a><br> <a \
href="http://www.haskell.org/mailman/listinfo/haskell-cafe" \
target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br> \
</blockquote></div><br><br clear="all"><br></div></div><span><font color="#888888">-- \
<br>Your ship was destroyed in a monadic eruption. \
</font></span><br>_______________________________________________<br> Haskell-Cafe \
mailing list<br> <a href="mailto:Haskell-Cafe@haskell.org" \
target="_blank">Haskell-Cafe@haskell.org</a><br> <a \
href="http://www.haskell.org/mailman/listinfo/haskell-cafe" \
target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br> \
<br></blockquote></div><br></div> </div></div></blockquote></div><br><br \
clear="all"><br>-- <br>Your ship was destroyed in a monadic eruption.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic