On 8 août 2015, at 14:40, Oliver Charles wrote:

There is reasonable reasoning here, but what you suggest breaks almost all Haskell code that has ever been written. Sounds like an idea better suited to the design of a new language :)

Maybe adding a language pragma or having both would avoid break any code?

Also, i think you need the newtype/data distinction as I believe they are operationally different wrt laziness.

Maybe keeping the `newtype` keyword would suffice? Alexey.

On Sat, Aug 08, 2015 at 04:23:15PM +0200, Corentin Dupont wrote:

One thing I quite don't understand is: do we really need to make the newtype/data distinction explicit?

I'm pretty sure we don't. newtype N = N A defines a datatype isomorphic to data D = D !A but you have to use it slightly differently, that's all. I wrote more about this here: http://stackoverflow.com/posts/21331284/revisions Tom

Hi Corentin, On 8 août 2015, at 17:23, Corentin Dupont wrote:

One thing I quite don't understand is: do we really need to make the newtype/data distinction explicit? If we used only one keyword, it should be quite easy for the compiler to detect the distinction statically.

I think someone more knowledgable in Haskell than me should answer this. Alexey.

Hi, Lars, On 8 août 2015, at 17:29, Lars Hupel wrote:

there is already an alternative syntax for declaring datatypes:

data Date where Date :: Int -> Int -> Int -> Date

data Anniversary where Birthday :: Name -> Date -> Anniversary Wedding :: Name -> Name -> Date -> Anniversary

This is called "GADT syntax" and can be enabled with -XGADTSyntax in GHC.*

Thank you for suggesting GADT, but i already knew about it. IMO this does not make the syntax with the equality sign (the one to which newcomers are introduced first) less weird :). Alexey.

+1 -------- Original Message -------- Subject: Re: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` From: Daniel Trstenjak To: haskell-cafe@haskell.org Date: 08/08/15 17:03

Hi Alexey,

...

type Name = String data Date = Date Int Int Int

if we're at it ;), then please change it to:

alias Name = String type Date = Date Int Int Int

Greetings, Daniel _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 08/08/2015, MigMit wrote:

That's ridiculous. The code would only be intuitive enough if it's written like this:

típus Név = Sor adat Időpont = Időpont Egész Egész Egész

+1 behozni Adat.Functor behozni Irányítás.Monad behozni Rendszer.BK -- bemenet-kimenet fő :: BK () fő = tenniSort "Helló, világ!"

Oh, you're right. We need to use Hungarian notation properly. Отправлено с iPad

8 авг. 2015 г., в 18:56, M Farkas-Dyck написал(а):

...

On 08/08/2015, MigMit wrote: That's ridiculous. The code would only be intuitive enough if it's written like this:

típus Név = Sor adat Időpont = Időpont Egész Egész Egész

Actually I think you missed the point here:

adat Időpont ahol Időpont :: Egész -> Egész -> Egész -> Időpont

Much better ☺

On 8 August 2015 at 08:03, Daniel Trstenjak wrote:

...

type Name = String data Date = Date Int Int Int

if we're at it ;), then please change it to:

alias Name = String type Date = Date Int Int Int

I wholeheartedly agree with replacing the current "type" with "alias", the current "type" is just flat out wrong: it does *not* create a type. This should be very simple to do too: introduce "alias" as a new keyword and deprecate "type". No existing code would be affected. I'm on the fence about "type" instead of "data", though. "data" clearly conveys the meaning that we are talking about data only, not functions on that data (as in OOP). (Well, data constructors are functions too.) Then again, as soon as you add "deriving", you *are* defining functions on that data.

I hate to come across as a party-pooper, but do we really think it's realistic that any of these changes will be made? I understand that there may be benefits, but they don't outweigh the cost of breaking almost all existing code. The idea of opting in to this with pragmas just doesn't seem worth it, and further fragments the language, ultimately reducing readability when I pick up another author's code. *ocharles* On Sat, Aug 8, 2015 at 7:29 PM Geraldus wrote:

type -> alias data -> data newtype -> newalias or newdata?

`type` keyword was really confusing for me at the beginning, also this confusion brought another one about `newtype` keyword.

сб, 8 авг. 2015 г. в 22:28, Hilco Wijbenga :

...

On 8 August 2015 at 08:03, Daniel Trstenjak wrote:

...

...

type Name = String data Date = Date Int Int Int

if we're at it ;), then please change it to:

alias Name = String type Date = Date Int Int Int

I wholeheartedly agree with replacing the current "type" with "alias", the current "type" is just flat out wrong: it does *not* create a type. This should be very simple to do too: introduce "alias" as a new keyword and deprecate "type". No existing code would be affected.

I'm on the fence about "type" instead of "data", though. "data" clearly conveys the meaning that we are talking about data only, not functions on that data (as in OOP). (Well, data constructors are functions too.) Then again, as soon as you add "deriving", you *are* defining functions on that data. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

One could discuss if "newtype" is really needed when we have "data" plus strictness annotations (personally I'm a bit unsure what the common use case for "case" is where they differ and what one might consider more natural).

Prelude> newtype A = A Int deriving Show Prelude> data B = B !Int deriving Show Prelude> let x = case x of A n -> A 1 in x A 1 Prelude> let y = case y of B n -> B 1 in y *** Exception: <<loop>>

P.S.: If you think this part of Haskell is a bit hard to read and confusing, I seriously propose a week or two in C++'s wonderful meta-programming world with templates... ;-)

Can't agree more

What you say is "if we don't use some perfectly legitimate language constructs and never use third-party code, than 'data' and 'newtype' are the same". That's certainly true, but that "if" is a very big one.

On 08 Aug 2015, at 22:49, Tom Ellis wrote:

On Sat, Aug 08, 2015 at 10:43:39PM +0200, MigMit wrote:

...

Prelude> newtype A = A Int deriving Show Prelude> data B = B !Int deriving Show Prelude> let x = case x of A n -> A 1 in x A 1 Prelude> let y = case y of B n -> B 1 in y *** Exception: <<loop>>

Sure, they're not exactly the same thing but if you get the translations right you can use them for the same purposes:

Prelude> let y = case y of b -> B 1 in y B 1

I list the translations here

http://stackoverflow.com/questions/21327740/strict-single-constructor-single...

Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Sat, Aug 8, 2015 at 5:11 PM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

No, not at all. I'm making a much stronger claim than that. I'm claiming the functionality provided by newtype is completely subsumed by that provided by data.

When did `data` start guaranteeing that the representation of a single constructor, strict `data' wrapper around another type is exactly the same as the wrapped type? -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Sat, Aug 8, 2015 at 5:16 PM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

On Sat, Aug 08, 2015 at 05:13:30PM -0400, Brandon Allbery wrote:

...

On Sat, Aug 8, 2015 at 5:11 PM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

...

No, not at all. I'm making a much stronger claim than that. I'm claiming the functionality provided by newtype is completely subsumed by that provided by data.

When did `data` start guaranteeing that the representation of a single constructor, strict `data' wrapper around another type is exactly the same as the wrapped type?

I make no claims about the operational semantics of existing compilers, but can you point out a reason why data of a single strict field *shuoldn't* be compiled in the same way as a newtype?

Because it's a bizarre special case compared to the way `data` works for everything else? Also, the behavior I described is not something that can just be ignored as an optimization in a particular compiler. It is part of the language specification. In fact, it is the *primary reason* for the existence of `newtype`. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

I won't say that's a legitimate concern. Representation doesn't matter here; if those two were indistinguishable (by Haskell code, without "hacks"), then the fact that they are represented differently would be irrelevant. But they ARE distinguishable, by a perfectly normal Haskell code.

On 08 Aug 2015, at 23:13, Brandon Allbery wrote:

On Sat, Aug 8, 2015 at 5:11 PM, Tom Ellis wrote: No, not at all. I'm making a much stronger claim than that. I'm claiming the functionality provided by newtype is completely subsumed by that provided by data.

When did `data` start guaranteeing that the representation of a single constructor, strict `data' wrapper around another type is exactly the same as the wrapped type?

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Sat, Aug 08, 2015 at 11:14:40PM +0200, MigMit wrote:

...

On 08 Aug 2015, at 23:11, Tom Ellis wrote:

On Sat, Aug 08, 2015 at 11:02:27PM +0200, MigMit wrote:

...

What you say is "if we don't use some perfectly legitimate language constructs and never use third-party code, than 'data' and 'newtype' are the same".

No, not at all. I'm making a much stronger claim than that. I'm claiming the functionality provided by newtype is completely subsumed by that provided by data.

Well, it's certainly unsupported by evidence. Because third-party code CAN distinguish between those.

OK, show me the code!

On Sat, Aug 08, 2015 at 11:18:18PM +0200, MigMit wrote:

...

On 08 Aug 2015, at 23:16, Tom Ellis wrote:

On Sat, Aug 08, 2015 at 11:14:40PM +0200, MigMit wrote:

...

...

On 08 Aug 2015, at 23:11, Tom Ellis wrote:

On Sat, Aug 08, 2015 at 11:02:27PM +0200, MigMit wrote:

...

What you say is "if we don't use some perfectly legitimate language constructs and never use third-party code, than 'data' and 'newtype' are the same".

No, not at all. I'm making a much stronger claim than that. I'm claiming the functionality provided by newtype is completely subsumed by that provided by data.

Well, it's certainly unsupported by evidence. Because third-party code CAN distinguish between those.

OK, show me the code!

I did. You removed it when quoting.

Reinstating:

...

Prelude> newtype A = A Int deriving Show Prelude> data B = B !Int deriving Show Prelude> let x = case x of A n -> A 1 in x A 1 Prelude> let y = case y of B n -> B 1 in y *** Exception: <<loop>>

This isn't third party code. It knows about the constructors of A and B.

On Sat, Aug 08, 2015 at 11:32:59PM +0200, MigMit wrote:

...

...

...

...

Well, it's certainly unsupported by evidence. Because third-party code CAN distinguish between those.

OK, show me the code!

I did. You removed it when quoting.

Reinstating:

...

...

Prelude> newtype A = A Int deriving Show Prelude> data B = B !Int deriving Show Prelude> let x = case x of A n -> A 1 in x A 1 Prelude> let y = case y of B n -> B 1 in y *** Exception: <<loop>>

This isn't third party code. It knows about the constructors of A and B.

1) This might be the code written by someone using your library/framework. In which case it would know about A and B.

Then it's up to me to define and document whatever strictness properties I want for my constructors. To reiterate: I'm *not* suggesting replacing newtype A = A a with data A = A! in existing code. Of course that won't work. But for *new* datatypes choosing one rather than the other gives no difference in terms of denotational semantics.

2) It might be generated by the Template Haskell — which is free to use whatever constructor is fed into it.

OK, so show me what goes wrong!

On Sun, Aug 09, 2015 at 12:16:27AM +0200, MigMit wrote:

...

...

1) This might be the code written by someone using your library/framework. In which case it would know about A and B.

Then it's up to me to define and document whatever strictness properties I want for my constructors.

Of course. But it's NOT up to you to restrict the user from using whatever techniques xe wants

Can you explain how any of this "restricts the user from using whatever techniques he wants"?

...

in existing code. Of course that won't work. But for *new* datatypes choosing one rather than the other gives no difference in terms of denotational semantics.

If it makes the difference for the old code, then it would make the difference for the new code as well.

I fail to see how. Breaking an API makes a difference for old code, but new code is written to the new API.

...

...

2) It might be generated by the Template Haskell — which is free to use whatever constructor is fed into it.

OK, so show me what goes wrong!

{-# LANGUAGE TemplateHaskell #-} module TH where import Language.Haskell.TH check :: Name -> ExpQ check c = [|let x = case x of $(conP c [[p|_|]]) -> $(conE c) 1 in x|]

Right, you can distinguish data declarations from newtype declarations this way, but by using Template Haskell you can also distinguish * data A = A Int * data A = A { a :: Int } * data A = A' Int * data A = A Int !(), and * newtype B = B A (where A has one of the above definitions) from each other. My claim is that * data B = B !A is as indistinguishable from the above four as they are from each other. Tom

On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote:

...

Right, you can distinguish data declarations from newtype declarations this way, but by using Template Haskell you can also distinguish

* data A = A Int * data A = A { a :: Int } * data A = A' Int * data A = A Int !(), and * newtype B = B A (where A has one of the above definitions)

Sure, because they are different.

...

from each other. My claim is that

* data B = B !A

is as indistinguishable from the above four as they are from each other.

Can you please NOT say that some thing can be distinguished AND that they are indistinguishable in the same post?

I think we are perhaps talking at cross purposes. To clarify, here is an explicit statement (somewhat weaker than the full generality of my claim): `data D = D !T` and `newtype N = N T` are isomorphic in the sense that there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and `g . f = id`. Do you agree or disagree with this statement? Then we may proceed. Tom

On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote:

I disagree.

Ah, good. A concrete point of disagreement. What, then, is wrong with the solution f :: D -> N f (D t) = N t g :: N -> D g (N t) = D t If you disagree that `f . g = id` and `g . f = id` then you must be able to find * a type `T` and either * `n :: N` such that `f (g n)` does not denote the same thing as `n` or * `d :: D` such that `g (f d)` does not denote the same thing as `d` Can you? Tom

...

9 авг. 2015 г., в 12:37, Tom Ellis написал(а): On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote:

...

...

Right, you can distinguish data declarations from newtype declarations this way, but by using Template Haskell you can also distinguish

* data A = A Int * data A = A { a :: Int } * data A = A' Int * data A = A Int !(), and * newtype B = B A (where A has one of the above definitions)

Sure, because they are different.

...

from each other. My claim is that

* data B = B !A

is as indistinguishable from the above four as they are from each other.

Can you please NOT say that some thing can be distinguished AND that they are indistinguishable in the same post?

I think we are perhaps talking at cross purposes.

To clarify, here is an explicit statement (somewhat weaker than the full generality of my claim):

`data D = D !T` and `newtype N = N T` are isomorphic in the sense that there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and `g . f = id`.

Do you agree or disagree with this statement? Then we may proceed.

On the contrary, it *is* the same thing Prelude> data D = D !Int deriving Show Prelude> D undefined *** Exception: Prelude.undefined Prelude> undefined :: D *** Exception: Prelude.undefined On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote:

First, the half that I agree with: f . g = id. No doubt.

But g . f > id. And the value "d" that you want is "undefined". g (f undefined) = D undefined, which is not the same as (undefined :: D).

Отправлено с iPad

...

9 авг. 2015 г., в 13:17, Tom Ellis написал(а):

...

On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: I disagree.

Ah, good. A concrete point of disagreement. What, then, is wrong with the solution

f :: D -> N f (D t) = N t

g :: N -> D g (N t) = D t

If you disagree that `f . g = id` and `g . f = id` then you must be able to find

* a type `T`

and either

* `n :: N` such that `f (g n)` does not denote the same thing as `n`

or

* `d :: D` such that `g (f d)` does not denote the same thing as `d`

Can you?

Tom

...

...

9 авг. 2015 г., в 12:37, Tom Ellis написал(а): On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote:

...

...

Right, you can distinguish data declarations from newtype declarations this way, but by using Template Haskell you can also distinguish

* data A = A Int * data A = A { a :: Int } * data A = A' Int * data A = A Int !(), and * newtype B = B A (where A has one of the above definitions)

Sure, because they are different.

...

from each other. My claim is that

* data B = B !A

is as indistinguishable from the above four as they are from each other.

Can you please NOT say that some thing can be distinguished AND that they are indistinguishable in the same post?

I think we are perhaps talking at cross purposes.

To clarify, here is an explicit statement (somewhat weaker than the full generality of my claim):

`data D = D !T` and `newtype N = N T` are isomorphic in the sense that there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and `g . f = id`.

Do you agree or disagree with this statement? Then we may proceed.

On Sun, Aug 09, 2015 at 07:49:10PM +0200, MigMit wrote:

You know, you've kinda conviced me.

I hope I'm correct then!

The difference between strict and non-strict parameters is in how constructors work. "data D = D Int" is still the same as "data D = D !Int", but it's constructor — as a function — is more restricted. It's somewhat like defining "d n = D $! n", and then not exporting D, but only d.

Right.

That said, it might be true that semantics differ depending on what is exported. So, it might be true that your D has the same semantics as N. We still can distinguish between those using various unsafe* hacks — but those are what they are: hacks.

Отправлено с iPad

...

9 авг. 2015 г., в 13:35, Tom Ellis написал(а):

On the contrary, it *is* the same thing

Prelude> data D = D !Int deriving Show Prelude> D undefined *** Exception: Prelude.undefined Prelude> undefined :: D *** Exception: Prelude.undefined

...

On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote: First, the half that I agree with: f . g = id. No doubt.

But g . f > id. And the value "d" that you want is "undefined". g (f undefined) = D undefined, which is not the same as (undefined :: D).

Отправлено с iPad

...

...

9 авг. 2015 г., в 13:17, Tom Ellis написал(а):

On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: I disagree.

Ah, good. A concrete point of disagreement. What, then, is wrong with the solution

f :: D -> N f (D t) = N t

g :: N -> D g (N t) = D t

If you disagree that `f . g = id` and `g . f = id` then you must be able to find

* a type `T`

and either

* `n :: N` such that `f (g n)` does not denote the same thing as `n`

or

* `d :: D` such that `g (f d)` does not denote the same thing as `d`

Can you?

Tom

...

...

9 авг. 2015 г., в 12:37, Tom Ellis написал(а): On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: >> Right, you can distinguish data declarations from newtype declarations this >> way, but by using Template Haskell you can also distinguish >> >> * data A = A Int >> * data A = A { a :: Int } >> * data A = A' Int >> * data A = A Int !(), and >> * newtype B = B A (where A has one of the above definitions) > > Sure, because they are different. > >> from each other. My claim is that >> >> * data B = B !A >> >> is as indistinguishable from the above four as they are from each other. > > Can you please NOT say that some thing can be distinguished AND that they > are indistinguishable in the same post?

I think we are perhaps talking at cross purposes.

To clarify, here is an explicit statement (somewhat weaker than the full generality of my claim):

`data D = D !T` and `newtype N = N T` are isomorphic in the sense that there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and `g . f = id`.

Do you agree or disagree with this statement? Then we may proceed.

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

El Aug 10, 2015, a las 7:38, Jonas Scholl escribió:

There is still a difference between a data type with one strict field and a newtype: You can strip the constructor of a newtype without evaluating anything.

Suppose we have

data D = D !D

data N = N N

This should be "newtype N = N N", no? Tom

d :: D d = D d

n :: N n = N n

d and n both evaluate to bottom, but it is possible to pattern match on (N t) and succeed, while matching on (D t) does not. Example:

mkDs :: Int -> D -> String mkDs i (D t) | i <= 0 = [] | otherwise = 'd' : mkDs (i - 1) t

mkNs :: Int -> N -> String mkNs i (N t) | i <= 0 = [] | otherwise = 'n' : mkNs (i - 1) t

Evaluating mkNs 5 n returns "nnnnn", while evaluating mkDs 5 d loops forever. Now we can define:

f :: D -> N f (D t) = N (f t)

g :: N -> D g (N t) = D (g t)

id1 :: D -> D id1 = g . f

id2 :: N -> N id2 = f . g

If both representations should be equal, we should get that mkNs 5 n == mkNs 5 (id2 n). But id2 converts everything to the D type first, which is only inhabited by _|_, and then pattern matches on it. So we get "nnnnn" == _|_, which is obviously false. If we change f to use a lazy pattern match, the equality holds again. So D and N are maybe equivalent if we allow only lazy pattern matches on D. As this is not the case, the two are clearly not equivalent.

On 08/09/2015 11:10 PM, Tom Ellis wrote:

...

On Sun, Aug 09, 2015 at 07:49:10PM +0200, MigMit wrote:

...

You know, you've kinda conviced me.

I hope I'm correct then!

...

The difference between strict and non-strict parameters is in how constructors work. "data D = D Int" is still the same as "data D = D !Int", but it's constructor — as a function — is more restricted. It's somewhat like defining "d n = D $! n", and then not exporting D, but only d.

Right.

...

That said, it might be true that semantics differ depending on what is exported. So, it might be true that your D has the same semantics as N. We still can distinguish between those using various unsafe* hacks — but those are what they are: hacks.

Отправлено с iPad

...

9 авг. 2015 г., в 13:35, Tom Ellis написал(а):

On the contrary, it *is* the same thing

Prelude> data D = D !Int deriving Show Prelude> D undefined *** Exception: Prelude.undefined Prelude> undefined :: D *** Exception: Prelude.undefined

...

On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote: First, the half that I agree with: f . g = id. No doubt.

But g . f > id. And the value "d" that you want is "undefined". g (f undefined) = D undefined, which is not the same as (undefined :: D).

Отправлено с iPad

...

> 9 авг. 2015 г., в 13:17, Tom Ellis написал(а): > > On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: > I disagree.

Ah, good. A concrete point of disagreement. What, then, is wrong with the solution

f :: D -> N f (D t) = N t

g :: N -> D g (N t) = D t

If you disagree that `f . g = id` and `g . f = id` then you must be able to find

* a type `T`

and either

* `n :: N` such that `f (g n)` does not denote the same thing as `n`

or

* `d :: D` such that `g (f d)` does not denote the same thing as `d`

Can you?

Tom

>> 9 авг. 2015 г., в 12:37, Tom Ellis написал(а): >> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: >>>> Right, you can distinguish data declarations from newtype declarations this >>>> way, but by using Template Haskell you can also distinguish >>>> >>>> * data A = A Int >>>> * data A = A { a :: Int } >>>> * data A = A' Int >>>> * data A = A Int !(), and >>>> * newtype B = B A (where A has one of the above definitions) >>> >>> Sure, because they are different. >>> >>>> from each other. My claim is that >>>> >>>> * data B = B !A >>>> >>>> is as indistinguishable from the above four as they are from each other. >>> >>> Can you please NOT say that some thing can be distinguished AND that they >>> are indistinguishable in the same post? >> >> I think we are perhaps talking at cross purposes. >> >> To clarify, here is an explicit statement (somewhat weaker than the full >> generality of my claim): >> >> `data D = D !T` and `newtype N = N T` are isomorphic in the sense that >> there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and >> `g . f = id`. >> >> Do you agree or disagree with this statement? Then we may proceed.

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

I'm not claiming that they should behave the same with regard to the *syntax* of case analysis (NB case analysis of newtypes is already treated specially since the constructor doesn't actually exist). Again I refer interested parties to my proposed translation between the two methods of defining types: http://stackoverflow.com/posts/21331284/revisions Does this answer your objection? Tom On Mon, Aug 10, 2015 at 01:38:23PM +0200, Jonas Scholl wrote:

There is still a difference between a data type with one strict field and a newtype: You can strip the constructor of a newtype without evaluating anything.

Suppose we have

data D = D !D

data N = N N

d :: D d = D d

n :: N n = N n

d and n both evaluate to bottom, but it is possible to pattern match on (N t) and succeed, while matching on (D t) does not. Example:

mkDs :: Int -> D -> String mkDs i (D t) | i <= 0 = [] | otherwise = 'd' : mkDs (i - 1) t

mkNs :: Int -> N -> String mkNs i (N t) | i <= 0 = [] | otherwise = 'n' : mkNs (i - 1) t

Evaluating mkNs 5 n returns "nnnnn", while evaluating mkDs 5 d loops forever. Now we can define:

f :: D -> N f (D t) = N (f t)

g :: N -> D g (N t) = D (g t)

id1 :: D -> D id1 = g . f

id2 :: N -> N id2 = f . g

If both representations should be equal, we should get that mkNs 5 n == mkNs 5 (id2 n). But id2 converts everything to the D type first, which is only inhabited by _|_, and then pattern matches on it. So we get "nnnnn" == _|_, which is obviously false. If we change f to use a lazy pattern match, the equality holds again. So D and N are maybe equivalent if we allow only lazy pattern matches on D. As this is not the case, the two are clearly not equivalent.

