Also implemented is the ‘=>’ keyword for ‘cond’ and ‘case’ is implemented now too. These 2 were needed to basically use ‘Macro by example’, unaltered.

On a further note, there seems to be a R4RS test ‘suite’, that I can hopefully use soon to implement most of the tests

[edit] So it seems it was not working correctly at all I have now gone thru it and fixed this issues [edit]

IronLisp progress

Lots of info and examples
Chez Sheme macros
Scheme FAQ: Macros
Old, but the appendix is quite descriptive

Off course the challenge was to actually test this code on IronLisp. At first I was rewriting alot to IronLisp dialect, this got tedious and error prone. I decided to use macro’s for what they intended for. Anyways 2 macro’s was sufficient for the bulk. And here they are:

(defmacro lambda (&rest body) 
  `(fn ,@body))
  
(defmacro define (nargs &rest body)
   `(defun ,(car ,nargs) ,(cdr ,nargs) ,@body)) 

As said, the aim was to test it, and beyond my expectations, it passed flying colors first time (except for a few syntax issues, like ‘new’ and clashing with existing functions).

I will be doing a checkin tonite. Some other things might still be broken, but you will get a nice dialog showing my acknowledgment of the issue

Anyways, things seems to be going the right way now, and I will make a checkin as soon as I have tested it a bit more. There are in fact alot more places that could be refactored

On the bright side, I seem to have gotten macro’s waxed. On the other hand, the code is in a total state of chaos! Anyways, macro’s are now all handled at compile time (probably very inefficiently), but they seem to do what I intend for them to do. Here is a sample of what it can handle:

