Haskell 中的语法糖

MMMIX

原帖由 cjacker 于 2009-4-13 16:02 发表


关于是否可以优雅的实现，既然您能认识到语言特性决定一般n元组无法实现，怎么还会质疑是否优雅的问题。

怎么不能质疑？虽然一般 n 元组和 Haskell 98 的类型系统冲突，但这也不意味着没有办法了，例如可以适当的扩展这个类型系统，或者使用一些其他手段，例如动态的代码生成。再说了，就算一时想不到什么更好的解决方案，质疑一下总是可以的。

cjacker

原帖由 MMMIX 于 2009-4-13 16:58 发表

怎么不能质疑？虽然一般 n 元组和 Haskell 98 的类型系统冲突，但这也不意味着没有办法了，例如可以适当的扩展这个类型系统，或者使用一些其他手段，例如动态的代码生成。再说了，就算一时想不到什么更好的解 ...

主要想说的是，语言特性已经决定了一般n元组无法实现(无法穷举)，那现有的实现也就无所谓优雅不优雅了，因为只能这么实现了，没有别的选择。

在实际使用的时候可以用Dynamic类型，其实关键还在于数据类型的确定性问题，如果一般n元组的元素数据类型无法确定，那么接受一般n元组的函数就要求出现多种类型的返回结果，这样的函数无法穷举定义，也不允许这么定义。
getElem n (..)，最后返回什么呢？

那最终的实现还是回到了统一成一致数据类型的元组(暂且叫元组)，其实就是列表了。

toDyn 1:toDyn "abc":toDyn 'c':[]
这个列表就是[Dynamic]类型，操作数据的时候仍然用列表函数就可以了，在最后使用数据时fromDyn就可以了，中间过程全部使用Dynamic类型。

这个过程有点像box和unbox。

ypyf3000

你才知道哦，去看一下源代码吧，揭示了一切，就是一个一个的，堆得像山高。。。不寒而栗

Magicloud

原帖由 cjacker 于 2009-4-13 21:21 发表

主要想说的是，语言特性已经决定了一般n元组无法实现(无法穷举)，那现有的实现也就无所谓优雅不优雅了，因为只能这么实现了，没有别的选择。

在实际使用的时候可以用Dynamic类型，其实关键还在于数据类型的 ...

我倒是同意MMMIX的说法，元组完全可以做的更好看。
我认为目前最根本的原因在于思想上，元组就没有作为一个数据类型出现。

MMMIX

原帖由 ypyf3000 于 2009-4-13 22:23 发表
你才知道哦，去看一下源代码吧，揭示了一切，

这话没错，但前提是要能看懂源码，有些 Haskell 的代码是不那么好懂的。下面就是 ($) 的源码,

1. 
   
2. infixr 0 $
   
3. ($) :: (a->b) -> a -> b
   
4. f $ x = f x
   

复制代码

这里有谁在第一次看到这个代码而且在没有看注释的情况下就完全理解了这段代码？反正我第一次是没有看明白。

MMMIX

原帖由 cjacker 于 2009-4-13 21:21 发表

主要想说的是，语言特性已经决定了一般n元组无法实现(无法穷举)，那现有的实现也就无所谓优雅不优雅了，

当然有是否优雅的问题了。判断出了时候优雅以后，才是它为什么优雅或者为什么不优雅。如果不优雅，要怎么做才能让它优雅。

因为只能这么实现了，没有别的选择。

总是有别的选择的。

Magicloud

原帖由 MMMIX 于 2009-4-14 11:21 发表

这话没错，但前提是要能看懂源码，有些 Haskell 的代码是不那么好懂的。下面就是 ($) 的源码,

infixr 0 $
($) :: (a->b) -> a -> b
f $ x = f x

这里有谁在第一次看到这个代码而且在没有看注释的情况 ...

f $ x = f x
我觉得这是最容易懂得了……甚至比 f . x 还容易……

MMMIX

原帖由 Magicloud 于 2009-4-14 13:46 发表

f $ x = f x
我觉得这是最容易懂得了……甚至比 f . x 还容易……

但是，你确定你完全理解它里面隐含的种种意思么？

Magicloud

原帖由 MMMIX 于 2009-4-14 14:04 发表

但是，你确定你完全理解它里面隐含的种种意思么？

没什么可隐含的吧，如果我已经完全理解了f x，那f $ x就没有更多需要领会的内容了。

MMMIX

原帖由 Magicloud 于 2009-4-14 16:21 发表

没什么可隐含的吧，如果我已经完全理解了f x，那f $ x就没有更多需要领会的内容了。

真敢说。。。