On 08/09/2015 11:10 PM, Tom Ellis wrote:

...

On Sun, Aug 09, 2015 at 07:49:10PM +0200, MigMit wrote:

...

You know, you've kinda conviced me.

I hope I'm correct then!

...

The difference between strict and non-strict parameters is in how constructors work. "data D = D Int" is still the same as "data D = D !Int", but it's constructor — as a function — is more restricted. It's somewhat like defining "d n = D $! n", and then not exporting D, but only d.

Right.

...

That said, it might be true that semantics differ depending on what is exported. So, it might be true that your D has the same semantics as N. We still can distinguish between those using various unsafe* hacks — but those are what they are: hacks.

Отправлено с iPad

...

9 авг. 2015 г., в 13:35, Tom Ellis написал(а):

On the contrary, it *is* the same thing

Prelude> data D = D !Int deriving Show Prelude> D undefined *** Exception: Prelude.undefined Prelude> undefined :: D *** Exception: Prelude.undefined

...

On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote: First, the half that I agree with: f . g = id. No doubt.

But g . f > id. And the value "d" that you want is "undefined". g (f undefined) = D undefined, which is not the same as (undefined :: D).

Отправлено с iPad

...

> 9 авг. 2015 г., в 13:17, Tom Ellis написал(а): > > On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: > I disagree.

Ah, good. A concrete point of disagreement. What, then, is wrong with the solution

f :: D -> N f (D t) = N t

g :: N -> D g (N t) = D t

If you disagree that `f . g = id` and `g . f = id` then you must be able to find

* a type `T`

and either

* `n :: N` such that `f (g n)` does not denote the same thing as `n`

or

* `d :: D` such that `g (f d)` does not denote the same thing as `d`

Can you?

Tom

>> 9 авг. 2015 г., в 12:37, Tom Ellis написал(а): >> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: >>>> Right, you can distinguish data declarations from newtype declarations this >>>> way, but by using Template Haskell you can also distinguish >>>> >>>> * data A = A Int >>>> * data A = A { a :: Int } >>>> * data A = A' Int >>>> * data A = A Int !(), and >>>> * newtype B = B A (where A has one of the above definitions) >>> >>> Sure, because they are different. >>> >>>> from each other. My claim is that >>>> >>>> * data B = B !A >>>> >>>> is as indistinguishable from the above four as they are from each other. >>> >>> Can you please NOT say that some thing can be distinguished AND that they >>> are indistinguishable in the same post? >> >> I think we are perhaps talking at cross purposes. >> >> To clarify, here is an explicit statement (somewhat weaker than the full >> generality of my claim): >> >> `data D = D !T` and `newtype N = N T` are isomorphic in the sense that >> there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and >> `g . f = id`. >> >> Do you agree or disagree with this statement? Then we may proceed.

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

One moment, please, the good reason has been provided -- newbie confusion.

I'm really happy that we are at the stage when this is considered an important source of newbie confusion in Haskell.

So, in the end, the idea will probably be shot down -- but please, let's shoot it down for a good reason, with a clear, irrefutable understanding of why.

The reason is very simple, and it was stated several times already: it will break everything that was written so far, and there is not enough evidence that things would be even a little better. In fact, moving to dynamic typing would a) break less existing code (could be none, if done carefully), and b) remove A LOT of newbie confusion, but for some reason I don't think it's a good idea either.

Brandon Allbery writes:

Haskell may be new to you personally. That does not mean that it's okay to break what, more than 15 years worth of code?

I don't mean to come across argumentative -- rather I merely want to point out, that the way of accomplishing it in a non-breaking way was proposed in this thread: an extra keyword + a pragma to guard against name clashes. Whether it's worth the trouble or not -- again, I have no opinion of my own. Please, let's discuss the idea on its merit, and not criticize some flawed version of it. -- respectfully, Косырев Серёга -- “And those who were seen dancing were thought to be insane by those who could not hear the music.” – Friedrich Wilhelm Nietzsche

Brandon Allbery writes:

On Sat, Aug 8, 2015 at 5:21 PM, Kosyrev Serge <_deepfire@feelingofgreen.ru> wrote:

I don't mean to come across argumentative -- rather I merely want to point out, that the way of accomplishing it in a non-breaking way was proposed in this thread: an extra keyword + a pragma to guard against name clashes.

Not worth the fact that I now have to look for two effectively incompatible languages both calling themselves Haskell.

Do you mean that adding a new keyword to the language, guarded by a language extension, really deserves this strong wording -- "effectively incompatible"? What about the precedents? - TransformListComp: group, by, using - RecursiveDo: mdo, rec Then, I guess there was a number of keywords introduced by Haskell 2010. -- respectfully, Косырев Серёга -- “And those who were seen dancing were thought to be insane by those who could not hear the music.” – Friedrich Wilhelm Nietzsche

On Sat, Aug 8, 2015 at 5:33 PM, Kosyrev Serge <_deepfire@feelingofgreen.ru> wrote:

What about the precedents?

- TransformListComp: group, by, using - RecursiveDo: mdo, rec

If I see those then I know that something is going on. If I don't see `data` and do see some new keyword in its place then I am not reading Haskell code; I know this because I have Haskell code and it uses `data`. If I see `data` and it means something different than what Haskell means by `data`? Oh right, you have decided your incompatible language is still "Haskell", I just have to deal with the fact that it means something completely different now. Have you ever come back to a project 6 months after you last worked on it, or a year after, and had to figure it out again? Consider how well that works when you've decided to mutate the language in the meantime, and your mission critical code was not permitted to be rewritten in the new language because it is mission critical and "oh just run this automated script to fix it" is not a plan that passes business review processes. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

It's generally considered OK to break small parts of code. For example, the infamous n+k patterns — if I remember correctly, they are still here, but you have to enable them explicitly. It breaks SOME code, but not a lot of it. We might even break a lot of code, but we surely need a VERY good reason to do that.

On 08 Aug 2015, at 23:27, Hilco Wijbenga wrote:

On 8 August 2015 at 14:03, Brandon Allbery wrote:

...

This is quite important, folks. Don't tell us how tools will mitigate this. Go look at Python 3's adoption rate --- and it does have the tools --- and tell me again how well that path works for an established language. (Hint: every Python package I use has no intention of moving to Python 3.)

That seems like a red herring to me. Python does not have a type system to speak of so even simple refactoring is painful. Let alone making changes to the language itself...

...

Haskell may be new to you personally. That does not mean that it's okay to break what, more than 15 years worth of code?

So when is it okay? :-) Still, if proper tooling automates it, why not?

(I'm not advocating making language changes willy-nilly but the argument "it breaks existing code" [in and of itself] implies we are stuck with all mistakes made in the past. Language designers are human too. We need a way forward.)

On 8 August 2015 at 14:46, Brandon Allbery wrote:

On Sat, Aug 8, 2015 at 5:27 PM, Hilco Wijbenga wrote:

...

So when is it okay? :-) Still, if proper tooling automates it, why not?

Because your tooling does not rewire people's brains and does not automatically run itself on other people's programs when you *look* at them.

I don't think we need to "rewire" our brains to accommodate a few language tweaks. The haskell-fix tool I had in mind would change the source code so you would look at the fixed code. But, yes, there would be a transition time. In my experience that is true for any change to your code base.

Because not everyone builds houses of cards and leaves them to collapse on their successor while they go chase the next cool thing, like certain modern "web programmers" who seems to have confused "agile" with "fragile" and therefore think Go rewriting its syntax every week is somehow sensible. And not everyone *can* do things the zero-memory-change-it-all-who-cares-it'll-all-be-different-next-week way; that does not fly on the business end, for example. (I've had people claim to me that they do that with accounting packages. I bet they've never faced an audit and will be learning the hard way why business does not work that way when the auditors *do* show up.)

