为什么lisp,或者说common lisp现在这么冷门呢?


#173

比如Paxos?

那没理由啊,rustc后端也是LLVM来着


#174

比如前面提到的 Stalin 作为反驳"动态类型语言很难推导XXX"就没什么说服力。对了,上面还提到了证明。虽然那个证明和研究邻域的证明说的不是一个东西,但搞证明适合用的邻域也比较狭窄。

然而你看 clang 走正常编译流程会执行的代码就是个前端而已,基本上没做优化。Rustc 也不算慢了,我看过一些 rust 各种场合下和 gcc、clang/llvm 的比较,很接近的。有比不过的地方就是安全的代价吧。


#175

Paul Graham 在书里说长远来说静态语言没戏,动态语言更灵活强大啊~~
我已经被洗脑了啊


#176

不是看汇编吗~~🤣?

Rust 这语言一直没了解过,在你们语调看来是很有前景的知识,就是传说中的R语言吗?

Lisp 都完全没学够啊~~ Rust有什么比Lisp更犀利的地方吗?


#177

GHC (with -O, as always) tries to inline (or “unfold”) functions/values that are “small enough,” thus avoiding the call overhead and possibly exposing other more-wonderful optimisations. GHC has a set of heuristics, tuned over a long period of time using many benchmarks, that decide when it is beneficial to inline a function at its call site. The heuristics are designed to inline functions when it appears to be beneficial to do so, but without incurring excessive code bloat. If a function looks too big, it won’t be inlined, and functions larger than a certain size will not even have their definition exported in the interface file. Some of the thresholds that govern these heuristic decisions can be changed using flags, see -f: platform-independent flags* .

至于为啥我解读成“默认 inline 所有函数”,指 GHC 会对所有函数考虑 inline 的可行性。

https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.html#inline-and-noinline-pragmas


#178

冯诺伊曼还因为学生用汇编而不是写机器码发火哩,今天还有人会在意汇编和机器码的区别么?人要向后看,几十年后完全犯不着在用静态还是动态语言上争论。


#179

这个时代已经过去了。今天想要手写汇编打败编译器生成的代码是一件非常困难的事情。


#180

原来这叫「默认 inline 所有函数」啊,学习了


#181

只会写C++, 还好没有被Rust骗, 不然成土包子了


#182

以后那些看起来冗长复杂的数学公式(各种多重微积分)希望也会退化成机器码


#183

老实说,我估计凑不出来 5 种语言能覆盖所有 CL 的特性。condition system 和 clos 很难在其他语言里找到(或许是我太孤陋寡闻了),好像也没有什么语言默认使用 unhyigenic macro 了?(好像 Clojure 还在用?)

可否举点例子?我看看和一些 Scheme 里的功能有什么差别?又有什么是 Racket 的 phase 是做不到的?

你看不上的 Scheme 是有这个特性的哦。而且对于有强大类型系统护航的语言,把数据结构 unbox 了也差不多意思了。

这个我觉得需要一些数据支持。Lisp 家族写出来的代码,不能说长,但也到不了「比绝大多数」短的水平。

这等于废话,因为任何一个合格的程序员使用一个合格设计的语言都能手动搬运一个库,而 ffi 也应该是准备给他人一定强度使用的语言都必备的功能——那么生态到底是什么呢?是指我能调用其他语言的东西吗?

讲 runtime 的动态性和语言本身和 runtime 的交互能力,不把 Smalltalk 搬出来就不合适了吧

:wink:

如果是把「GHC 会对所有函数考虑 inline 的可行性,解读成『默认 inline 所有函数』」,那么我无法理解这一句了。难道是说一般的编译器拿个 random() 去判断要不要考虑这个函数能不能 inline 吗?不然「更」这个字我无法理解啊。

最后送一个小提示,是 linear logic 不是 liner,别再 typo 啦。


#184

现在觉得CLOS 最大的缺陷,是我们在主流的 OOP语言里习惯了把对象做主语,放在前面,而CLOS都是祈使句

所以要一点点适应的时间(我初学者,想要用来做我准备做的管理系统,可能不那么复杂,发挥不出CL的亮点啊~😹)

还有那:after :before :around 看起来好像也挺有用的,但是看使用的例子好像并不多(虽然PCL学者也说使用率可能只有1%但作用也是很大的)

以前用的开发利用iOS的OC 基本都是把 [super method];放在第一行,而 (call-next-method) 都是放在最后一行,它们的思路是不是很不一样的?


#185

你看,我就说没有dot operator能劝退一批从Java C来的quiche eaters :joy: @yfzhe

不说rust了,python的方法不同样要显式写出来self?本来就是个语言抉择的问题到你这里成最大缺陷了。

另外Generic可以和CLOS分开,甚至换用其他语言的interface,trait都可以,本来就是个用来实现Adhoc polymorphism的东西,你看generic甚至可以对CL的struct dispatch。

