Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Lisp in C#

github.com

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Show HN: Lisp in C#

#31

Post by codr7 »

mst wrote: 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…

Noted, I feel like I need more use cases and experience to say for sure.

Some way of forming ranges is planned anyways.

Re: Show HN: Lisp in C#

#32

Post by KineticLensman »

dualogy wrote: post #20
keithnz wrote: post #8

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.

There's also Make-A-Lisp and, unlike most write-you-a-lisp/scheme-s out there, that one also covers TCO interpretation, quasiquotation/unquote for macros and their expansion, and goes up to self-hosting: https://github.com/kanaka/mal/ I just went through it over 2-3 days, great practice IMHO to do once in your life from start to finish: https://github.com/metaleap/go-lisp

Concur, although it took me two to three months, not days (was working full time is my excuse). Biggest grief point was getting macro expansion to work correctly; TCO worked almost first time, IIRC.

Re: Show HN: Lisp in C#

#33

Post by codr7 »

KineticLensman wrote: post #32
dualogy wrote: post #20

Earlier quoted context omitted.

There's also Make-A-Lisp and, unlike most write-you-a-lisp/scheme-s out there, that one also covers TCO interpretation, quasiquotation/unquote for macros and their expansion, and goes up to self-hosting: https://github.com/kanaka/mal/ I just went through it over 2-3 days, great practice IMHO to do once in your life from start to finish: https://github.com/metaleap/go-lisp

Concur, although it took me two to three months, not days (was working full time is my excuse). Biggest grief point was getting macro expansion to work correctly; TCO worked almost first time, IIRC.

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.

Re: Show HN: Lisp in C#

#34

Post by mst »

codr7 wrote: post #31
mst wrote: 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…

Noted, I feel like I need more use cases and experience to say for sure. Some way of forming ranges is planned anyways.

Yeah, 'int is iterable' triggered "oh that's cute!" immediately followed by "... and the exact sort of cute I often find irresistably tempting myself and then regret later."

My current thing in progress has basically all of its temptation points already spent because I decided I was going to make it fexpr based, but I'm very definitely having fun with that so far - "no special forms required" makes for some interesting possibilities.

(kernel-lisp and kernel-thesis in /lisp/ are worth looking at if fexprs sound interesting, though I'm on the pragmatics side of things and will not pretend I came anywhere close to understanding the $vau calculus part)

Re: Show HN: Lisp in C#

#35

Post by codr7 »

mst wrote: post #34
codr7 wrote: post #31

Earlier quoted context omitted.

Noted, I feel like I need more use cases and experience to say for sure. Some way of forming ranges is planned anyways.

Yeah, 'int is iterable' triggered "oh that's cute!" immediately followed by "... and the exact sort of cute I often find irresistably tempting myself and then regret later." My current thing in progress has basically all of its temptation points already spent because I decided I was going to make it fexpr based, but I'm very definitely having fun with that so far - "no special forms required" makes for some interesti…

A certain level of helpfulness is nice though, Ruby and to a somewhat lesser extent Perl get that part right. I guess Perl could be seen as a warning example of what happens if you go all in.

Yep, I've been on a ride down the fexpr implementation hole previously; which is another reason I've been delaying user macros; still processing the experience.

Re: Show HN: Lisp in C#

#36

Post by KineticLensman »

codr7 wrote: post #33
KineticLensman wrote: post #32

Earlier quoted context omitted.

Concur, although it took me two to three months, not days (was working full time is my excuse). Biggest grief point was getting macro expansion to work correctly; TCO worked almost first time, IIRC.

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.

Re: Show HN: Lisp in C#

#37

Post by diggan »

neonsunset wrote: post #6
codr7 wrote: 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…

https://github.com/codr7/sharpl/pull/1 Was: 686 98 1195 Now: 226 79 293 (with net9.0 preview: 201 70 269, another release another free >10%) The reason for such a significant difference is that `ArrayStack ` only implements `IEnumerable `, which prevented the Enumerable.Last(stack) call from seeing that the type has an indexer which can be used to quickly access the last element instead of traversing it in its entire…

Interesting .gitignore addition. As someone who basically never writes C# (besides for some mods for games sometimes), is that the default ephemeral files that Visual Studio Code/some other tool writes when dealing with C# projects? Seems like an awful amount of trash if that's the case.

Re: Show HN: Lisp in C#

#38

Post by pjmlp »

codr7 wrote: post #28
zczc wrote: 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

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.

You mean rebranding distributed computing and OS IPC for newer generations?

Re: Show HN: Lisp in C#

#39

Post by neonsunset »

diggan wrote: post #37
neonsunset wrote: post #6

Earlier quoted context omitted.

https://github.com/codr7/sharpl/pull/1 Was: 686 98 1195 Now: 226 79 293 (with net9.0 preview: 201 70 269, another release another free >10%) The reason for such a significant difference is that `ArrayStack ` only implements `IEnumerable `, which prevented the Enumerable.Last(stack) call from seeing that the type has an indexer which can be used to quickly access the last element instead of traversing it in its entire…

Interesting .gitignore addition. As someone who basically never writes C# (besides for some mods for games sometimes), is that the default ephemeral files that Visual Studio Code/some other tool writes when dealing with C# projects? Seems like an awful amount of trash if that's the case.

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 :)

Re: Show HN: Lisp in C#

#40

Post by diggan »

neonsunset wrote: post #39
diggan wrote: post #37

Earlier quoted context omitted.

Interesting .gitignore addition. As someone who basically never writes C# (besides for some mods for games sometimes), is that the default ephemeral files that Visual Studio Code/some other tool writes when dealing with C# projects? Seems like an awful amount of trash if that's the case.

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 just a index.html file + your single JavaScript file, nothing else required or generated at all, and now you have a interactive website :)

Post reply on HN