Emacs Lisp revived

Emacs Lisp revived

[Daniel Kraft]

Hi all,

I finally started real work on implementing the elisp compiler and just 
pushed a first start-off code to branch elisp.  It is however not yet 
usable for anything, but also already has some very few things done.

Some important points I'd like to mention and welcome comments:

1) In implementing all those special forms like progn, prog1, if, while, 
...  I think it is best to translate a basic set directly to TreeIL via 
the compiler, but also implement some (where that's reasonably possible) 
simply as elisp macros (or even some things as functions).  What do you 
think about this plan?

2) It seems that elisp uses nil as false value (and does not have a 
dedicated false); so the question raises, should be then always use #f 
for nil, or maybe TreeIL's void?  But some experiments show that void is 
rather interpreted as true:

tree-il@(guile-user)> (if (void) (const 1) (const 2))
1

scheme@(guile-user)> (if (if #f 0) 1 2)
1

Not related, but I came across it: (if (begin) 1 2) gives an error, 
don't know if that's expected.

I think I remember already reading some discussion about this topic in 
general for Guile's elisp support; so what should we do here?  My code 
so far uses #f as nil, BTW.

3) I still haven't got building lexical constructs in TreeIL working 
(and I figure that named-lets for compiling the while-construct are even 
more interesting), but will hopefully manage to do so soon...

Yours,
Daniel

Re: Emacs Lisp revived

[Andy Wingo]

Howdy,

On Tue 09 Jun 2009 22:07, Daniel Kraft <d@domob.eu> writes:

> I finally started real work on implementing the elisp compiler and just
> pushed a first start-off code to branch elisp.  It is however not yet
> usable for anything, but also already has some very few things done.

Yay!! I hope to have time to look at your branch soon :)

> 1) In implementing all those special forms like progn, prog1, if, while,
> ...  I think it is best to translate a basic set directly to TreeIL via
> the compiler, but also implement some (where that's reasonably possible)
> simply as elisp macros (or even some things as functions).  What do you
> think about this plan?

A core should compile to tree-il, and then you should be able to build
the rest with macros. What fun, no? :)

> 2) It seems that elisp uses nil as false value (and does not have a
> dedicated false); so the question raises, should be then always use #f
> for nil, or maybe TreeIL's void?

Don't use void. You should use Guile's %nil, and we should have a
make-nil instruction. %nil was added to Guile for precisely this
purpose.

> tree-il@(guile-user)> (if (void) (const 1) (const 2))

Oh yes, (void) is true indeed. (I'm happy you're using the tree-il repl
btw, that's nice :)

> Not related, but I came across it: (if (begin) 1 2) gives an error,
> don't know if that's expected.

Yes, it is an error. Surprising to me when I found that out, but even
R5RS prohibits it.

> 3) I still haven't got building lexical constructs in TreeIL working
> (and I figure that named-lets for compiling the while-construct are even
> more interesting), but will hopefully manage to do so soon...

Ooh, sorry for not getting back to you about that. I'm sleepy now though
;) Here's some examples:

scheme@(guile-user)> (use-modules (language tree-il))
scheme@(guile-user)> (unparse-tree-il (compile '(let ((x 10)) (+ x x)) #:to 'tree-il))
$3 = (let (x) (x33) ((const 10)) (apply (toplevel +) (lexical x x33) (lexical x x33)))
scheme@(guile-user)> (unparse-tree-il (compile '(let ((x 10)) (+ x x)) #:to 'tree-il))
$4 = (let (x) (x34) ((const 10)) (apply (toplevel +) (lexical x x34) (lexical x x34)))
scheme@(guile-user)> (unparse-tree-il (compile '(let ((x 10)) (+ x x)) #:to 'tree-il))
$5 = (let (x) (x35) ((const 10)) (apply (toplevel +) (lexical x x35) (lexical x x35)))
scheme@(guile-user)> (compile '(let ((x 10)) (+ x x)) #:to 'tree-il)
$6 = #<<let> src: #f names: (x) vars: (x36) vals: (#<<const> src: #f exp: 10>) body: #<<application> src: #f proc: #<<toplevel-ref> src: #f name: +> args: (#<<lexical-ref> src: #f name: x gensym: x36> #<<lexical-ref> src: #f name: x gensym: x36>)>>

You see what changes and what does not? The gensyms are "fresh names"
for the lexically bound vars. They are introduced in the binding
constructs and included in the references. You can make a gensym with
the `gensym' procedure.

Happy hacking!

Andy
-- 
http://wingolog.org/