爱放哪放哪,我是首先super的。call-next-method不止super一个用法,我猜你可能搞混了。


#186

号称小 CLOS 的 Dylan 了解一下。c preprocessor 被你开除了?这年头连 Haskell 都还在用 cpp,还专门做了给 Haskell 适配的版本。

(defun stub () nil)
(funcall (intern (read))) ;; key in "STUB" here

请不用 Scheme 的 eval 做。(ps. 给我留下 Scheme is inferior 印象的问题 1)

Chez Scheme Version 9.5.2
Copyright 1984-2019 Cisco Systems, Inc.

> (list (values 1 2 3))
Exception: returned three values to single value return context
Type (debug) to enter the debugger.
Clozure Common Lisp Version 1.12-dev  DarwinX8664

For more information about CCL, please see http://ccl.clozure.com.

CCL is free software.  It is distributed under the terms of the Apache
Licence, Version 2.0.
? (list (values 1 2 3))
(1)

(ps. 给我留下 Scheme is inferior 印象的问题 2)

你这就是云用户发言。

PaulGraham has claimed that LISP results in significantly less code, and this results in faster development, fewer bugs, and less maintenance effort.

至于大忽悠的背书靠不靠谱我好说。

反正那几个能在 Mac 上用的 Smalltalk 实现我沒有用得舒服的,连个 native feeling GUI 都无,太穷酸了,Clozure CL IDE 水平都沒有。

pragma 是啥你不知道么?

DEK 都会在著作里犯 type,我向他学习不行么,沒有支票,不過可以领我的一句 “quiche eater”。你还可以指责我繁简字混用,不识中华文化,于是可领老夫一句「给爺爪巴」

没 沒

看见沒?


#187

笑死 :rofl:


#188

哦还有这种 macro system 的啊,我马上学习!

http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-8.html#node_sec_5.8 看一下 R6RS 标准吧,看看谁是云用户?这里本来应该丢 r5rs 的链接的,但是没有直达 values 的链接,所以就拿 r6rs 代替一下。连 r5rs 都没读过的,不配批评别人云用户吧。

Scheme 里的 values 本来就是要接受它的 continuation 接受到值数量和它本身返回的值的数量要对上。又不是说可以取其中几个值。

看上文你纠结 multiple return values,就是在会不会 boxing 这个点啊;Scheme 这个完全符合,怎么了?

我理解的 Scheme 讲究准确,几个槽位就对应几个值。在这个 type-safe 被举到非常高位置的时代,不知道几个值都可以拿的是不是不讲究呢?

确实,写出来的很丑,还得绕一下。但是在现在都开始讲究 staging programming 的时候,run-time 和 compile-time 直接混杂在一起真的好吗?

(define (so-easy) #t)

(define-syntax (foo stx)
  (datum->syntax stx (list (read))))

(foo)

你猜 GHC 有没有负责 inline 的 pragma?

嗯,meta-typo。只是 liner 这个拼写法看着像没怎么用过这个词的人凭自己感觉就写出来的样子。而且我看上文这个词出现的地方都拼错了,以为你是不知道怎么正确拼写这个词,所以提醒你一下。

  1. 大忽悠在本贴 #2 楼不是被批判了吗,怎么抬出来当论据了?
  2. 这句话后半段我真没看懂

#189

我的例子编译成 fasl 以后和 batch load 行为一致,你这用 Chez 编译了就沒用了,你真的写过有意义的程序吗?程序的用途都给你改变了,还有比较的意义么?

都叫 multiple-return-value 就一样了,能等价了?我强调的就是 CL 的 values 可以不受 context 限制,所以 Scheme 根本就沒这个"和 CL 行为一样的 multiple value " 你为什么要故意混淆?还鼓吹 Scheme is better practice? 恁就是王x?

你猜 GHC 有没有负责 inline 的 pragma?

有,但是 GHC 会无視。这就和 ANSI CL 认可实现可以完全不处理 pragma 一样。


#190

原来如此,那 Racket 应该做不到(Scheme 不熟,不能把人拖下水)

话说回来,都 run-time 和 compile-time 混合了,我用 eval 也没问题吧。说实话,我没理解这种行为和 eval 的差别在哪

没写过。

别别别,我们在说语言特性呢,先别跑去批评人家平台的使用体验啊。

嗯嗯,大 PL 家去叫辣鸡的 Scheme 委员会把他们的认识错误改了?

没看出来

那我可以举无数个某某语言的特性,要求你拿出来一摸一样的出来。

求参考资料,正好之前还没学过 Haskell,这次学习一下。


#191

那回到这里,请用 CL 做一个 Scheme 版本的 multiple return values


#192

CLOS最大也是最有意思的特点是multi method,这个在主流语言里真的找不到,但是又很有用,所以不得不整出些Visitor模式之类的,但是方便程度差太远了