The Future of Lispy

Lispy is a Scheme/Python-like language written in C.  Lispy was the first interpreter I wrote in a low-level language and my first program ever written in C.  With this in mind, I consider Lispy to be a very successful project.  I learned a lot along the way, but mostly I learned that writing a language is a lot of work.

My general idea for Lispy was to have a system that behaved like Scheme, but looked and felt more like Python.  Most of the core functions in Lispy are generic and comprehensions play a large role in looping, though tail-recursion is still available in the general case.

However I’ve always wanted more from Lispy.  I really like the sequence abstractions and immutable data structures of Clojure.  I want to play around with lazy, concurrent and parallel evaluation.  However the idea of implementing all that in C is daunting to me.*

The solution is obvious.  Since Lispy is to be a Scheme-like language, and Scheme is a language that is designed for writing programming languages, the next version of Lispy will be written in Chicken Scheme.  It was a natural choice, and would have been my first, had I not done the original implementation for academic purposes.

The switch to Chicken should make it easier to scratch another itch of mine, compiling.  I can envision a number of paths to the compilation of Lispy, from macro compiling to Chicken all the way down to generating assembly.  I haven’t started laying out a plan for compilation yet, but my bet would be that Lispy will become a thin language layer on top of Chicken.

This new version will focus on extending the sequence/constructor concept to support lazy sequences, hash-tables and generic operations for all sequences.

There are three excerpts that I think succinctly describe the motivations behind Lispy.

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

R4RS

Most data structures exist because of speed. For example, many languages today have both strings and lists. Semantically, strings are more or less a subset of lists in which the elements are characters. So why do you need a separate data type? You don’t, really. Strings only exist for efficiency. But it’s lame to clutter up the semantics of the language with hacks to make programs run faster. Having strings in a language seems to be a case of premature optimization.

Paul Graham “The Hundred-Year Language”

Thus, programs must be written for people to read, and only incidentally for machines to execute.

SICP

Lispy’s main goal is to make a language that is “shockingly inefficient” but also a joy to program in.  Lispy is at least a 10 year language.  Lispy is designed to be simple at the expense of efficiency.  Lispy is research, mainly research into the type of programming language that I want to use (as I haven’t quite figured that out yet).

Note that this post is to help encourage me to start developing this version.  I haven’t written any code yet.

* It may be that I’m just inexperienced with the language, but I prefer coding in Scheme.

Advertisements