Dan Doel dan.doel at gmail.com writes:
However, another thing to consider is that getting rid of data type
contexts was accepted into the language standard.
... which means that implementers should be free to fix data type contexts
however they like, as they are now complier extensions which
On Sun, Apr 28, 2013 at 3:59 AM, harry volderm...@hotmail.com wrote:
Dan Doel dan.doel at gmail.com writes:
However, another thing to consider is that getting rid of data type
contexts was accepted into the language standard.
... which means that implementers should be free to fix data
Brandon Allbery allbery.b at gmail.com writes:
... which means that implementers should be free to fix data type contexts
however they like, as they are now complier extensions which won't conflict
with standard Haskell.
Except that people do build older programs with newer Haskell
On Sun, Apr 28, 2013 at 10:29 AM, gs volderm...@hotmail.com wrote:
Brandon Allbery allbery.b at gmail.com writes:
... which means that implementers should be free to fix data type
contexts
however they like, as they are now complier extensions which won't
conflict
with standard Haskell.
Alexander Solla alex.solla at gmail.com writes:
I do not support that criterion. We use theory to ENSURE that no
real-world code will break.
By theoretical example, I meant something which you would never expect to
find in use. Perhaps it was a poor choice of wording in an academically
On Sun, Apr 28, 2013 at 10:55 AM, gs volderm...@hotmail.com wrote:
Alexander Solla alex.solla at gmail.com writes:
I do not support that criterion. We use theory to ENSURE that no
real-world code will break.
By theoretical example, I meant something which you would never expect to
find
Dan Doel wrote:
I don't really think they're worth saving in general, though. I haven't missed
them, at least.
Maybe you haven't :-) My code is cluttered with redundant type contexts - I can't think of a similar redundancy in any
other language.
That is because every other language conflates the notion of a class with a
vtable smashed into every inhabitant of the class where everything has to
be defined together in one monolithic definition.
You also can't write sensible Monads in those languages (Where does return
go?) or retroactively
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,
From what I have heard, they are completely subsumed by GADTs, which is
a stable enough extension that it was considered unimportant to save.
Your Foo would be something like this:
data Foo a where
Foo :: Eq a = a - Foo a
On 4/25/2013 6:38 AM, harry wrote:
If I understand correctly, the
On Thu, Apr 25, 2013 at 6:36 PM, Joe Quinn headprogrammingc...@gmail.comwrote:
data Foo a where
Foo :: Eq a = a - Foo a
is equivalent to
data Foo a = Eq a = Foo a
but is different from
data Eq a = Foo a = Foo a
(Yup, tripped up a few of us already!)
-- Kim-Ee
Kim-Ee Yeoh ky3 at atamo.com writes:
data Foo a where
Foo :: Eq a = a - Foo a
is equivalent to
data Foo a = Eq a = Foo a
but is different from
data Eq a = Foo a = Foo a
... and nothing in GADTs does what one would naively expect the last
declaration to do.
On Thu, Apr 25, 2013 at 6:38 AM, harry volderm...@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
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
Brandon Allbery allbery.b at gmail.com writes:
As I understand it, it's because fixing them involves passing around a
dictionary along with the data, and you can't do that with a standard
declaration (it amounts to an extra chunk of data that's only *sometimes*
wanted, and that sometimes
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
Good point, again. Is that the only problem with it?
On Thu, Apr 25, 2013 at 5:57 PM, Dan Doel dan.d...@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
I can't think of any at the moment that are still in force. However, one
that might have been relevant at the time is:
data C a = Foo a = Foo a a
foo :: Foo a - (a, a)
foo ~(Foo x y) = (x, y)
Irrefutable matches used to be disallowed for GADT-like things, which would
break the above
On 4/25/13 9:49 PM, Dan Doel wrote:
I don't really think they're worth saving in general, though. I haven't
missed them, at least.
The thing I've missed them for (and what I believe they were originally
designed for) is adding constraints to derived instances. That is, if I
have:
data Bar
2013-04-26 04:31, wren ng thornton skrev:
On 4/25/13 9:49 PM, Dan Doel wrote:
I don't really think they're worth saving in general, though. I haven't
missed them, at least.
The thing I've missed them for (and what I believe they were originally
designed for) is adding constraints to derived
20 matches
Mail list logo
