Scheme和Common Lisp之间的实际区别是什么? (或Lisp的其他两种方言) [英] What are the actual differences between Scheme and Common Lisp? (Or any other two dialects of Lisp)

查看:124
本文介绍了Scheme和Common Lisp之间的实际区别是什么? (或Lisp的其他两种方言)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

注意:我并不是问要学习哪个,哪个更好,或者类似的东西.

我选择了SICP的免费版本,因为我觉得读起来会很高兴(我听说过很多不错的东西,并且我对编程的这种方面很感兴趣).

我知道Scheme是Lisp的方言,我想知道:Scheme与Common Lisp之间的实际区别是什么?

"CL具有更大的stdlib ...方案在现实世界中的编程中并不好.."似乎有很多事情,但没有实际的说法这是因为CL是这个/拥有这个".

解决方案

这是一个棘手的问题,因为差异既是技术上的,(更重要的是,我认为)是文化上的.答案只能提供不精确,主观的观点.这就是我要在这里提供的.有关一些原始技术细节,请参见方案Wiki .

方案是一种基于以下原则的语言:提供优雅,一致,经过深思熟虑的基础语言基础,可以在实践和学术应用程序语言的基础上构建.

您很少会发现有人用纯R5RS(或R6RS)Scheme编写应用程序,并且由于极简的标准,大多数代码无法在Scheme实现中移植.这意味着,如果您要编写某种最终用户应用程序,则必须仔细选择Scheme实施,因为这种选择将在很大程度上决定您可以使用哪些库.另一方面,设计实际应用程序语言的相对自由度意味着Scheme实现经常提供其他地方所闻所未闻的功能.例如,PLT Racket使您能够使用静态类型并提供非常了解语言的IDE.

通过社区驱动的SRFI流程提供了超越基本语言的互操作性,但是任何给定SRFI的可用性都因实现而异.

大多数Scheme的方言和库都专注于函数式编程习惯用法,例如递归而不是迭代.要进行OOP时,可以将各种对象系统作为库加载,但是与现有代码的集成在很大程度上取决于Scheme方言及其周围的文化(例如,Chicken Scheme比Racket更像面向对象). /p>

交互式编程是Scheme子社区与众不同的另一点.MIT Scheme以强大的交互式支持而闻名,而PLT Racket则感觉更加静态.无论如何,交互式编程似乎并不是大多数Scheme子社区的中心关注点,而且我还没有看到与大多数Common Lisps一样类似的交互式编程环境.

Common Lisp 是专为实际编程而设计的语言.它充满了丑陋的疣和兼容性漏洞-与Scheme优雅的极简主义相反.但是当它本身使用时,它的功能也更加丰富.

Common Lisp孕育了一个相对较大的便携式库生态系统.通常,即使在部署应用程序之后,您通常也可以随时切换实现,而不会遇到太多麻烦.总体而言,Common Lisp比Scheme更统一,而且如果进行了更彻底的语言实验,则通常将其嵌入为可移植库,而不是定义全新的语言方言.因此,语言扩展往往更保守,但也更易于组合(通常是可选的).

像外来功能接口之类的通用语言扩展不是通过正式方式开发的,而是依赖于所有主要Common Lisp实现上可用的准标准库.

语言习语是功能,命令式和面向对象方法的狂野混合,一般而言,Common Lisp感觉更像是命令式语言,而不是功能性语言.它也具有极强的动态性,可以说比任何一种流行的动态脚本语言都更具动态性(例如,类重新定义适用于现有实例,并且条件处理系统内置了交互性),而交互式探索性编程是其中的重要组成部分. 常见的Lisp方式."这也反映在Common Lisp可用的编程环境中,几乎所有环境都提供了与正在运行的Lisp编译器的某种直接交互.

Common Lisp具有内置对象系统(CLOS),条件处理系统,其功能比单纯的异常处理,运行时可修补性以及各种内置数据结构和实用程序(包括臭名昭著的 LOOP 宏,对于Scheme来说,迭代子语言太难看了,但太有用了,以至于提及,以及在格式字符串中具有 GOTO支持的类似printf的格式化机制.

由于基于图像的交互式开发,以及由于语言较大,因此Lisp实现在整个操作系统上的可移植性通常不如Scheme实现.例如,让Common Lisp在嵌入式设备上运行并不意味着胆怯.与Java虚拟机类似,在虚拟内存受到限制的计算机(例如基于OpenVZ的虚拟服务器)上,您也经常会遇到问题.另一方面,方案的实现往往更紧凑和可移植.尽管ECL实施的本质仍然是正确的,但ECL实施质量的提高已在一定程度上缓解了这一点.

如果您需要商业支持,则有几家公司提供自己的Common Lisp实现,包括图形GUI构建器,专用数据库系统等.

总结,Scheme是一种设计更为精美的语言.它主要是一种具有某些动态功能的功能语言.它的实现代表具有独特功能的各种不兼容方言. Common Lisp是一种成熟的,高度动态的,多范式的语言,具有各种丑陋但实用的功能,其实现方式在很大程度上相互兼容.与Common Lisp相比,方案的方言往往更静态,交互性更小.常见的Lisp实现往往更重,安装更麻烦.

您选择哪种语言,祝您玩得开心! :)

Note: I am not asking which to learn, which is better, or anything like that.

I picked up the free version of SICP because I felt it would be nice to read (I've heard good stuff about it, and I'm interested in that sort of side of programming).

I know Scheme is a dialect of Lisp and I wondered: what is the actual difference is between Scheme and, say, Common Lisp?

There seems to be a lot about 'CL has a larger stdlib...Scheme is not good for real-world programming..' but no actual thing saying 'this is because CL is this/has this'.

解决方案

This is a bit of a tricky question, since the differences are both technical and (more importantly, in my opinion) cultural. An answer can only ever provide an imprecise, subjective view. This is what I'm going to provide here. For some raw technical details, see the Scheme Wiki.

Scheme is a language built on the principle of providing an elegant, consistent, well thought-through base language substrate which both practical and academic application languages can be built upon.

Rarely will you find someone writing an application in pure R5RS (or R6RS) Scheme, and because of the minimalistic standard, most code is not portable across Scheme implementations. This means that you will have to choose your Scheme implementation carefully, should you want to write some kind of end-user application, because the choice will largely determine what libraries are available to you. On the other hand, the relative freedom in designing the actual application language means that Scheme implementations often provide features unheard of elsewhere; PLT Racket, for example, enables you to make use of static typing and provides a very language-aware IDE.

Interoperability beyond the base language is provided through the community-driven SRFI process, but availability of any given SRFI varies by implementation.

Most Scheme dialects and libraries focus on functional programming idioms like recursion instead of iteration. There are various object systems you can load as libraries when you want to do OOP, but integration with existing code heavily depends on the Scheme dialect and its surrounding culture (Chicken Scheme seems to be more object-oriented than Racket, for instance).

Interactive programming is another point that Scheme subcommunities differ in. MIT Scheme is known for strong interactivitiy support, while PLT Racket feels much more static. In any case, interactive programming does not seem to be a central concern to most Scheme subcommunities, and I have yet to see a programming environment similarly interactive as most Common Lisps'.

Common Lisp is a battle-worn language designed for practical programming. It is full of ugly warts and compatibility hacks -- quite the opposite of Scheme's elegant minimalism. But it is also much more featureful when taken for itself.

Common Lisp has bred a relatively large ecosystem of portable libraries. You can usually switch implementations at any time, even after application deployment, without too much trouble. Overall, Common Lisp is much more uniform than Scheme, and more radical language experiments, if done at all, are usually embedded as a portable library rather than defining a whole new language dialect. Because of this, language extensions tend to be more conservative, but also more combinable (and often optional).

Universally useful language extensions like foreign-function interfaces are not developed through formal means but rely on quasi-standard libraries available on all major Common Lisp implementations.

The language idioms are a wild mixture of functional, imperative, and object-oriented approaches, and in general, Common Lisp feels more like an imperative language than a functional one. It is also extremely dynamic, arguably more so than any of the popular dynamic scripting languages (class redefinition applies to existing instances, for example, and the condition handling system has interactivity built right in), and interactive, exploratory programming is an important part of "the Common Lisp way." This is also reflected in the programming environments available for Common Lisp, practically all of which offer some sort of direct interaction with the running Lisp compiler.

Common Lisp features a built-in object system (CLOS), a condition handling system significantly more powerful than mere exception handling, run-time patchability, and various kinds of built-in data structures and utilites (including the notorious LOOP macro, an iteration sublanguage much too ugly for Scheme but much too useful not to mention, as well as a printf-like formatting mechanism with GOTO support in format strings).

Both because of the image-based, interactive development, and because of the larger language, Lisp implementations are usually less portable across operating systems than Scheme implementations are. Getting a Common Lisp to run on an embedded device is not for the faint of heart, for example. Similarly to the Java Virtual Machine, you also tend to encounter problems on machines where virtual memory is restricted (like OpenVZ-based virtual servers). Scheme implementations, on the other hand, tend to be more compact and portable. The increasing quality of the ECL implementation has mitigated this point somewhat, though its essence is still true.

If you care for commercial support, there are a couple of companies that provide their own Common Lisp implementations including graphical GUI builders, specialized database systems, et cetera.

Summing up, Scheme is a more elegantly designed language. It is primarily a functional language with some dynamic features. Its implementations represent various incompatible dialects with distinctive features. Common Lisp is a fully-fledged, highly dynamic, multi-paradigm language with various ugly but pragmatic features, whose implementations are largely compatible with one another. Scheme dialects tend to be more static and less interactive than Common Lisp; Common Lisp implementations tend to be heavier and trickier to install.

Whichever language you choose, I wish you a lot of fun! :)

这篇关于Scheme和Common Lisp之间的实际区别是什么? (或Lisp的其他两种方言)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