(= defmacro (macro (name args &rest body) 
  `(= ,name (macro ,args ,@body))))  

(defmacro defun (name args &rest body) 
  `(= ,name (fn ,args ,@body)))
  
(defun hello (x)
  (prl x)
  (prl "hello")
  (prl x))  

(hello "leppie")

(defmacro define (name value)
  `(= ,name ,value))
  
(defmacro listp (l) 
  `(or (eq null ,l) (is cons ,l)))

(defun islist (x)
   (listp x))
   
(prl (islist 1))

(define ml '(1 2 3 4))
(prl (listp ml))

IronLisp: Build in release mode
Z:\dev\IronLisp\IronLisp\bin\Release>IronLisp.exe
time: 326.281ms
time: 303.722ms
time: 313.096ms
time: 304.353ms
time: 305.102ms

IronPython: Latest checkout, build in release mode
C:\dev\IronPython_Main\Bin\Release>ipy tak.py
Result: 7 Time: 0.763377747731
Result: 7 Time: 0.657344718393
Result: 7 Time: 0.655193607009
Result: 7 Time: 0.664234979585

Python 2.51
C:\Python25>python.exe -O tak.py
Result: 7 Time: 1.38913744624
Result: 7 Time: 1.38743890634
Result: 7 Time: 1.37719849869
Result: 7 Time: 1.37393355859

As you can see this paints a different picture. The picture is indeed very good as the DLR compiles most of the code. I tried running IronPython in ‘eval’ mode, but it seem to think about something forever (this didnt happen though previously when tested on the interactive console).

Here is the python code:

import time

def tak (x, y, z):
    if not(y < x):
        return z
    else:
        return tak(tak(x-1, y, z), tak(y-1, z, x), tak(z-1, x, y))

for i in range(4):
  t = time.clock()
  r = tak(24, 14, 6)
  t2 = time.clock()
  print "Result: ", r, "Time: ", (t2 - t)

dumb theme
And finally the IronLisp code (see that macro!!!):

(using System.Diagnostics)

(= tak (fn (x y z)
  (if (not (< y x))
    z
    (tak (tak (- x 1) y z)
         (tak (- y 1) z x)
         (tak (- z 1) x y) ))))

(= time (macro (x)
  `(do
      (= sw (startnew stopwatch))
      ,x
      (= ts (elapsed sw))
      (cwl "time: {0:f3}ms" (totalmilliseconds ts)))))

(to i 4
  (time (tak 24 14 6)))

1. IronLisp is not a replacement for LSharp, it shares common ideas.
2. The author of LSharp is NOT the author of IronLisp (although I wouldnt mind getting Rob on the team:)).
3. It is called IronLisp (as is IronRuby and IronPython, I assume) as it is targeted for the Silverlight core (iron/silver/metals, get it?).
4. As with IronRuby, the current state of the code is ‘very alpha’, and it doesnt even include a readme.txt and should be regarded as WIP (work-in-progress).
5. I am still learning the in’s and out’s of the DLR (which doesnt have much documentation yet), and this was my 1st attempt at using it for the purpose of constructing a (scripting) language. I have already seen places where I could have (and will probably in the future) done things better.

Another aspect mentioned was library support. Again, learning the entire LISP library(s) to get an idea of the implementation will be too great task for me. Having worked (almost exclusively) on the .NET Framework ‘library’ for the last 6 years, it is pretty much the only library I am really comfortable with. My idea with IronLisp is to let the .NET framework provide all the common libraries, and hence any .NET user can just learn a new syntax to use it practically. That will also keep IronLisp small and manageable.

Getting back to Scheme. Ideally IronLisp at some future time, will support/comply to some degree of Scheme, or will have a compatibility mode, or have macros to make it syntax (and functionally) compatible. With this in hand, hopefully IronLisp would be capable of running Scheme libraries.

Unfortunately, Scheme has no defined test suite, but the specification is rather unambiguous, and smaller in total than the Common LISP’s index!

Enjoy, and I am looking forward to all the feedback

IronLisp will be hosted at http://www.codeplex.com/IronLisp. For now it will contain very little infomation, but the latest code will be downloadable from the ‘source code’ tab. Anyone wanting to help out/contribute with development can contact me, or just supply a patch (if that is easier). If you are really serious, I will consider making you part of the project team .

The state of the current source:
1. Macros has not been implemented, and hence does not work (I hope to get this finished by the weekend).
2. ‘let’ behaves like the Scheme version, but does not support ‘named let’.
3. No ‘with’, use ‘let’ instead.
4. No ‘nconc’, use ‘append’.
5. Although previously stated that IronLisp will not have a ‘cons’ class, it does infact have one now. All the ‘cons’ operations do work on IEnumerable though.
6. The source of the DLR is almost exactly the same as the latest IronPython release, but does include an enhancement, and 2 bug fixes (althought the latter is just used in debugging).
7. Passing a single argument to ‘subtract’ eg (- a) will negate the value.

Most of the other implemented operations works like they do in LSharp.

I hope this implementation will be a good introductory platform for using the DLR to shape your own scripting languages.

Thanks and enjoy

I found a benchmark in an old Lisp PDF (mainly for computers running in the 60′s – 70′s I guess), it is called ‘tak’.

(using System.Diagnostics)

(= tak (fn (x y z)
  (if (not (< y x))
    z
    (tak (tak (- x 1) y z)
         (tak (- y 1) z x)
         (tak (- z 1) x y) ))))


(= run-tak (fn ()
  (= sw (startnew stopwatch))
  (= t (tak 24 14 6))
  (= ts (elapsed sw))
  (cwl "time: {0:f3}ms result: {1}" (totalmilliseconds ts) t)))

(to i 4
  (run-tak))

The above code executes in about 660ms in compiled/debug mode, and about 440ms in compiled/release mode. The fastest C# code I can dish up runs in about 85ms. While this may seem slow, I decided to compare it to Python and its managed cousin, IronPython. Python runs in about 2500 ms in the evaluator, while IronPython takes a whopping 11 seconds. On the other hand, IronLisp in eval mode, runs it in 2200ms. Still faster than Python!

On the scoping front, closures seems to be detected correctly, but the DLR provides no way to detect the delegate type at compile time. The delegate type is only available at the emission of IL stage, and then it’s a bit late! Also, there seems to be big differences in the DLR between running in interpreted vs. compiled mode.

(let ((x (* 3 4))) (+ x x)) => ((fn (x) (+ x x)) (* 3 4))

This yields exactly the same result and is semantically the same.

My design wasn’t so flawed after all, it was my interpretation of how quote works :p

Now that I have eval working properly (well as much as I can see (i really need to start writing tests(no pun intended with the braces))), I will be battling macros next. Also, scoping of some constructs eg. let, with, etc.

After that will I will like release the source. Closures and some other functionality will be missing still.

• eval is a total nightmare
• eval of quote‘d expressions is a worse nightmare
• macro relies on eval
• consistency of quote‘d expressions
• compiling eval‘d expressions
• some functionality not available in the DLR yet

Unfortunately, I didnt go deep enough into the Lisp ‘spec’ at the start, and my design is a bit flawed in a sense.

So thats about it…

On a different note: IronLisp will be opensource, and will be hosted on Codeplex under the MS Permissive License. Contributions/patches will be accepted.

Missing:

• Some functions
• Macro support
• Closure support
• Tests

New:

• Simple class support
• Compilation & Source level step debugging

Different:

• No Cons class, IEnumerable replaces it

Here is a sample of some working code:

(defclass foo
  (= arg (prl "in ctr")) ;define field with init expression
  (= bar (fn (a) (prl a )) ) ;define method taking 1 arg
)

(= myfoo (new foo)) ;init new foo

(bar myfoo "hello world") ;call myfoo.bar()
(prl ?) ;print previous result
(prl (arg myfoo)) ;print myfoo.arg

I have also decided to host this project at Codeplex, and will supply the url soon.

So far it can do:

(= hello
  (fn (say who)
    (
      (pr say)
      (pr " ")
      (prl who))))

(hello "hello" "peter")
(hello "water" "melon")

(prl say)
(prl who)
(prl ?)

More to come soon!