Author here.

I'm afraid I've been out of the C# loop too long to know what's fast and what isn't these days.

Now that maybe I have the attention of some serious C# nerds, any assistance in making this thing run faster would be much appreciated.

It's not terrible atm, given a managed host language, but I'm sure there are plenty of knobs left to turn.

See the benchmarks section in the README for more info, and the same benchmarks ported to Python in python/fib.py.

Oh, and there's some undocumented yet potentially useful stuff in /Libs; strings, terminal control and IO mainly.

If only we could get a tiny Lisp loving push from the HN crew, wink, nudge.

I don't much like the odds of Lisp vs. Nintendo hardware kickstarters.

There's also Clojure CLR (lisp) https://github.com/clojure/clojure-clr

It's worth mentioning https://github.com/IronScheme/IronScheme

years ago someone posted http://norvig.com/lispy.html here on HN

I wrote a lisp in C# based on that, it was only a 100+ ish lines of code. It was a great way to get into Lisp.

Cool, thanks for showing. Are you planning for any sort of FFI/interop in either direction? I don't see it in your TODO, but I also don't understand why you would write it in C# unless you had this in mind.

Cool! I didn't get a chance to run it but I dug around the code a little bit. I noticed there is a Macro class, but no mention of macros in the README. Are macros working?

Separate from anything else, I'm ... concerned ... at the idea of ints being iterable, because it seems like something I'd be much more likely to invoke accidentally than intentionally and then wonder wtf my program was doing. I'd prefer to have to write something like

    (reduce + (range 1 3) 0)

and if you find yourself wanting the natural number iteration regularly maybe

    (^upto (n) (range 1 (- n 1)))

as sugar.

This concern brought to you by e.g. the great pain induced by the difference between

    for x in "foo":

and

    for x in "foo",:

in python, for example.

It may turn out in practice that a lispy language and/or programmers who make different mistakes to me will make it not an issue ... but were it -my- project I'd probably comment out the iterator implementation for int and see if its absence annoyed me enough to decide it was worth bringing back.

(when perpetrating language myself I often find that some of my favourite bits of clever don't pass the 'annoyed me enough' test and end up as documentation examples or similar in the end instead ... hopefully you have better luck ;)

You can annotate the code blocks in the README to get generic lisp syntax highlighting.

```lisp

(+ 1 2)

```

So, it is a shortcut around the tenth rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp" [1]

[1] https://en.wikipedia.org/wiki/Greenspun's_tenth_rule

[dead]