Chicken Scheme 6.0 | Hacker News Reader

Chicken Scheme 6.0

code.call-cc.org

303 pointseatonphil62 comments

Folks may also be interested that this version, 6.0, supports Crunch(although Crunch itself has not been declared a 1.0 status, currently @ .993), which is a compiler for a statically typed subset of Scheme R7RS. (https://wiki.call-cc.org/eggref/6/crunch)

CRUNCH is really cool, I helped make it work better on Windows (although it requires a bit of setup)

For an introduction:

CHICKEN is a compiler that translates Scheme source files into C, which in turn can be fed to a C compiler to generate a standalone executable. An interpreter is also available and can be used as a scripting environment or for testing programs before compilation.

does this mean that you can't do `eval`-like things in "production" systems?

IIRC not compiled (you can include the interpreter).

But then Scheme was always less EVAL-friendly of the lisps

I'm not seeing the less friendly... Eval, and sandboxing eval, are builtin features of the Scheme standard.

It has eval but it lacks reader macros (or at least it did thirty years ago) which is what makes eval useful on lisp2 systems.

I'm interested in reading more about how reader macros make `eval` better/useful.

R5RS supports reader macros? Which would be 1998, and I guess only 28 years ago.

That's why SRFI-49 and its descendants were a possibility. Wisp, JavaScript, brainfuck, etc. implementations all exist because the tools exist in the language.

It does not. https://conservatory.scheme.org/schemers/Documents/Standards... Particular implementations could.

That document, shows several forms:

https://conservatory.scheme.org/schemers/Documents/Standards...

Common Lisp reader macros hook into the reader itself as it's parsing S-exps and meets some character combination: http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec... Define-syntax is for making special forms (i.e. normal macros).

Not that I know why eval should be paired with reader macros.

The less-eval-friendly thing is R5RS only requires two possible "environment specifiers" (2nd arg to eval), returned by SCHEME-REPORT-ENVIRONMENT and NULL-ENVIRONMENT, with no special form or procedure to get the current lexical environment; and R4RS (I just checked) does not specify eval. There's pretty much no manipulation of environments in the standard; the best is something like

  ((eval `(lambda (foo) ,exp) (scheme-report-environment 5))
   foo)

(can't really think of applications for getting the current environment right now except for pseudo-macro stuff)

Scheme is hygeneic, yes. Which is why sandboxing works.

If you want to manipulate the current environment, and defeat half the point of the language, then you're allowed that through (user-initial-environment).

(define-syntax) will also let you rewrite the bindings however you require.

Edit: Here's an eval macro I use fairly often:

  (define-syntax constexpr
  (syntax-rules ()
    ((_ expr)
     (begin
       (syntax->datum
        (datum->syntax
         (quote-syntax here)
         (eval 'expr (interaction-environment))))))))
         
  (define (factorial n)
  (if (<= n 1)
      1
      (* n (factorial (- n 1)))))
         
  (define n
    (constexpr (factorial 10)))

By the current lexical environment I meant the lexical environment at some place in the code (not just the top-level one, which user-initial-environment gives, though it's optional). I'm not attempting to make a case for anything; but without that RnRS' eval doesn't grant more expressivity than just tacking on an interpreter to every program, which you could also just do yourself. (It also doesn't complicate the implementation; variable names don't need to be preserved after compiling.) I.e. it makes sense to say standard Scheme has been less "eval-friendly," even if there were good reasons or one doesn't care.

I started playing with Chicken over the weekend because I was looking for a scheme that you could build binaries of and that had a lively ecosystem. I've really enjoyed it. So far I've mostly played with web stuff. Built a wrapper around makemkvcon for ripping some dvds I've been meaning to rip that'll do a little bit of automatic naming of output using the tv db.

I was slightly worried that I'd start using v5 and then v6 would come out but it looked like they'd been working on it for a while so I figured I'd have some time on v5. Turns out I was wrong!

How would it be for a 2D game?

I’ve thought a tiny bit about this. I think I’d lean towards Guile for a game because of Hoot, wasm compiler, and Chickadee, little game library. But I’m remarkably unqualified to have a real opinion since I’ve used Chicken for 72 hours now.

There's raylib and sdl2 eggs available. Those are a great place to start.

I am currently looking into simple options for using Scheme as a scripting language in a game written in C. So far, s7 made a good impression for embedding it, but I am also not that far into evaluating the actual performance. I looked a bit at Chicken, and it seemed possible to embed, but too complicated for my purposes.

I would use Guile for that, its documentation about how to use it as a scripting language within a C program is excellent.

It is being used by many projects for this purpose: GNU Cash, Lilypond, GNU Guix... I don't know about games, however.

I had a look at Guile as well and it is great - but the simplicity of embedding s7 with just one header and C file made me go with it now. But for a more complex case, I would love to try Guile.

I've only made the one game with it. A lot more GUI apps.

sdl is in the package manager, making it fairly easy to hook into, and "standard". From there its about the same as anything else.

Because I was cross-compiling, I compiled to C and had a... Somewhat complicated Makefile for building Linux, Windows, Android binaries all at once.

Debugging Android made me give up, in the end. The platform, not the tools I had, was the pain point.

By the way, what do you use to postprocess your DVDs? My experience is that DVDs had awful quality and got interlaced unless using a good player (like cyberlink powerdvd) which was always improving with the video greatly and deinterlacing it?

I was eagerly waiting for this release, which brings full Unicode support.

Congratulations to the team, Chicken Scheme is a little gem!

For those who use Chicken Scheme: what made you pick it over other Lisps? What are some things it does particularly well?

The compiler. That’s the gem of the system.

The generated C is reasonably portable, so you can run Scheme programs on systems that “don’t run Scheme”.

Absolutely. And eggs too [1]: these are libraries provided by the community, very easy to import and use.

[1] https://wiki.call-cc.org/eggs

What happens if you try to run Python eggs under Chicken? Do you get Roko's Basilisk? :-)

Pythons are too cold to hatch Chicken eggs, and viceversa

Just to run with the joke - one project I worked on was a CPython extension. We used Chicken to build out our library to do some rather hacky things and bring async/await to Python before it supported it.

And we did call it basilisk.

The eggs are great. For instance I can be up and running building an SDL2 game or make a webserver quickly.

It has good emacs support with geiser-chicken.

Because it compiles down to C the FFI provides a lot of nice ergonomics beyond what I get with Chez Scheme.

Error messages are actually useful with a stacktrace. Can't overstate this.

It supports optional type definitions which reduces the number of tests I need.

The docs are adequate, though I frequently add "MIT scheme" to my search queries. I wasn't able to get chicken-doc setup in NixOS, and the docs website has gone down on me a bunch lately. I wish Chicken had complete documentation available including its eggs in an offline format, like a PDF.

What about Gambit? Perhaps it's a better, optimizing compiler but the built-in library is rather minimalist?

     It has good emacs support with geiser-chicken.

I wrote the initial support for chicken some 11 years ago; it wasn't _great_, but I see that Jao and others have worked on it some since then. Glad to see it's working well!

Self-contained, compact, compiled, fast, ready to use.

SBCL is not compact and its "image" concept is not universally liked by everyone.

Guile and Racket are not fast (nor compact).

Chez Scheme is not "ready to use".

In many benchmarks, Racket is significantly faster than many other Scheme implementations, including Chicken: https://ecraven.github.io/r7rs-benchmarks/ This is because it is now based on Chez.

It is certainly not compact, though.

Would be interesting to see how Crunch [0][1] does on that benchmark. Any plans to add it to the benchmark?

[0] https://news.ycombinator.com/item?id=49252127

[1] https://wiki.call-cc.org/eggref/6/crunch

Racket may be significant faster than many, esp since transitioning to Chez, but its still very hard/problematic to compile to a binary, and if wrapped into a binary still very bloated in size.

FWIW: I enjoy working with Gambit, especially since it can compile to C and standalone binaries and also scores even higher than Racket.

Well, SBCL can just use sources just fine. On Guile not being fast enough, it got a JIT since version 3 and it can be pretty fast. It must be, you know, because if not Guix would be even slower.

To me it is the combination of what is listed in https://www.call-cc.org/.

Happy to see CHICKEN 6.0 out. Moving to full R7RS and UTF-8 strings was long overdue. The change from blobs to bytevectors and the process-object API look particularly clean. Anyone who has already started porting code — any major gotchas so far?

Why do people use chicken over gambit? Is it due to chicken’s larger ego system and eggs, or is there more?

Native UTF-8 strings are the part I care about most here. The old blob-versus-string juggling was the first thing that bit me porting code.

   - Strings and symbols passed to foreign code are not copied, they are
    passed directly, any mutations done by external code will be visible on the
    Scheme side.
  - Complex numbers, C structs and unions can now be passed directly as
    arguments and returned as results when interfacing to C code.

Those were major bottlenecks for any FFI-heavy Chicken Scheme app, and would often result in brittle and unsafe abstractions to work around. Glad to see this changed.

I only used Chicken for a short time, because of a UTF-8 bug it had/has, but I always liked Chicken's docs. They seem to be written with care and often make things understandable. When I look up Scheme things and don't understand something, sometimes I specifically go for the Chicken Scheme docs, to see if I understand its explanation.

ngl this is a massive update full R7Rs support UTF-8 strings and they finally ditched blobs for bytevectors the closure reuse otpimization sounds interesting too ngl

Uhm. I'm divided. Common Lisp it's the weird cousin, bloated at first but in the end you get SBCL, ECL or CCL and almost everything will work the same. With Scheme, you need to instal SRFI's to complete SICP exercises and then there's R5RS and R7RS.

You have no way to run Hypergiant under Guile. In Common Lisp, tons of packages for QuickLisp/UltraLisp will run on SBCL, CCL and ECL with ease.

In the end Scheme+Dependencies can be more convoluted than a subset of Common Lisp (you can avoid CLOS if you don't need it for instance).

I've never really heard of installing SRFIs (could be my ignorance); do you mean importing them? Or is installing SRFI implementations as their own packages really common? (Haven't really tried R7.)

The anti-R6/R7 folks (or what I've heard) won't see a problem so long as you can use CL to build fancy serious software, which lets Scheme stay small and simple for education. (Of course ideally you'd be able to do any SICP exercise on a Scheme implementation out of the box, though.)

For that I use Chicken 5 with trace, srfi-203 and srfi-216.

Scheme SRFIs make Scheme a much bigger language while also making it painful to use because you have to research which SRFI are implemented in your scheme variant then map those SRFI numbers to what they actually do then you usually need read the raw SRFI because that's the only documentation around.

R7RS is going on 14 years old and there's still no R7RS-large either. They really need to just take the critical SFRIs, give them names and proper documentation, then call them R7RS-large and move the current work to a future R8RS.

Indeed. Scheme it's amazing for embedded (such as s9) and its small size. Also, the SICP it's cool to do with Chicken Scheme and this ~/.csirc (and chicken install srfi-203 and srfi-216):

    (import scheme)
    (import (srfi 203))
    (import (srfi 216))
 
 (define (displaynl x)
  (display x)
  (newline))
 
 (define pi (* 4 (atan 1.0)))

Even if Chicken has Hypergiant to play with 3D objects, Common Lisp has Kandria, Sketch, Kons-9...

From Scheme, after finishing SICP as an Scheme exercise (and CS course), just jump into Common Lisp, and finish both Gentle Introduction to Symbolic Computation and Paradigms of Artificial Intelligence, where you will implement a micro-Scheme in Common Lisp itself as an exercise.

SBCL allows you to create working stuff with very few dependencies (uiop and the like from QuickLisp/Ultralisp). With Scheme/Chicken you will get lost in a maze of eggs and SRFI's.

And, on CS/academics, if you finish SICP both GITC and PAIP on on Common Lisp will be a breeze and it will give you superpowers with these three books.

I guess you mean s7 -- I find s7 scheme fits into a lua shaped hole for scripting larger applications quite well without having to use lua (which is a personal preference). I used s7 scheme for scripting a C program years ago, and moved on to writing programs with chicken scheme.

I really think in an alternate universe chicken scheme could fit into the python niche, because the eggs feel very "batteries included". Super excited for this release!

Are there official solutions/answers to SICP?

Github has several repos, there's one which works for Guile (and Racket for the 2nd lesson), but you can just use Chicken Scheme 5 for all of them.

Here are the commands to build the addons needed for Chicken Scheme 5 and SICP compat. You need gcc, make and similar tools on your Unix machine. Install "build-essential" on Ubuntu, Debian and derivatives will just work.

     chicken-install -s srfi 203
     chicken-install -s srfi 216
     chicken-install -s trace

Then at ~/.csirc

     (define
        (displaynl x)
        (display x)
        (newline))

     (define pi (* 4 (atan 1.0)))

    (import scheme)
    (import (srfi 203))
    (import (srfi 216))

Displaynl and "pi" are just for convenience.

Thanks. I’ll look into that. What about SICP solutions that work with MIT Scheme? That’s the implementation of Scheme used in SICP. Also, what are the differences between the major Scheme implementations?

Sorry, I hit the nested comment limit. On MIT Scheme, it used to recommend some older version, specially the first edition, but on Chicken 5 with the SICP related SRFI's loaded and maybe scm-sicp you can hit an almost 100% compatibility.

On differences, I already said that there's local library overlapping from the own subdialect implementations, such as Chicken Eggs and Guile ice-9 modules, but if you start them with R5RS or RSR7 standard compatibility flags the differences fade away, altough there are rough edges:

https://doc.guix.gnu.org/guile/latest/en/html_node/R6RS-Inco...

It's like ANSI C vs C99 but worse.

So I use Scheme for small scripts with S9 (R4RS standard) plus Unix and NCurses related addons.

For learning SICP, I use Chicken 5 with 203 and 216 eggs plus the ~/.csirc and call it done. Most of the R5RS stuff from SICP will run fine under S9 too with tons of patience (and you can maybe adapt the postscript generating Scheme code from the "Computer Abstraction" books for the frame language and just spit out some PS file). It's just basic geometry with vectors in the end, something SICP will teach you throughly. If you finish SICP with Chicken you for sure will be able to even adapt the threading Scheme code from the chapters for an R4RS compliant Scheme like S9 as it already has some Unix/thereading support. Just generate some wrapping functions and call it done :). It's, for sure a great exercise for Lisp and CS, and far easier to do, for example, than making a ANSI C compiler being C99 compatible. Or, as a modern example, backporting modern Rust/Java functions to older compilers.

On S9 Scheme (s9fes) you could just hack away most of the exercises at blinding speed...

I prefer Common LIsp for bigger tasks (altough you can learn a lot of CS with Gentle Introduction to Symbolic Computation and Paradigms of Artificial Intelligence Programming too), but SICP it's 'harder' and it will put you on God low-level mode making the CL exercises at light speeds despite the design differences between Scheme and CL:

Common Lisp:

  (defun hello () (princ "hello"))
   (hello)

Scheme:

   (define (hello) (display "hello")) 
   (hello)

The reason on picking CL over Scheme: If the code runs under SBCL, CCL and ECL call it done, it will almost run on every Common Lisp compiler/interpreter, even the commercial ones. Quicklisp (and UltraLisp) will handle the dependencies itself and CLHS (Common Lisp Hyper Spec) will have everything doccumented on your hands. The editor? Emacs+Slime or Lem, with both have functions to look up functions and autocomplete, with help about a function or library in the spot. Far better than Scheme in the end for big projects.

Both will teach you iteration vs recursion, anonymous functions (lambdas), closures and so on.

However, with Schemes the SRFI implementations usually (?) come with the standard library, so you don't actually "have to install" them. Still gotta know the usual suspects, like SRFI for tests, SRFI for vectors, hash tables, random numbers, etc. if you want your code to be mostly portable to other Schemes.

That dynamic was exactly why I moved from Scheme to CL many years ago (full disclosure, Clojure is my daily driver, now). I loved the minimalism of the RxRS documents, but they really only covered the small core of the language, and then all the implementations were completely different when it came to libraries. And those differences always needed to be understood in order to write real-world programs. SRFIs helped, but adoption was spotty. Every multi-implementation language has some of that, but Scheme had more than most. For me, the choices were to use a very full-featured Scheme like Racket (which is great) or go to CL and then use something like SBCL. I went with CL and later jumped to Clojure (which, IMO, is a better, more modern Lisp that fits better with today’s multi-core hardware than either Scheme or CL).

Disappointed to learn this is unrelated to the Chicken chicken chicken https://www.youtube.com/watch?v=yL_-1d9OSdk

How can you tell?

Original presentation: https://isotropic.org/papers/chicken.ppt :)

Reply on news.ycombinator.com