[language] 只恨haskell的一个地方
 |
coolspeed
2008-12-02
haskell都很好，可就是为什么不用虚拟机实现？
这样岂不弄得像每个编译出来的程序都自带虚拟机一样繁冗？ |
 |
dogstar
2008-12-03
引用 haskell都很好，可就是为什么不用虚拟机实现？ 是为什么用,还是为什么不用?两句话,前后矛盾呀.haskell没用过,但是我估计是有虚拟机的,虚拟机是实现某些语言特性和功能的必需装备.lock-free data structure,貌似就必须vm.听牛人解答吧
|
|
coolspeed
2008-12-04
dogstar 写道 引用 haskell都很好，可就是为什么不用虚拟机实现？ 是为什么用,还是为什么不用?两句话,前后矛盾呀.haskell没用过,但是我估计是有虚拟机的,虚拟机是实现某些语言特性和功能的必需装备.lock-free data structure,貌似就必须vm.听牛人解答吧它是编译执行的，实际上是编译成C/C++源文件，进一步编译成native代码。貌似我说的没有矛盾吧？ |
 |
CloudiDust
2008-12-14
Haskell有虚拟机的。
生成本地码应该是为了性能~ 像ghci或者hugs也可以实现“解释”的说~ |
 |
lhyasia
2008-12-17
why vm?
|
|
fredchen
2008-12-21
我觉得编译成native code挺好的，这样虽然可执行文件大一点，但可以直接在没有安装haskell的电脑上执行，方便编写一些小工具给别人使用。
当然如果haskell能像ocaml那样，既有native compiler，也有bytecode compiler，那自然更好，但如果要我只选一项，我宁愿选择native的 要说haskell的不好，我觉得也真不少，其中最让我头疼的还是命名的冲突，例如用到ByteString时，就会有很多函数跟Prelude和System.IO里的名字冲突，只好小心翼翼的import，例如使用qualified import，或者加上hiding，或者用哪个函数就import哪个函数，需要的时候再加新的。这虽然好像是个微不足道的小问题，写代码的时候却是个大麻烦。 像面向对象语言在这方面就好多了，因为除了package/module/namespace的命名控制外，还有class这一层的控制，命名方面好控制多了 不知道各位有没有什么方法可以解决或者绕开这个问题？ |
|
pascal4123
2009-01-07
fredchen 写道 我觉得编译成native code挺好的，这样虽然可执行文件大一点，但可以直接在没有安装haskell的电脑上执行，方便编写一些小工具给别人使用。
当然如果haskell能像ocaml那样，既有native compiler，也有bytecode compiler，那自然更好，但如果要我只选一项，我宁愿选择native的 要说haskell的不好，我觉得也真不少，其中最让我头疼的还是命名的冲突，例如用到ByteString时，就会有很多函数跟Prelude和System.IO里的名字冲突，只好小心翼翼的import，例如使用qualified import，或者加上hiding，或者用哪个函数就import哪个函数，需要的时候再加新的。这虽然好像是个微不足道的小问题，写代码的时候却是个大麻烦。 像面向对象语言在这方面就好多了，因为除了package/module/namespace的命名控制外，还有class这一层的控制，命名方面好控制多了 不知道各位有没有什么方法可以解决或者绕开这个问题？ 命名冲突本没有万全之策，package/module/namespace之类只是减小冲突概率而已。 起名字还是不要偷懒为根本。 |
 |
Magicloud
2009-01-24
fredchen 写道 我觉得编译成native code挺好的，这样虽然可执行文件大一点，但可以直接在没有安装haskell的电脑上执行，方便编写一些小工具给别人使用。
当然如果haskell能像ocaml那样，既有native compiler，也有bytecode compiler，那自然更好，但如果要我只选一项，我宁愿选择native的 要说haskell的不好，我觉得也真不少，其中最让我头疼的还是命名的冲突，例如用到ByteString时，就会有很多函数跟Prelude和System.IO里的名字冲突，只好小心翼翼的import，例如使用qualified import，或者加上hiding，或者用哪个函数就import哪个函数，需要的时候再加新的。这虽然好像是个微不足道的小问题，写代码的时候却是个大麻烦。 像面向对象语言在这方面就好多了，因为除了package/module/namespace的命名控制外，还有class这一层的控制，命名方面好控制多了 不知道各位有没有什么方法可以解决或者绕开这个问题？ 我想按import的先后顺序覆盖最简单，但这和haskell的原则相违背。 |
|
glacjay
2009-02-18
coolspeed 写道 dogstar 写道 引用 haskell都很好，可就是为什么不用虚拟机实现？ 是为什么用,还是为什么不用?两句话,前后矛盾呀.haskell没用过,但是我估计是有虚拟机的,虚拟机是实现某些语言特性和功能的必需装备.lock-free data structure,貌似就必须vm.听牛人解答吧它是编译执行的，实际上是编译成C/C++源文件，进一步编译成native代码。貌似我说的没有矛盾吧？ 就 GHC 这个实现而言，它有一个解释器，就是那个 ghci，同 python 的命令行，同时你也可以解释执行某个 Haskell 源文件，不过得用 runhaskell 或者 runghc 。 然后，GHC 这个编译器的后端不是 C 也不是 C++，而是 C--，这是 SPJ 那家伙领导的一个项目，目的是实现一个比 C 更好的后端型语言，处在与 LLVM 相互竞争的层面上。而 C-- 就进一步的编译成本地代码。这样编译出来的程序就可以直接以二进制的形式来发布了。 至于 lz 所谓的 vm，这个甚至连 C 都有啊，就是 runtime library 嘛，只不过 C 的 runtime 不管在哪个操作系统上都是事先就有装，Haskell 的事先没装罢了，那就静态链接好了，方便发布。 |
|
glacjay
2009-02-18
fredchen 写道 我觉得编译成native code挺好的，这样虽然可执行文件大一点，但可以直接在没有安装haskell的电脑上执行，方便编写一些小工具给别人使用。
当然如果haskell能像ocaml那样，既有native compiler，也有bytecode compiler，那自然更好，但如果要我只选一项，我宁愿选择native的 要说haskell的不好，我觉得也真不少，其中最让我头疼的还是命名的冲突，例如用到ByteString时，就会有很多函数跟Prelude和System.IO里的名字冲突，只好小心翼翼的import，例如使用qualified import，或者加上hiding，或者用哪个函数就import哪个函数，需要的时候再加新的。这虽然好像是个微不足道的小问题，写代码的时候却是个大麻烦。 像面向对象语言在这方面就好多了，因为除了package/module/namespace的命名控制外，还有class这一层的控制，命名方面好控制多了 不知道各位有没有什么方法可以解决或者绕开这个问题？ 这个没什么问题啊，Haskell 的 import 默认相当于 Java 的 import xxx.*; Java 不就是不提倡这种写法嘛。如果说 Java 的命名空间的基本单位是 class 的话，那 Haskell 的就是 module 了。 |
