是否有纯函数式的方案或 Lisp？
我尝试过几种函数式编程语言，并且非常喜欢 Lisps 使用的 s-expr 语法（特别是 Schema）。
我还看到了使用纯函数式语言工作的优势。因此：
是否存在纯函数式方案（或一般的 Lisp）？
I've played around with a few functional programming languages and really enjoy the s-expr syntax used by Lisps (Scheme in particular).
I also see the advantages of working in a purely functional language. Therefore:
Are there any purely functional Schemes (or Lisps in general)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
新的 Racket 语言（以前称为 PLT 方案）允许您使用 s 表达式（实际上是任何语法）实现您喜欢的任何语义）。基础语言是一种急切评估的动态类型方案变体，但构建在其之上的一些著名语言是惰性方案和称为“Father Time”的功能反应系统。
在 Racket 中创建纯函数式语言的一个简单方法是采用基本语言并且不提供任何改变状态的过程。例如：
组成一种没有
set!的语言。The new Racket language (formerly PLT Scheme) allows you to implement any semantics you like with s-expressions (really any syntax). The base language is an eagerly evaluated, dynamically typed scheme variant but some notable languages built on top are a lazy scheme and a functional reactive system called Father Time.
An easy way to make a purely functional language in Racket is to take the base language and not provide any procedures that mutate state. For example:
makes up a language that has no
set!.我不相信有任何纯粹的函数式 Lisp，但 Clojure 可能是最接近的。
Rich Hickey，Clojure 的创建者：
http://clojure.org/rationale
Clojure 是函数式的，具有不可变的数据类型和变量，但您可以获取可变的数据类型某些特殊情况下的行为或下降到 Java（Clojure 在 JVM 上运行）。
这是设计使然 - Rich 的另一句话是
请参阅针对 Lisp 程序员的 Clojure 演示。
I don't believe there are any purely functional Lisps, but Clojure is probably the closest.
Rich Hickey, the creator of Clojure:
http://clojure.org/rationale
Clojure is functional, with immutable data types and variables, but you can get mutable behavior in some special cases or by dropping down to Java (Clojure runs on the JVM).
This is by design - another quote by Rich is
See the presentation of Clojure for Lisp programmers.
ACL2 定理证明器是一个纯粹的 Lisp。然而，它是用于定理证明而不是编程，特别是它仅限于一阶程序。然而，它在其利基市场上取得了极大的成功。
除此之外，它还荣获了 2005 年 ACM 软件系统奖。
The ACL2 theorem prover is a pure Lisp. It is, however, intended for theorem proving rather than programming, and in particular it is limited to first-order programs. It has, however, been extremely successful in its niche.
Among other things, it won the 2005 ACM Software System Award.
可能不是，至少不是玩具/概念证明之外的任何东西。请注意，即使 Haskell 也不是 100% 纯粹的功能 - 它有秘密逃生舱口，
IO中的任何内容都是 仅在某种折磨人的、挥手的意义上的“纯粹”。那么，也就是说，您真的需要一种纯函数式语言吗？您可以用几乎任何语言编写纯函数式代码，但会带来不同程度的不便和低效。
当然，假设通用状态修改的语言使得保持事物纯净变得很痛苦，所以也许你真正想要的是一种鼓励不变性的语言？在这种情况下，您可能会发现值得了解 Clojure 的哲学。首先，它是一个 Lisp！
最后一点，请务必意识到 Haskell 的大部分“语法”都是厚厚的糖层。底层语言只不过是类型化的 lambda 演算，没有什么可以阻止您以这种方式编写所有代码。不过，其他 Haskell 程序员可能会用奇怪的眼神看你。还有 Liskell 但我不确定现在它处于什么状态。
最后，实用的说明：如果您想实际编写您打算使用的代码，而不仅仅是为了好玩而修补东西，您将真正需要一个知道如何使用纯代码的聪明编译器/不可变的数据结构。
Probably not, at least not as anything other than toys/proofs of concept. Note that even Haskell isn't 100% purely functional--it has secret escape hatches, and anything in
IOis only "pure" in some torturous, hand-waving sense of the word.So, that said, do you really need a purely functional language? You can write purely functional code in almost any language, with varying degrees of inconvenience and inefficiency.
Of course, languages that assume universal state-modification make it painful to keep things pure, so perhaps what you really want is a language that encourages immutability? In that case, you might find it worthwhile to take a look at Clojure's philosophy. And it's a Lisp, to boot!
As a final note, do realize that most of Haskell's "syntax" is thick layers of sugar. The underlying language is not much more than a typed lambda calculus, and nothing stops you from writing all your code that way. You may get funny looks from other Haskell programmers, though. There's also Liskell but I'm not sure what state it's in these days.
On a final, practical note: If you want to actually write code you intend to use, not just tinker with stuff for fun, you'll really want a clever compiler that knows how to work with pure code/immutable data structures.
这里的“不一致”是什么？
仅根据语法来选择语言是很奇怪的。毕竟，学习语法需要几个小时——这只是所需投资的一小部分。
相比之下，速度、打字规则、可移植性、库的广度、文档和社区等重要考虑因素对您是否能够提高工作效率具有更大的影响。
忽略所有的火焰诱饵，快速谷歌一下不可变的方案会产生一些结果：
http://blog .plt-scheme.org/2007/11/getting-rid-of-set-car-and-set-cdr.html
What is "inconsistency" here?
It is odd to base a language choice soley on syntax. After all, learning syntax will take a few hours -- it is a tiny fraction of the investment required.
In comparison, important considerations like speed, typing discipline, portability, breadth of libraries, documentation and community, have far greater impact on whether you can be productive.
Ignoring all the flame bait, a quick google for immutable Scheme yields some results:
http://blog.plt-scheme.org/2007/11/getting-rid-of-set-car-and-set-cdr.html
30 年前有 lispkit lisp
不确定今天的访问情况如何。
[那是我学习函数式编程的地方之一]
30 years ago there was lispkit lisp
Not sure how accesible it is today.
[Thats one of the places where I learnt functional programming]
有 owl lisp，R5RS 方案的方言所有数据结构都是不可变的，还有一些额外的纯数据结构。这不是一个大项目，但似乎是由一小群人积极开发和使用的（从我在网站和 git 存储库上看到的）。还计划包括 R7RS 支持和某种类型推断。因此，虽然可能还没有准备好用于生产使用，但这可能是一件有趣的事情。
there is owl lisp, a dialect of scheme R5RS with all data structures made immutable and some additional pure data structures. It is not a large project, but seems to be actively developed and used by a small group of people (from what I can see on the website & git repository). There are also plans to include R7RS support and some sort of type inference. So while probably not ready for production use, this might be a fun thing to play with.
如果你喜欢 lisp 的语法，那么你实际上可以在 Haskell 中做类似的事情。
let fibs =放在一边。您始终可以在 Haskell 表达式中使用 s-expr 语法。这是因为你总是可以在外面添加括号，这并不重要。这是没有多余括号的相同代码：这里是“典型”Haskell 风格：
If you like lisp's syntax then you can actually do similar things in Haskell
The
let fibs =aside. You can always use s-expr syntax in Haskell expressions. This is because you can always add parentheses on the outside and it won't matter. This is the same code without redundant parentheses:And here it is in "typical" Haskell style:
有几个项目旨在在 lispy 语法下使用 haskell。更老、更死、更笨重的是“Liskell”。更新、更有活力、重量更轻的是 搭扣。我想你可能会发现它值得一看。
There are a couple of projects that aim to use haskell underneath a lispy syntax. The older, deader, and more ponderous one is "Liskell". The newer, more alive, and lighter weight one is hasp. I think you might find it worth a look.