Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P82-83 Double# vs Double vs undefined #28

Open
boboyada opened this issue Jan 4, 2017 · 5 comments
Open

P82-83 Double# vs Double vs undefined #28

boboyada opened this issue Jan 4, 2017 · 5 comments

Comments

@boboyada
Copy link

boboyada commented Jan 4, 2017

undefined 表示 "底",无法计算的值
P82第一、第二行,Cm,Inch 两类型,
x = Cm 3 x直接指向Double, 此时可以表示 "底",表示无法计算的值

y=Inch 4 y直接指向Double#,此时,不可以表示 "底",不可以表示无法计算的值,y虽然节约了时间,面对y这个thunk,此时就不担心计算“危险”吗?

@winterland1989
Copy link
Owner

不是很理解你的问题哈,任何thunk求值都有可能返回bottom(比如遇到error),增加一次跳转也并不能改变这个事情。关于newtype带来的严格性变化可以参考 https://wiki.haskell.org/Newtype 。 或者你再细化下你的问题?

@boboyada
Copy link
Author

boboyada commented Jan 11, 2017

P82页
data Cm = Cm Double
x = Cm 3
涉及到Cm盒子,Double盒子,Double#三个盒子,其中前二个盒子都包含了undefined的能力,Double#则不包含undefined的能力

newtype Inch = Inch Double
y=Inch 4
涉及到Inch盒子,Double#二个盒子,其中前一个盒子也包含了undefined的能力,Double#则不包含undefined的能力

书上解释,y减少了一次Double的打包和解包的过程。
???而我奇怪的则是:之所以要打包,就是为了解决 bottom ,以扩展Double#,Int#等包含undefined这种能力。
可现在通过newtype,却又取消了这种能力,岂非矛盾?
还是说,在这个例子中,Inch这个盒子的 bottom,,会与Double盒子上的bottom重叠,如此一来,Double就多余了?

@winterland1989
Copy link
Owner

请仔细阅读关于newtypedata的区别,newtype的引入恰恰就是为了避免运行时额外的boxing/unboxing。

@boboyada
Copy link
Author

newtype的引入既然是为了避免运行时额外的boxing/unboxing,但newtype规定只能是单构造单参数的类型。感觉好像是说 单构造函数单参数的newtype才可以避免一次boxing/unboxing了?多构造函数或多参数,haskell就无法实现boxing/unboxing?

@winterland1989
Copy link
Owner

winterland1989 commented Jan 13, 2017

目前来说是这样,但是之后随着unlifted data的发展,可能这个限制会得到消除。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants