Live data from Hacker News

Show HN: Lisp in C#

github.com

41–50 of 70 posts

Re: Show HN: Lisp in C#

#41
post #21

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

[deleted]

Re: Show HN: Lisp in C#

#42
post #33

Earlier quoted context omitted.

Unquoting took me several implementations to wrap my head around and consistently get good enough. As did register allocation, which is more of a VM issue.

Interesting. I'm about to start doing a MAL-like again, but this time (I used C# before) using Rust and building a VM as in Crafting Interpreters rather than following the MAL guide. Macros are one of the things that I anticipate being a challenge.

AFAICT, their expansion still happens during an interpretation cycle — but when you "interpret" AST into your byte-code.

Re: Show HN: Lisp in C#

#44
post #40

Earlier quoted context omitted.

As description in PR indicates, it’s just a default catch-all gitignore that you can add with ‘dotnet new gitignore’ that covers all kinds of tools and build artifacts, I see no reason to customize it. For large amounts of trash in project you would need to look for other languages, like JS ecosystem or certain Java-related projects :)

> As description in PR indicates, it’s just a default catch-all gitignore that you can add with ‘dotnet new gitignore’ that covers all kinds of tools and build artifacts, I see no reason to customize it. Ah, someone should just come up with a huge file so we can ignore every possible combination at this point :) > like JS ecosystem Heh, JS is probably the language that generates the least trash by default as it's jus…

GitHub doesn't have it all in one huge file, but has a somewhat comprehensive template repo of many ecosystems: https://github.com/github/gitignore

(This is what is used to populate the templates if you ask GitHub to include a gitignore when creating a new repo, or if you add a new file to a Repo and name it .gitignore and get the template selector to show up.)

I believe `dotnet new gitignore` basically shares the same template, even, as this file: https://github.com/github/gitignore/blob/main/VisualStudio.g...

Re: Show HN: Lisp in C#

#45
post #30

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 co…

Integers are also iterable in TXR Lisp. But in a different way; you get an infinite sequence starting from the value.

  1> [mapcar list '(a b c) 10]
  ((a 10) (b 11) (c 12))
This crops up on a regular basis in my coding, removing verbosity; I don't regret the decision. It's one of the "take alongs": something to repeat in a future language.

Re: Show HN: Lisp in C#

#46
post #5

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…

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…

A fun middle ground to compiling to IL is using System.Linq.Expression as a compiler. This was the middle ground that the "DLR" (Dynamic Language Runtime) used to great effect. System.Dynamic is still in the BCL and still useful, even though the dreams of IronPython and IronRuby and interop between them are sort of dead/dormant. System.Dynamic.DynamicMetaObject is still a fun thing to play with in how much power it gives you do some surprisingly optimized dynamic language things, all using System.Linq.Expression as the higher level intermediate language than raw IL.

Re: Show HN: Lisp in C#

#47

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.

Given how easy it is to expose functionality from the host language using existing facilities [0], and how complicated a reflection based FFI could get; I would rather not, at least not right now. It's also one of those decisions that will drastically limit my choices for future evolution of the implementation.

The general idea is to use both languages together, as complements; not calling one from the other.

https://github.com/codr7/sharpl/blob/main/src/Sharpl/Libs/Co...

Re: Show HN: Lisp in C#

#48

Earlier quoted context omitted.

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…

A fun middle ground to compiling to IL is using System.Linq.Expression as a compiler. This was the middle ground that the "DLR" (Dynamic Language Runtime) used to great effect. System.Dynamic is still in the BCL and still useful, even though the dreams of IronPython and IronRuby and interop between them are sort of dead/dormant. System.Dynamic.DynamicMetaObject is still a fun thing to play with in how much power it g…

Interesting, Linq.Expression actually looks doable within my complexity budget.

Re: Show HN: Lisp in C#

#49
post #42

Earlier quoted context omitted.

Interesting. I'm about to start doing a MAL-like again, but this time (I used C# before) using Rust and building a VM as in Crafting Interpreters rather than following the MAL guide. Macros are one of the things that I anticipate being a challenge.

AFAICT, their expansion still happens during an interpretation cycle — but when you "interpret" AST into your byte-code.

Or compile, since it's usually a transformation.

I like to call that the emit phase, as in emitting byte code.

The interesting thing is that it only happens once, before the code is evaluated.

Re: Show HN: Lisp in C#

#50
post #47

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.

Given how easy it is to expose functionality from the host language using existing facilities [0], and how complicated a reflection based FFI could get; I would rather not, at least not right now. It's also one of those decisions that will drastically limit my choices for future evolution of the implementation. The general idea is to use both languages together, as complements; not calling one from the other. https:/…

Ah, this is actually what I had in mind by "interop". So from C# I can evaluate some Lisp code and then test that the result is `PairType` (for example)? Maybe this is so obvious it goes without saying, but I didn't see any examples of that.
Post reply on HN