Difference between `newtype` and `data` with a strictness annotation
How does this code
data D = D { _d :: ![P] } -- Note the strictness annotation!
Compare to this
newtype D = D { _d :: [P] }
An answer to a related question says:
the main difference between data and newtype is that with data is that data constructors are lazy while newtype is strict
How does this difference work when the data version has a strictness annotation?
(the question is based on real code the I've stumbled on)
haskell lazy-evaluation newtype
asked Nov 20 '18 at 10:42
yairchu
15.5k75894
add a comment |
How does this code
data D = D { _d :: ![P] } -- Note the strictness annotation!
Compare to this
newtype D = D { _d :: [P] }
An answer to a related question says:
the main difference between data and newtype is that with data is that data constructors are lazy while newtype is strict
How does this difference work when the data version has a strictness annotation?
(the question is based on real code the I've stumbled on)
haskell lazy-evaluation newtype
asked Nov 20 '18 at 10:42
yairchu
15.5k75894
add a comment |
How does this code
data D = D { _d :: ![P] } -- Note the strictness annotation!
Compare to this
newtype D = D { _d :: [P] }
An answer to a related question says:
the main difference between data and newtype is that with data is that data constructors are lazy while newtype is strict
How does this difference work when the data version has a strictness annotation?
(the question is based on real code the I've stumbled on)
haskell lazy-evaluation newtype
asked Nov 20 '18 at 10:42
yairchu
15.5k75894
How does this code
data D = D { _d :: ![P] } -- Note the strictness annotation!
Compare to this
newtype D = D { _d :: [P] }
An answer to a related question says:
the main difference between data and newtype is that with data is that data constructors are lazy while newtype is strict
How does this difference work when the data version has a strictness annotation?
(the question is based on real code the I've stumbled on)
haskell lazy-evaluation newtype
haskell lazy-evaluation newtype
asked Nov 20 '18 at 10:42
yairchu
15.5k75894
asked Nov 20 '18 at 10:42
yairchu
15.5k75894
asked Nov 20 '18 at 10:42
yairchu
15.5k75894
asked Nov 20 '18 at 10:42
yairchu
15.5k75894
asked Nov 20 '18 at 10:42
yairchu
15.5k75894
15.5k75894
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
For instance,
case undefined of
D d -> "hello"
will error out for data types (strict or not strict), but will evaluate to "hello" for newtypes.
This is because, at runtime, applying a newtype constructor, or pattern matching on it corresponds to no operation. Not even forcing the value we case upon.
By contrast, pattern matching on a data constructor always forces the value we case upon.
I think this is the only runtime difference between strict data and newtype.
There are some static differences, such as some GHC extensions which only affect newtype, Coercible, etc., but at runtime the two types are isomorphic (but pattern matching operates differently, as shown above).
answered Nov 20 '18 at 10:56
chi
73.1k280135
So if no such pattern matching is done, there's absolutely no difference between the two?
– yairchu
Nov 20 '18 at 14:28
4
There should be a slight memory overhead with the strict data that isn't there with the newtype, but I don't remember if GHC can optimize that out.
– DarthFennec
Nov 20 '18 at 17:33
1
@yairchu I think so. There's a small memory overhead with strict data, as DarthFennec points out. Note that "if no such pattern matching" can be a big "if" -- pattern matching is everything for data types. E.g.case expensiveFunction 23 of D d -> ...performs the expensive computation immediately for big data, potentially keeping in memory a long listdfor a long time depending on the.... With a newtype, that list would be bound lazily, and only generated afterwards, when (and if) demanded by the....
– chi
Nov 20 '18 at 19:33
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53391237%2fdifference-between-newtype-and-data-with-a-strictness-annotation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
For instance,
case undefined of
D d -> "hello"
will error out for data types (strict or not strict), but will evaluate to "hello" for newtypes.
This is because, at runtime, applying a newtype constructor, or pattern matching on it corresponds to no operation. Not even forcing the value we case upon.
By contrast, pattern matching on a data constructor always forces the value we case upon.
I think this is the only runtime difference between strict data and newtype.
There are some static differences, such as some GHC extensions which only affect newtype, Coercible, etc., but at runtime the two types are isomorphic (but pattern matching operates differently, as shown above).
answered Nov 20 '18 at 10:56
chi
73.1k280135
So if no such pattern matching is done, there's absolutely no difference between the two?
– yairchu
Nov 20 '18 at 14:28
4
There should be a slight memory overhead with the strict data that isn't there with the newtype, but I don't remember if GHC can optimize that out.
– DarthFennec
Nov 20 '18 at 17:33
1
@yairchu I think so. There's a small memory overhead with strict data, as DarthFennec points out. Note that "if no such pattern matching" can be a big "if" -- pattern matching is everything for data types. E.g.case expensiveFunction 23 of D d -> ...performs the expensive computation immediately for big data, potentially keeping in memory a long listdfor a long time depending on the.... With a newtype, that list would be bound lazily, and only generated afterwards, when (and if) demanded by the....
– chi
Nov 20 '18 at 19:33
add a comment |
For instance,
case undefined of
D d -> "hello"
will error out for data types (strict or not strict), but will evaluate to "hello" for newtypes.
This is because, at runtime, applying a newtype constructor, or pattern matching on it corresponds to no operation. Not even forcing the value we case upon.
By contrast, pattern matching on a data constructor always forces the value we case upon.
I think this is the only runtime difference between strict data and newtype.
There are some static differences, such as some GHC extensions which only affect newtype, Coercible, etc., but at runtime the two types are isomorphic (but pattern matching operates differently, as shown above).
answered Nov 20 '18 at 10:56
chi
73.1k280135
So if no such pattern matching is done, there's absolutely no difference between the two?
– yairchu
Nov 20 '18 at 14:28
4
There should be a slight memory overhead with the strict data that isn't there with the newtype, but I don't remember if GHC can optimize that out.
– DarthFennec
Nov 20 '18 at 17:33
1
@yairchu I think so. There's a small memory overhead with strict data, as DarthFennec points out. Note that "if no such pattern matching" can be a big "if" -- pattern matching is everything for data types. E.g.case expensiveFunction 23 of D d -> ...performs the expensive computation immediately for big data, potentially keeping in memory a long listdfor a long time depending on the.... With a newtype, that list would be bound lazily, and only generated afterwards, when (and if) demanded by the....
– chi
Nov 20 '18 at 19:33
add a comment |
For instance,
case undefined of
D d -> "hello"
will error out for data types (strict or not strict), but will evaluate to "hello" for newtypes.
This is because, at runtime, applying a newtype constructor, or pattern matching on it corresponds to no operation. Not even forcing the value we case upon.
By contrast, pattern matching on a data constructor always forces the value we case upon.
I think this is the only runtime difference between strict data and newtype.
There are some static differences, such as some GHC extensions which only affect newtype, Coercible, etc., but at runtime the two types are isomorphic (but pattern matching operates differently, as shown above).
answered Nov 20 '18 at 10:56
chi
73.1k280135
For instance,
case undefined of
D d -> "hello"
will error out for data types (strict or not strict), but will evaluate to "hello" for newtypes.
This is because, at runtime, applying a newtype constructor, or pattern matching on it corresponds to no operation. Not even forcing the value we case upon.
By contrast, pattern matching on a data constructor always forces the value we case upon.
I think this is the only runtime difference between strict data and newtype.
There are some static differences, such as some GHC extensions which only affect newtype, Coercible, etc., but at runtime the two types are isomorphic (but pattern matching operates differently, as shown above).
answered Nov 20 '18 at 10:56
chi
73.1k280135
answered Nov 20 '18 at 10:56
chi
73.1k280135
answered Nov 20 '18 at 10:56
chi
73.1k280135
answered Nov 20 '18 at 10:56
chi
73.1k280135
73.1k280135
So if no such pattern matching is done, there's absolutely no difference between the two?
– yairchu
Nov 20 '18 at 14:28
4
There should be a slight memory overhead with the strict data that isn't there with the newtype, but I don't remember if GHC can optimize that out.
– DarthFennec
Nov 20 '18 at 17:33
1
@yairchu I think so. There's a small memory overhead with strict data, as DarthFennec points out. Note that "if no such pattern matching" can be a big "if" -- pattern matching is everything for data types. E.g.case expensiveFunction 23 of D d -> ...performs the expensive computation immediately for big data, potentially keeping in memory a long listdfor a long time depending on the.... With a newtype, that list would be bound lazily, and only generated afterwards, when (and if) demanded by the....
– chi
Nov 20 '18 at 19:33
add a comment |
So if no such pattern matching is done, there's absolutely no difference between the two?
– yairchu
Nov 20 '18 at 14:28
4
There should be a slight memory overhead with the strict data that isn't there with the newtype, but I don't remember if GHC can optimize that out.
– DarthFennec
Nov 20 '18 at 17:33
1
@yairchu I think so. There's a small memory overhead with strict data, as DarthFennec points out. Note that "if no such pattern matching" can be a big "if" -- pattern matching is everything for data types. E.g.case expensiveFunction 23 of D d -> ...performs the expensive computation immediately for big data, potentially keeping in memory a long listdfor a long time depending on the.... With a newtype, that list would be bound lazily, and only generated afterwards, when (and if) demanded by the....
– chi
Nov 20 '18 at 19:33
So if no such pattern matching is done, there's absolutely no difference between the two?
– yairchu
Nov 20 '18 at 14:28
So if no such pattern matching is done, there's absolutely no difference between the two?
– yairchu
Nov 20 '18 at 14:28
4
4
There should be a slight memory overhead with the strict data that isn't there with the newtype, but I don't remember if GHC can optimize that out.
– DarthFennec
Nov 20 '18 at 17:33
There should be a slight memory overhead with the strict data that isn't there with the newtype, but I don't remember if GHC can optimize that out.
– DarthFennec
Nov 20 '18 at 17:33
1
1
@yairchu I think so. There's a small memory overhead with strict data, as DarthFennec points out. Note that "if no such pattern matching" can be a big "if" -- pattern matching is everything for data types. E.g.
case expensiveFunction 23 of D d -> ... performs the expensive computation immediately for big data, potentially keeping in memory a long list d for a long time depending on the .... With a newtype, that list would be bound lazily, and only generated afterwards, when (and if) demanded by the ....– chi
Nov 20 '18 at 19:33
@yairchu I think so. There's a small memory overhead with strict data, as DarthFennec points out. Note that "if no such pattern matching" can be a big "if" -- pattern matching is everything for data types. E.g.
case expensiveFunction 23 of D d -> ... performs the expensive computation immediately for big data, potentially keeping in memory a long list d for a long time depending on the .... With a newtype, that list would be bound lazily, and only generated afterwards, when (and if) demanded by the ....– chi
Nov 20 '18 at 19:33
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53391237%2fdifference-between-newtype-and-data-with-a-strictness-annotation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
