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]
Show HN: Lisp in C#
21–30 of 70 posts
Re: Show HN: Lisp in C#
#22Author 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…
I haven't had chance to look over the code but I know that using Span for parsing might be a nice thing to try out.
Have you considered making it compile to IL? Or if not that, using the Roslyn API to compile it to C# which is then automatically faster as a result of being compiled. Then getting AOT (ahead-of-time compilation) at build time gives you improved perf basically for free.
I see neon has contributed a perf change, I know that he's an expert at using https://github.com/dotnet/BenchmarkDotNet so hopefully you'll be able to do some scientific tests soon.
I would love to see another language here for the *Common* Language Runtime (CLR, the core of .NET).
Re: Show HN: Lisp in C#
#23You can annotate the code blocks in the README to get generic lisp syntax highlighting.
```lisp
(+ 1 2)
```
Re: Show HN: Lisp in C#
#24Author 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…
I haven't had chance to look over the code but I know that using Span for parsing might be a nice thing to try out. Have you considered making it compile to IL? Or if not that, using the Roslyn API to compile it to C# which is then automatically faster as a result of being compiled. Then getting AOT (ahead-of-time compilation) at build time gives you improved perf basically for free. I see neon has contributed a perf…
Bit of a tradeoff there; so long as it's using its own bytecode, the sharpl executable itself can easily be AOT. Once you start trying to create your own assembly at runtime and run that, it's a LOT of work to get the host to still AOT (because you have to include the dotnet runtime anyway to run the inner assembly!)
And AOT isn't a lot of free perf; it's mostly equivalent to JIT, the big advantage is faster and smaller startup.
(I have used the Roslyn compile API; it's pretty cool but you do have to do more setup. e.g. https://joshvarty.com/2016/01/16/learn-roslyn-now-part-16-th... )
Re: Show HN: Lisp in C#
#25Author 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…
By all means, keep them coming people :) We just roughly doubled the speed by changing one line of code, that means there's plenty more fun before it gets really tricky. My issue isn't really profiling, its not knowing enough about the platform to do anything constructive with the hot spots.
I don't know the platform and would -guess- that this won't actually help, but it's sufficiently fascinating I thought I'd share anyway: https://trout.me.uk/lisp/vlist.pdf (roughly "stitching together efficient cons lists out of arrays")
(and /lisp/ has an index if you want to see the other random lisp-related stuff I've collected copies of so I can find it again later)
Re: Show HN: Lisp in C#
#26Author 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…
I haven't had chance to look over the code but I know that using Span for parsing might be a nice thing to try out. Have you considered making it compile to IL? Or if not that, using the Roslyn API to compile it to C# which is then automatically faster as a result of being compiled. Then getting AOT (ahead-of-time compilation) at build time gives you improved perf basically for free. I see neon has contributed a perf…
Sure thing, Span is one of the features I haven't had time to dig into yet.
Parsing is a one time thing though.
Yes, different levels of compiling to C# are definitely on the table as options; for performance, but also to hopefully be able to generate self contained executables.
Even just generating my own bytecode for faster startup.
Re: Show HN: Lisp in C#
#27You can annotate the code blocks in the README to get generic lisp syntax highlighting. ```lisp (+ 1 2) ```
Thanks.
It's unfortunately enough of a bad fit for me to prefer no highlighting; my own fault, the price you pay for adding syntax.
Re: Show HN: Lisp in C#
#28So, 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
Observant :)
Polyglot projects have been sort of a thing lately, because micro services made them doable I guess; but I feel the combination of a capable and portable host language and a scripting language implemented in that language captures the best of both worlds while adding nice super powers on top.
Re: Show HN: Lisp in C#
#29Earlier quoted context omitted.
By all means, keep them coming people :) We just roughly doubled the speed by changing one line of code, that means there's plenty more fun before it gets really tricky. My issue isn't really profiling, its not knowing enough about the platform to do anything constructive with the hot spots.
I don't know the platform and would -guess- that this won't actually help, but it's sufficiently fascinating I thought I'd share anyway: https://trout.me.uk/lisp/vlist.pdf (roughly "stitching together efficient cons lists out of arrays") (and /lisp/ has an index if you want to see the other random lisp-related stuff I've collected copies of so I can find it again later)
Interesting, thanks.
Re: Show HN: Lisp in C#
#30Separate 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)
(^upto (n) (range 1 (- n 1)))
This concern brought to you by e.g. the great pain induced by the difference between
for x in "foo":
for x in "foo",:
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 ;)