这又不算语言特性，算实现优化。如果有CL实现用了个巨垃圾的allocator，一样吃瘪。CL标准总没规定vector必须alloc on write吧
但是 Emacs Lisp 只有一两个不咋样的实现(算上 guile 吧)，CL 有好几个质量高的实现，这就是区別，你咋不说 C++ 可以实现的比 emacs lisp 槽的，所以 emacs lisp 性能比 C++ 好吧
真的？你确定不是pretty print这个vector拖了后腿？
(let ((a (make-vector 6000000 0)))
nil)
同样秒return
然后我试了下map一次这个vector，速度当然比不上CL，不过远远没有说卡很久的地步。
所以一不小心把这 vector 打出來了，Emacs 完全卡死了咋办？
这么trivial的东西也要纠结啊，佛了。 
那请您用 el 写一个。
我等你用CL写完然后port，还可以帮你喊一句666
当然别用类似这种为了用而用的玩意搞我就好啦
确实有一点重复了，day 2/5/7/9 都是在不断整那个 intcode，看 reddit 上也有人说无聊撤了。
不过后面都是那 intcode 跑 input 了，还是不一样的
看答案也没意思，主要还是想要有个讨论的地方（day13 part 2 被卡了，也没搞清楚问题在哪🙂）
为什么？即使是 “polynomial”，怎么从给定的 input 得到这个多项式关系？
我用 Haskell 写的 Simulator，得用 immutable array 和 IO array 两种版本应对不同题目，头都大了。
多试几个 x y 输入组合把结果 plot 出來就很直观的可以猜出这个结论。
day13 是个 pong! 类游戏，只要让 paddle 和球的 y pos 相同就行。
另外，我发现ielm里make-vector是直接把vector的每个elem都打印出来（和终端下SBCL打印的方式一样），如果是在scratch里用C-j的Pretty print，会把结果打印成
[0 0 0 0 0 0 0 0 0 0 0 0 ...]
和sly里用SBCL打印方式一样，Emacs是完全妹有任何问题滴。所以这问题本质回到了超长行卡编辑器的问题。当然你可以说CL不和任意编辑器关联所以没有这个问题，如果这样说我认了。
讲道理我用Emacs借助sqlite3读火狐的几十万条历史记录都没卡死，怎么你建立个这么“小”的vector就能卡死？
我围观了 Racket 社区的解答，有几个人的做法给我印象很深，他们是拿一个 thread 模拟一个 intcode machine。正好 io 就用 thread 的消息传递来弄。
最初的 intcode 标准里就存在修改内容单元的指令，理论上是存在不同的 (x, y) 导致修改的内存地址/内容不一样的。我觉得应该不存在所谓的多项式关系。
另外，任意有限多的 (x,y) => output 都可以总结出一个多项式公式吧。
最近事有点多，没紧跟 aoc 了，后面再补
我用 closure 來表示 intcode machine，用 function apply/callback 做 io。这样全都是单线程的了。
AoC 的模式是每个人的 input data 都是不一样的，也就是说这个 intcode 程序是自动生成的，为了保证生成程序的合法性(不会数组越界)，最合理的生成办法就是修改的内存地址是不会变的，只不过不影响内存地址的数据会变。
我现在的做法是用一个 struct 打包内存和寄存器，但是它那种线程式的做法就是 io 操作很符合正常使用的思路。不需要人工去管理状态
你说的也有道理吧，但是对于能直接找出一个多项式我还是不信任的；而且这题 100 * 100 暴力遍历一下就好了，没必要去找什么「规律」
这个的确没有。
Functional set我第一反应是tree based map/set（比如Rust的BTreeMap，BTreeSet），或许可以用struct和vector撸一个BTree类似物做一下。
又看了下Emacs有一个AVL树实现，不知道有没有用