hrs/blueprint

A teeny tiny Scheme implemented in Ruby.

blueprint's Issues

Implement destructuring-bind

It'd be slick if we could perform a destructuring-bind when binding variables. Something like:

(destructuring-bind (a (b c) d) '(1 (2 3) 4)
    (list a b c d)) # => '(1 2 3 4)

I think §18 of On Lisp has some good stuff on destructuring. We could probably implement this as a macro in the standard library.

REPL should be able to handle multiple lines of input

Right now, if we try to enter a multi-line expression on the REPL, it'll throw an error and exit. Instead, we should catch those errors (where appropriate) and let the user keep typing on the next line.

We could also try to determine if an expression is balanced and use that information instead. What do other lisps do?

Add filter and reduce to the standard library

We've already got map (since I wanted it for let), but it'd be nice to complete the trifecta.

Might want to reimplement map in terms of reduce while I'm at it.

Create a Sexpr object and parse into that instead of just Arrays

This'll clean up a lot of nonsense in the code (in particular Repl#format).

Implement macroexpansion as a separate phase?

Pros:

• Pulls functionality out of the evaluator.
• Probably improves evaluator performance.
• Establishes precedent for building other phases (replacing constants, various optimizations).

Cons:

• Introducing a compile-time/runtime distinction, which is arguably harder to reason about (especially as it relates to loading). Probably need to check Flatt 2002.
• Need to implement a load phase, too, since we want to be able to expand macros in other files.
• If we want macros to remain applicable we'll need to pass the Macro objects from the expander to the evaluator, which means the evaluator won't be any simpler.

Add note that Blueprint macros are fexprs

The terms that Blueprint calls macros are expanded at runtime (rather than in a separate macro-expansion phase). It's not exactly wrong to call them macros, but the more precise term would be "fexprs," and we should refer to them as such in the documentation.

On the topic of fexprs, Kent Pitman wrote Special Forms in Lisp in 1980 recommending against their use because they aren't amenable to static analysis. Blueprint performs exactly no static analysis, and doesn't aspire to, so this isn't a big problem for us. It's something to consider for future languages, though!

Fix comments

They're totally broken right now. Our parser tests need to be a lot more extensive.

Implement ' as quote syntax shortcut

Probably pending replacing the parser.

Reimplement the standard library in actual Blueprint

Right now the standard library is basically a collection of raw ASTs, but there's nothing conceptually stopping us from reimplementing it in Blueprint itself. This will require:

• The ability to read and evaluate a file (where the standard library will live).
• A mechanism for defining macros in Blueprint for let, etc (as described in #9)

Implement generalized macro-expansion

This might involve unification of some kind? We'll see!

The empty list () should be falsy

It is in all the other Lisps, so we might as well.

Support strings

Implement tail-call optimization

Norvig has a nice example in Lispy2. SICP also covers it pretty well in §5.

Exit with arbitrary exit status

Syntax should probably be something like:

(exit 0)
(exit 1)

We might also want aliases, like:

(exit 'success)

Support richer numbers

As least negative integers and floats. Rationals would be neat, too!

Rewrite stdlib tests in Blueprint

We've got eval and apply now, so we've got almost all we need. We might need support for exceptions.

Reimplement the lexer and parser in Parslet

Parslet or something similar (Ragel?) would clean up some of the nasty ad-hoc state-machine malarky. It'd also make it easier to add new syntax (quotes, strings, ...) in the future.

REPL output should be formatted in Blueprint, not Ruby

Implement gensym

To avoid accidental variable capture in macros.

Add macro literals

We've got function literals in the form of lambdas, and macros are essentially a first-class object in Blueprint anyway, so maybe we should add a syntax to create anonymous macros?

Support boolean operations and, or, and not

Add user-defined macros

Through a defmacro special form, or something similar. I'd like to match the syntax up with the Scheme-style define I'm already using, so we'll want something like:

(defmacro (if condition consequent alternative)
  `(cond (,condition ,consequent)
         (else ,alternative)))

If we're still using chunkier syntax (macro-quote, macro-escape, macro-splice, or whatever) instead of backquotes and commas, then that's just fine, too.

Add macro-quote, macro-escape, and macro-splice special forms

We need forms that serve the purpose of backquote, comma, and ,@ in Common Lisp.

We'll eventually want to add the fancy syntax for them in the parser (or as reader macros, if I ever figure out how those work...) but in the meantime these'll do. Anything beats manually cobbling together macros with list and quote.

Define variadic functions

Standard Scheme uses a dot notation to define functions that take a varying number of arguments:

(define (my-function (a b . the-rest)
  ...)

We'll need to tell the parser to accept dots and modify lambda and define to handle this.

Make special forms applicable

It's be cool if we could write something like:

(map first '((1 2) (3 4)))

Right now we can't, since first is a special form. We have to do something like this instead:

(map (lambda (x) (first x)) '((1 2) (3 4)))

Which is kinda lame.

Add support for boolean types

Might be helpful when dealing with #14.

Add sequential binding with a let* macro

Just a simple macro for the standard library. Might be nice, though.

Implement display to write to stdout

We'll want to be able to write to other streams, too, but for now let's just focus on stdout.

Support comments

I think I prefer # to end-of-line style syntax, like in shell/Perl/Python/Ruby/etc.

let shouldn't be a special form

let is currently handled in eval, which isn't right. It should be a macro which is expanded as part of a general macro-expansion step between parsing and evaluation.

Refactor to objects

The whole Evaluator class is a big mess! It'd be much better if each kind of node in the AST was its own class with an eval function that took an environment and returned an expression and a possibly-updated environment.

Curried functions?

I'm not sure how hard this would be, or how difficult it would be to integrate with the pattern-matching function arguments discussed in #31. But it'd sure be neat.

Define set! and define as special forms

They're not currently defined, but they're pretty important.

We might also consider defining define as a macro that uses set!. Gonna have to look into it once we've got macro-expansion.

Configure with Travis

It'd be nice to know that tests keep on passin'.

Support a modulo operator

Should be able to load files from the REPL

Something like:

(load "my-library-file.blu")

Users should be able to eval and apply functions

eval and apply are special forms, so they're not currently accessible to the user. It'd be nice if they were.