[EXPERIMENT] A toy APL/Lisp hybrid built in C/C++
C C++ Common Lisp Python
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
c
noweb
test
.gitignore
Makefile
README.md
SKETCH
__10-04-APLisp
color.cc
color.h
compile.cc
compile.h
gen.cc
gen.h
reader.cc
reader.h
runtime.cc
runtime.h
sym.h
value.cc
value.h

README.md

APLisp - "Array Programming Lisp"

APLisp is a hybrid Lisp-APL hobby compiler that I started writing in August 2010 after becoming interested in the APL language, vector/tensor math, OpenCL/CUDA multicore GPU coding, and similar stuff. I started coding APLisp in C++ initially, realized it was overkill, and ported to plain C a few months later (using the little "UThash" macro package in place of STL maps/vectors/arrays).

This code is far from complete, but I thought I'd share it to show some of my ideas for designing simpler computing systems as a whole. For most purposes, I think VMs and optimizing compilers alike are relics of a pipe dream of enabling the average scientist or manager to write high-perf code, back in the day when computers were wicked slow. The idea here (not by any means original) is to generate unoptimized machine code in most cases, only optimizing expensive array operations. Then you insert hand-tuned assembly if needed, without any clever surprises from the compiler. You could also write code to generate dynamically-tuned assembly on the fly -- something you can't do with a typical batch-mode assembler. That's my vision for APLisp or some other future compiler.

Questions and suggestions are welcome.

Status

Definitely a work in progress. I'm still working on goal #1 (see below). Math operations are naive and integer-only for now; I'll have to address that when I move on to goal #2. Some type inference and annotation functionality already exists, but the type system is still in flux. There's no GC at all.

As of May 2011, APLisp runs under Linux on x86-64 and (almost) 80x86. I've tested it under Ubuntu 10.10 and Slackware 13.37. It builds with GCC, TCC, and probably Clang. YMMV on OSX and other Unix-like OSes. Windows support is do-able but it's a low priority.

Goals

  1. Implement an incremental compiler that's simple and easy to modify, unoptimized, embeddable in C (like Lua), with minimal dependencies. The syntax and semantics are like Lisp (particularly the Clojure dialect) but compatibility is not a goal (at this stage, anyway).

  2. APL-like type system with APL-style on-the-fly static compilation of array operations such as (FOLD + '(1 2 3 4 5)).

  3. APL-like syntax within Lisp code (wrapped in square brackets, perhaps). Since APL traditionally lacks structured control flow constructs, I'll use Lisp's.

  4. Experiment with various usage scenarios -- SIMD vector algorithms, DSP, music, GPU coding, kernel/driver implementation, etc.

  5. If it still sounds useful, experiment with user-definable graphical symbols. (Seemed like a neat idea, but Unicode symbols are probably adequate.)

Build instructions

Edit the Makefile, then run 'make'. Repeat until it works :)

The only dependency is GNU Readline, which you can disable by commenting out a line in test/apli.c.

Design overview

TODO

See SKETCH file...

License

Copyright (c) 2010-2011 Thomas Novelli

This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

  1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.