标签: r7rs

截至2016年,是否有一个方案实施支持100%的R7RS(小)没有偏差?

我愿意学习Scheme.我想坚持使用R7RS,因为它是最后一个标准.然而,似乎在Scheme当前实现上存在很多碎片,并且大多数碎片停留在R5RS或R6RS的一部分.

我发现的唯一一个支持R7RS的部分是Kawa,但由于它在JVM上运行,它不支持尾调用优化,这是针对该实现的一个强点.

Scheme计划世界是否真的那么支离破碎,甚至还没有R7RS完全实现呢?我问,因为如果没有,我一赶上,我就打算建一个; 但是,如果存在,最好不要重新发明轮子并为某种实施做出贡献.

如果您有信息,请不仅要回答姓名,还要提供适当的进一步信息(实施的官方网站,甚至邮件组的摘录都可以作为参考).

顺便说一句,我不是在考虑Racket,因为它不再是Scheme了.

lisp scheme implementation r6rs r7rs

22
推荐指数
2
解决办法
6076
查看次数

Chibi Scheme - 简单的定义库示例不起作用

我写了下面的例子,试图在 Chibi Scheme 0.5.3 中试验 R7RS 库:

(define-library (example hello)
    (export hello-world)
    (import (scheme base))
    (begin
      (define (hello-world) "hello, world"))) 

(import (scheme write)
        (example hello))
(write (hello-world))
Run Code Online (Sandbox Code Playgroud)

不幸的是,在执行时,它会生成有关未定义变量的错误:

$ chibi-scheme  hello.scm 
ERROR: undefined variable: hello-world
Run Code Online (Sandbox Code Playgroud)

我一定犯了一个简单的错误,但没有看到它。有任何想法吗?

scheme chibi-scheme r7rs

7
推荐指数
1
解决办法
948
查看次数

Scheme中的宏和内部定义

在Freenode的#scheme频道上提出了一个很好的问题.请考虑以下Scheme中的代码:

(define alpha 1)

(define-syntax foo
  (syntax-rules (quote alpha)
    ((_ alpha msg) (define bar 2))
    ((_ other msg) (syntax-error msg)) ) )

(define (beta)
  (foo alpha "beta")
  (define alpha 3)
  'beta )

(define (gamma)
  (define alpha 4)
  (foo alpha "gamma")
  'gamma )

(define (delta alpha)
  (foo alpha "delta")
  'delta )
Run Code Online (Sandbox Code Playgroud)

的哪些beta,gamma以及delta应产生语法错误?并?我已经用Chibi Scheme检查了这个问题,一切beta都很好gamma而且delta失败了.我想知道这是预期的行为还是仅仅是赤壁的一个错误.

根据标准,似乎扩展宏应该在内部定义被重写之前发生letrec*.所以,beta并且gamma都应该失败,因为foo它将与内部定义匹配alpha,而不是全局定义.

但是,标准中没有明确规定内部定义实际上是如何工作的,只是它们 …

macros scheme r7rs

5
推荐指数
1
解决办法
199
查看次数

球拍/基础命名空间

任何人都知道racket/base语言中包含的内容.我希望将racket/base命名空间定义与R7RS草案进行比较,以便直接了解Racket与Scheme的不同之处.

scheme racket r7rs

5
推荐指数
1
解决办法
496
查看次数

是否可以在Scheme中"扩展"函数/ lambda /宏?

例如:如果我希望函数equal?识别我自己的类型或记录,我可以添加新的行为equal?吗?没有删除或覆盖旧的?

或者,例如,如果我想使函数"+"接受也字符串?

inheritance scheme r6rs r5rs r7rs

5
推荐指数
1
解决办法
419
查看次数

如何(eval ...)在鸡 r7rs 库中?

我正在尝试获得evalr7rs鸡蛋库中工作的基本知识。以下顶级(不是库)程序按我的预期工作,运行时csi -R r7rs

(import (scheme base)
        (scheme eval))

(eval '42 (scheme-report-environment 5))
Run Code Online (Sandbox Code Playgroud)

这也适用于(null-environment 5)(但不适用于(environment '(scheme base) ...)变体)。但是,在库中:

(define-library (test-eval)
  (import
    (scheme base)
    (scheme eval))
  (export
    my-eval)
  (begin
    (define (my-eval)
      (eval '42 (scheme-report-environment 5)))))
Run Code Online (Sandbox Code Playgroud)

我得到

Error: module unresolved: test-eval
....
<syntax>          [my-eval] (scheme-report-environment 5)
<syntax>          (##core#begin)
<syntax>          (##core#undefined)    <--
Run Code Online (Sandbox Code Playgroud)

可能是什么问题呢?Wiki 中的R7RS 环境似乎存在一些问题,但我不确定这是否与此处相关。

用鸡 5.2.0 版(自制程序包)测试,两者csicsc.

scheme chicken-scheme r7rs

5
推荐指数
1
解决办法
171
查看次数

方案 R7RS 中加载和包含之间的差异

在方案 R7RS 中,有 aloadinclude形式。

包含描述为:

语义:include 和 include-ci 都采用一个或多个以字符串文字表示的文件名,应用特定于实现的算法来查找相应的文件,按照指定的顺序读取文件的内容,就像重复应用 read 一样,并有效地重新- 将 include 或 include-ci 表达式与包含从文件中读取的内容的 begin 表达式放在一起。两者之间的区别在于 include-ci 读取每个文件,就像它以 #!fold-case 指令开头一样,而 include 则不然。注意:鼓励实现在包含包含文件的目录中搜索文件,并为用户提供一种指定其他目录进行搜索的方法。

负载描述为:

依赖于实现的操作用于将文件名转换为包含Scheme源代码的现有文件的名称。加载过程从文件中读取表达式和定义,并在环境说明符指定的环境中按顺序计算它们。如果省略环境说明符,则假定为(交互环境)。未指定是否打印表达式的结果。加载过程不会影响当前输入端口和当前输出端口返回的值。它返回一个未指定的值。基本原理:为了可移植性,加载必须对源文件进行操作。它对其他类型文件的操作必然因实现而异。

这两种形式的理由是什么?我认为这是历史性的。这两种形式之间有什么重要的语义差异吗?我发现load可以选择包含环境说明符,但include没有。并且include-ci没有直接等效的使用load. 但比较loadinclude单独比较,有什么区别,重要吗?

lisp scheme r7rs

5
推荐指数
2
解决办法
1088
查看次数

R7RS计划的反思能力

关于编程语言Scheme的R7RS报告描述了在Scheme系统中运行Scheme代码的两种方法:

1)方案系统可以运行报告中第5.1节所述的程序.

2)方案系统可以提供read-eval-print-loop,其中交互式地解释Scheme代码.

我的问题是如何在Scheme系统中反映这两种运行Scheme代码的方式,以及R7RS报告中包含的内容.

有一个eval库过程eval,它在一个正在运行的Scheme系统中执行Scheme代码,所以eval看起来就像我在搜索的内容.

但是,我可以插入的唯一保证可变环境evalinteraction-environmentrepl库过程返回的环境.但是,有了这个,我无法可靠地模拟上面的REPL(第2点),因为REPL允许导入表单,而eval程序不需要.

此外,eval由于其他原因,我无法使用交互环境来完整的Scheme程序:它通常不为空,特别是它包含所有绑定(scheme base).

为了实现1)在运行的Scheme系统中,eval库过程environment看起来很有前途,因为它允许事先导入库(这是运行程序的一部分).但是,环境是不可变的,所以我无法评估define环境中的s.一种方法是将程序体包装在一个lambda表单中,以便define定义局部变量.但是,这也行不通:在一个lambda表单中,所有定义都必须出现在body的开头(对于Scheme程序的顶层不是这样),并且在lambda表单库中,绑定可以被词法覆盖,顶级绑定无法实现.

由于Scheme是Turing-complete,我当然可以在正在运行的Scheme系统中模拟Scheme系统,但我想知道是否可以通过使用该eval过程.我感兴趣的一个原因是eval可能会优化(例如通过JIT编译器后端),因此使用此过程可能会提供接近本机的速度(与手动编写简单的解释器相比).

reflection scheme eval read-eval-print-loop r7rs

3
推荐指数
1
解决办法
579
查看次数

计划r7rs-大有趣,但......它还在进行中吗?

我试图看一下r7rs的状态,但我在计划报告页面等中找不到任何信息,只是2013年的一次演讲.我搜索谷歌也没有成功.

  • 还活着吗?
  • 我在哪里可以找到信息?
  • 暂定日期是什么?
  • 目前进展如何?

谢谢.

scheme guile report r7rs

3
推荐指数
1
解决办法
1408
查看次数

什么时候可以覆盖(R7RS)方案中的顶级绑定?

我已经阅读了即将发布的R7RS方案标准(小语言)的当前草案,但我不明白在什么条件下重新定义顶级绑定不是错误。

我想可以定义设置!第二次在程序顶层引入的绑定。但是从外部库导入的绑定又如何呢?是否可以通过标准覆盖这些绑定?

报告第 26/27 页写道:

程序的顶层还可能包括导入声明。在库声明中,使用不同的绑定多次导入相同的标识符,或者使用 Define、define-syntax 或 set! 重新定义或改变导入的绑定都是错误的。然而,REPL 应该允许这些操作。

这是否意味着重新定义仅在导入绑定的库中发生时才是错误?

据我所知,如果编译器不知道“ +”是否仍然意味着内置加法或任何其他用户指定的错误,它会禁止编译器进行优化。但从这个角度来看,在库级别限制禁止重新绑定是没有意义的,因为它对于程序中的导入绑定也有意义(至少)。

PS:因为这都是关于一个计划程序的环境:我说环境不是一等公民,因为你无法掌握当前的环境,我这样说对吗?(这反过来又允许编译的程序忘记所选择的绑定名称。)

scheme r7rs

2
推荐指数
1
解决办法
455
查看次数