== aloysLisp ==

A long, long time ago....

Well, as you can see, it hasn't moved from a long time.... but it's tsill here 
in the state it was. :D

I think 2 month in whole of various reflections, and not so bad ideas.

The third time, I rewrote the whole stuff, I understood the problem was grabbing 
a standard and not grabbing a language. A lot of overwhelming stuff, details, 
as the most important thing was make it easy...

I wanted to put all the stuff out, and quitting COMMON LISP standards. Taking some 
more functionnal and straighforward way... Halas, someone had already done that, and in a light way...

So rewrite clojure to make an objective lisp.... pfff ! lisp2 with a lisp1, rewrite 
clojure. Make a new lib to make an objective lisp, one more... no...

So... sorry for this trial, but, you can look inside the pros, and cons and the 
problems I encounter. It can be read as a novel : ideas, good and bad, regrets, 
dead ends, and so.

But I think, I can definitively put this thread as DEPRECATED. Anyway if someone 
want to try a Frankenstein work he's free to make the monster live again, the way he wants :D

  IP 02/03/2013
 
 A LISP interpreter, compiler and library.
 
 Copyright (C) 2011 kilroySoft [[aloyslisp@kilroysoft.ch]]
  
 Authors 
	Ivan Pierre [[me@ivanpierre.ch]]
	George Kilroy [[george@kilroysoft.ch]]
	
  IP 03/03/2011

== PREAMBLE ==

I liked a lot LISP language in my first programming age. Well, time flies like
an arrow, thirty years ago. There was no Internet and grabbing infos was an hard
work in libraries. As a beginning stage, I analysed a PROLOG interpreter in LISP
I had found in some Unix server at Polytechnic School of Lausanne. But there was 
no LISP interpreter available.

The first one I tried was Acorn LISP on the BBC computer (int he old and dark cave age). 
Try is not the right word this one was very basic but efficient, so I disassemble 
the ROM and discover the beautiful concept of a self-written language. Once the basic 
structure found, the first program to create was a rom disassembler taking the LISP 
internal structure. For the beginning in BASIC, and afterward in LISP.

Some time ago, I discoverd that LISP had had some improvements with COMMON-LISP, Scheme
and other implementation. As I needed LISP for some musical analysis and text generation,
hierographical text analysis and translation for my own interest. I looked at some 
implementations. Working these times in Java, I found Jatha, that was a simple interpreter 
and p-code generator. But improving it for COMMON-LISP compatibility, I stopped the work
because of structural problems.

Two month ago, I took back the project and decided to take it back, but rewriting the whole 
stuff from beginning. I know ! there's already ABCL, Clojure, ... but making it by myself 
is more fun and valuable that using someone's else code (even if I did). So, that's 
this project.

== LINKS ==

* aloysLisp community : [[http://aloys.li/sp]]
* Javadoc page : [[http://kilroysoft.github.com/aloysLisp/doc]]
* GitHUB repository : [[http://github.com/kilroysoft/aloysLisp]]
* Documentation : [[http://github.com/kilroysoft/aloysLisp/wiki]]

== MAIN IDEAS ==

=== Simpliest core as possible ===

Only base LISP objects are defined with their base functions. Main goal is not efficiency
but simplicity, readability and code independence. In intend of developpement process
some places will be hard coded as first draft, this is to be removed as soon as possible.

=== Java and LISP programming ===

The whole lisp should be made in LISP. But base objects interface is defined in Java. 
All the access and constructor functions as access to Java library will be programmed as 
primitives that can be called by both Java (with java arguments) and LISP (with LISP
interface).

Evaluation process manages the conversion if needed. LISP interface is generated directly 
from Java source code using annotation information. Compilation of LISP code will produce
Java code with the intended annotations.

=== Java compilation ===

As LISP and java programming interface to LISP objects are someway homomorphic, it's
more efficient to generate binary code as JVM code through the Java compiler and not
through an intermediary b-code. A lot of optimization will be managed by java itself
as will be garbage collection.

Compiled code using Java form dynamic variables management will be done in a Java way.
LISP Strings will be Java Strings and so on. Compiled functions and macros will be 
created with source in Java, so compilation improvement will be tested. 

That's all folks !!!! for now...