You seem to be creating a whole mountain range out of a mole hill. :-) I have to maintain a very low quality, legacy code base. So I totally sympathize with the "house of cards" and "fragile" part of your paragraph. But after that I have a hard time making sense of it. Nobody is advocating changing Haskell to look like a completely different language. Or that we start making language changes every week. I really do not understand where you got that impression. Everybody is talking about tiny language tweaks that (hopefully) make the language better. If the agreement is that, yes, it does make the language better than the blanket counter argument "it breaks existing code" should not stop progress. If you don't make improvements now because of existing code then tomorrow there will be more existing code and thus even more inertia.

2015-08-09 1:01 GMT+02:00 Hilco Wijbenga :

On 8 August 2015 at 14:46, Brandon Allbery wrote: [...] Everybody is talking about tiny language tweaks that (hopefully) make the language better. If the agreement is that, yes, it does make the language better than the blanket counter argument "it breaks existing code" should not stop progress. If you don't make improvements now because of existing code then tomorrow there will be more existing code and thus even more inertia.

This is flawed reasoning, ignoring basically all reality in business, larger projects, legacy projects etc.: Of course languages should evolve, but there is always a cost associated with it, and this should outweigh the disadvantages. And I can't see this happening here at all: We are talking about perhaps 5min of confusion (if at all) when starting Haskell compared to millions (billions?) of existing LOC perhaps needing a change (or not, who knows?), books (which can't be updated by something like 'gofix'), brains of people using Haskell for over a decade etc. Programming languages are just like natural languages: Even if they are often irregular, they form a common ground for communication and understanding each other. Do we need irregular verbs? No. But try to take them away from native speakers... :-) Are irregular verbs really a problem? No. When you are fluent in a language you don't even think about them anymore.

Will Yager writes:

Obviously a change like this would be horribly destructive to existing code, and for relatively little benefit.

Hidden behind a pragma -- is it really that horribly destructive?

There are much larger barriers to understanding Haskell than syntactic trivia like the one mentioned here.

Barriers exist at every level of mastery -- the ones that matter are those present at the exact point of one's progression. It is, of course, true that at some point the little awkwardness exits the picture completely -- but for any point of time, there always will be a nontrivial set of people thinking to themselves -- "what the heck?!".

It is worth asking, then, if we should record these small aesthetic suggestions somewhere for consideration while designing the next major compatibility-breaking release of the Haskell specification (Haskell 2020 or what have you).

Now this is exactly the kind of assessment that I have been hoping to hear! And the idea is that, before the next release of the language specification, it is possible to experiment with the keyword hidden behind the pragma -- and should the result prove satisfactory, all that remains to do is to lift the pragma requirement. Maybe a unified playground for such tweaks -- XNewSyntax, for example. Or do people suggest, that it should somehow suddenly materialise in the next release of the specification, without touching any staging ground? -- respectfully, Косырев Серёга -- “And those who were seen dancing were thought to be insane by those who could not hear the music.” – Friedrich Wilhelm Nietzsche

GHC ships with a solution to the original problem about a very confusing `=`: GADT syntax. I *don't* mean GADTs, in all their glory. It has been correctly observed that GADTs are not for the beginner. But there's nothing wrong at all with GADT syntax:

data Maybe a where Just :: a -> Maybe a Nothing :: Maybe a

This syntax seems to fix the original poster's problem, and more besides. I've had several beginners complain about things like `data Foo = MkFoo Int`, in that we see the phrase `MkFoo Int`, but these two things -- a data constructor and a type -- belong to two very different parts of the syntax. GADT syntax gets rid of these problems. Perhaps tutorials/teachers should just introduce GADT syntax and mention traditional syntax as a historical note. GHC even has the -XGADTSyntax extension to allow the syntax without full-blown GADTs. To respond to two other strands of this thread: - Beyond the difference already observed between `data` and `newtype`, using `newtype` also works with GHC's Coercible mechanism. This is, of course, GHC-specific and not part of standard Haskell, but I thought it worth mentioning. See https://wiki.haskell.org/GHC/Coercible - Haskellers are, of course, welcome to change keywords in their files via CPP. This works, for example:

#define datatype data #define alias type

datatype Boolean = F | T alias IsGood = Boolean

invert :: IsGood -> IsGood invert T = F invert F = T

You can even specify such things via the command line via the -D option, so you could create a wrapper around GHC that added the necessary -D options and then you'd have your new language, with nothing extra in your source files. Good luck sharing your code though! Note that this solution is functionally equivalent to hiding the change behind a pragma. Richard

On 8 August 2015 at 12:14, Oliver Charles wrote:

I hate to come across as a party-pooper, but do we really think it's realistic that any of these changes will be made? I understand that there may be benefits, but they don't outweigh the cost of breaking almost all existing code. The idea of opting in to this with pragmas just doesn't seem worth it, and further fragments the language, ultimately reducing readability when I pick up another author's code.

I have no doubt that you are right: nothing will change. However... I don't agree that "it breaks existing code" is a valid argument (in and of itself). You can stick with whatever version of the compiler you are currently using. Nobody is forcing you to change *immediately*. Holding a programming language hostage because of the existing code base is irresponsible. Having said that, changing the language "often" is also irresponsible. So it should only happen, say, every 5 years. More importantly, it should be done by means of a tool (a la gofix, see [1]). Especially with a language like Haskell, it should be relatively simple to create a haskell-fix tool that replaces deprecated structure/syntax with its new-and-improved alternative. Make haskell-fix a standard part of the toolchain and most (all?) problems related to language changes disappear. (I would be very interested to know whether the availability of such a haskell-fix tool would change people's opinion about making language changes.) [1] http://blog.golang.org/introducing-gofix

On 9/08/2015, at 5:28 am, Hilco Wijbenga wrote:

I wholeheartedly agree with replacing the current "type" with "alias",

That would be to replace a precise time with a vague one. All sorts of things can be aliased. Especially when someone writes code that I would like to use, but writes it with an American accent, I would very much like to be able to do things *like* alias Colour = Color and I would like to do this for types, for modules, for constructors, for plain functions, &c. I am not saying that the same *form* of declaration should be used in each case, but that declarations all using the _word_ 'alias' should be available to make it quite plain to the reader what is going on. In particular, there is currently no way to give an additional name to a constructor that lets you *use* it as a constructor. 'alias' is far too potentially useful a word to squander this way. Consider ML: val thingy = 42 This says that 'thingy' is another name for the val(ue) 42. It's an equality for values. type 'a sequence = 'a list This says that for any type 't, 't sequence is another name for the type 't list. It's an equality for types. Type is the *perfect* word here, in ML. Now Haskell does not the 'val' keyword (nor the 'fun' keyword) and it doesn't need them. But it *does* have two kinds of type declaration, one of which *IS* a type equality type Sequence t = [t] and *looks like it*, and one of which ISN'T a type equality. If you want to argue about the grammar of 'data' declarations, go right ahead. I myself was a little confused by them at the beginning, because the declare a new type and some constructors, but do not declare 'data' in the sense that a DATA statement in BASIC or Fortran or the DATA DIVISION in COBOL does. The word 'data' is so very far from conveying the idea "introduce a new type" that it's not funny. But to be confused by 'type' declarations? That's, well, alien. Especially as in the Haskell teaching material I'm familiar with, people are introduced to 'type' declarations doing the utterly familiar 'introduce a new name for an old type' thing before they're introduced to 'data'.

the current "type" is just flat out wrong: it does *not* create a type.

AND IT DOES NOT *CLAIM* TO CREATE A TYPE. It claims to state a type EQUALITY, and it really does. It's just like if you write answer = 42 This does NOT define a new constant. It gives a new name for an existing value. Next thing someone will say that this ought to be written value_alias answer = 42 or something.

On 18/08/2015, at 6:49 pm, Daniel Trstenjak wrote:

Hi Richard,

...

AND IT DOES NOT *CLAIM* TO CREATE A TYPE. It claims to state a type EQUALITY, and it really does.

I can understand your reasoning and only looking at 'type' it's fine, but you've to look at 'type/newtype/data' at once, and if 'data' is strangely named, what other name would you take for it?

Oh, I _have_ looked at them all at once. In fact looking at them all at once was precisely what made it easy to understand them. newtype *says* it introduces a new type, and it *does*. The distinction between type and newtype makes it extremely hard to be confused about 'type', or any rate hard to both be awake and *remain* confused for long. What name would I have used for 'data'? While 'newtype T x = T x' and 'data T x = T !x' _aren't_ exactly the same in Haskell, they _could_ have been, and then 'newtype' would have been the perfect replacement for 'data'. The fact that 'newtype' and 'data' *both* introduce new types is surely the one confusing point here. But again, this makes 'data' the confusing keyword, not 'type' and not 'newtype'. More precisely, we could have had something like newtype T x = ~T !x {- current newtype -} newtype C x = A | B x | C x x { - current data -} or some such distinction. But we have what we have, and it certainly isn't *more* confusing than F# or Clean. If this is the worst problem beginners have, Haskell must be in wonderful shape.

...

It's just like if you write

answer = 42

This does NOT define a new constant. It gives a new name for an existing value. Next thing someone will say that this ought to be written

value_alias answer = 42

or something.

But with this point of view 'type Sequence t = [t]' is also somehow bogus and should just be 'Sequence t = [t]'.

WRONG. Type names and function names live in different namespaces. 'type' is NECESSARY to specify the namespace that Sequence lives in.

It sort of should I think. In Idris I believe closed type families just use regular function syntax, can be declared inside of let-bindings, have type signatures themselves, and otherwise syntactically behave just like the value level equivalents. I'm hoping at some point goldfire's dependent Haskell work will eventually lead to the same in Haskell, though I know from his comments on reddit that this is very far off from being a reality. Daniel Trstenjak-2 wrote

But with this point of view 'type Sequence t = [t]' is also somehow bogus and should just be 'Sequence t = [t]'.

Greetings, Daniel _______________________________________________ Haskell-Cafe mailing list

Haskell-Cafe@

http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- View this message in context: http://haskell.1045720.n5.nabble.com/an-idea-for-modifiyng-data-newtype-synt... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Anybody who comes acros "data _ = _" and feels entitled to understand it before looking up the data keyword is being too lazy. On Wed, Aug 19, 2015 at 1:09 AM, Alexey Muranov wrote:

On 18 août 2015, at 08:16, Richard A. O'Keefe wrote:

...

If you want to argue about the grammar of 'data' declarations, go right ahead. I myself was a little confused by them at the beginning, because the declare a new type and some constructors, but do not declare 'data' in the sense that a DATA statement in BASIC or Fortran or the DATA DIVISION in COBOL does. The word 'data' is so very far from conveying the idea "introduce a new type" that it's not funny.

Ok, then, just hypothetically (i do not want to argue about actually introducing it), how about

type Name = String type Date ::= Date Int Int Int type Anniversary ::= Birthday Name Date | Wedding Name Name Date

instead of

type Name = String data Date = Date Int Int Int data Anniversary = Birthday Name Date | Wedding Name Name Date

?

Alexey. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe