little-scheme

I have written almost the identical Scheme interpreters in Ruby and Crystal: [1] and [2]. The biggest difference I have felt between them is the absence of good old Object, which can represent everything at runtime, from Crystal. I had to declare Obj and Val: class Obj end # Value operated by Scheme alias Val = Nil | Obj | Bool | String | Int32 | Float64 | BigInt to define Cons Cell of Scheme: # Cons cell class Cell < Obj include Enumerable(Val) getter car : Val # Head part of the cell property cdr : Val # Tail part of the cell def initialize(@car : Val, @cdr : Val) end ... end # Cell Note that you see generics, Enumerable(Val), and constructor arguments with '@' in the excerpt above. As for performance, Crystal is faster than Ruby 8.6 times as interpreter and 39.4 times as

You are absolutely right. I have written Scheme interpreters in both languages. Compare https://github.com/nukata/little-scheme-in-ruby/blob/v0.3.0/... # Cons cell class Cell include Enumerable attr_reader :car attr_accessor :cdr def initialize(car, cdr) @car = car @cdr = cdr end # Yield car, cadr, caddr and so on, à la for-each in Scheme. def each j = self begin yield j.car j = j.cdr end while Cell === j j.nil? or raise ImproperListException, j end end # Cell and https://github.com/nukata/little-scheme-in-crystal/blob/v0.2... # Cons cell class Cell < Obj include Enumerable(Val) getter car : Val # Head part of the cell property cdr : Val # Tail part of the cell def initialize(@car : Val, @cdr : Val) en

Crystal is comparable to Java in performance. I am impressed with it. See https://github.com/nukata/little-scheme#performance and https://github.com/nukata/little-scheme#performance-on-the-t...

In my experiment, the Crystal version (https://github.com/nukata/little-scheme-in-crystal) was 38x faster than the Ruby version (https://github.com/nukata/little-scheme-in-ruby) and comparable to the Java version (https://github.com/nukata/little-scheme-in-java). Indeed, it is in the fastest group. See https://github.com/nukata/little-scheme#performance

I timed each implementation in solving 6-Queens[1] on a meta-circular Scheme[2] (i.e. each Scheme interpreter ran a meta-circular Scheme interpreter to solve 6-Queens). Results are shown in [3]; the order of speed is observed as follows: Go ≈ Java ≈ Crystal(Compiled) ≈ SBCL > C# ≈ PyPy > TypeScript(Node.js) ≈ Crystal ≈ Dart >> PHP > Python ≈ Ruby [1] https://github.com/nukata/little-scheme/blob/v1.2.0/examples... [2] https://github.com/nukata/little-scheme/blob/v1.2.0/scm.scm [3] https://github.com/nukata/little-scheme/tree/v1.2.0#performa...

This is a small interpreter of a subset of Scheme. It implements the same language as https://github.com/nukata/little-scheme-in-python (and also its meta-circular interpreter, https://github.com/nukata/little-scheme). As a Scheme implementation, it also handles first-class continuations and runs the yin-yang puzzle correctly. $ cat yin-yang-puzzle.scm ;; The yin-yang puzzle ;; cf. https://en.wikipedia.org/wiki/Call-with-current-continuation ((lambda (yin) ((lambda (yang) (yin yang)) ((lambda (cc) (display '*) cc) (call/cc (lambda (c) c))))) ((lambda (cc) (newline) cc) (call/cc (lambda (c) c)))) ;; => \n*\n**\n***\n****\n*****\n******\n... $ little-scheme-in-go yin-yang-puzzle.scm | head * ** *** **** ***** ****** ******* ******** ****