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

Lisp implemented in Rust macros

github.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Lisp implemented in Rust macros

#61

Post by sham1 »

danschuller wrote: post #55
meindnoch wrote: post #53

But C++ is not a sane language because templates are Turing-complete, right?

C++ is not a sane language for anyone with a passing familiarity. At least Rusts macros aren't literal text substitutions, a move towards the light.

To be fair, neither are C preprocessor macros. They're instead token substitutions. It's not that much better, but they're not literally text substitution. They're at least more clever than just that.

They're also of course surprisingly powerful, at the expense of being very cludgy.

Re: Lisp implemented in Rust macros

#62

Post by xedrac »

rapsey wrote: post #48
krick wrote: post #27

Everyone is supposed to be cheering for how "fun" it is, but every time I see anything like that I cannot help but think, that I hate the fact it can be implemented in Rust. It never truly was a simple language, but I think it started as something way more manageable than what it has become.

The only real change since 1.0 was async. If you want to live without async that is completely up to you. It is an entirely optional part of the language. If you want a language guided by the principle of simplicity Rust was never that and you have plenty of options elsewhere.

Except that many crates only provide an async interface. I actually use async for many things, but the whole colored functions thing is really annoying.

Re: Lisp implemented in Rust macros

#63

Post by fallat »

quasigloam wrote: post #8
p4bl0 wrote: post #6

That was fun. Thanks for sharing!

Thanks! It was fun to make. It was also instructive, as I learned that rust analyser doesn't handle macros generating millions of tokens :D

I would love for you to elaborate on lessons learned in the project readme!

Re: Lisp implemented in Rust macros

#64

Post by klrtaj »

duetosymmetry wrote: post #5

Greenspun's tenth rule strikes again! https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

A great example of the rule is that C++ rediscovers car/cdr at a glacial pace in the template language. In C++26 one can finally get the car of a typename parameter pack with Args...[0].

I've no idea why they don't introduce car/cdr functions and nil for empty parameter packs and allow to store parameter packs instead of the current syntax insanity.

Re: Lisp implemented in Rust macros

#66

Post by josmar »

krick wrote: post #27

Everyone is supposed to be cheering for how "fun" it is, but every time I see anything like that I cannot help but think, that I hate the fact it can be implemented in Rust. It never truly was a simple language, but I think it started as something way more manageable than what it has become.

If it's Turing Complete, there will be a LISP for it

Re: Lisp implemented in Rust macros

#68

Post by gpderetta »

klrtaj wrote: post #64
duetosymmetry wrote: post #5

Greenspun's tenth rule strikes again! https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

A great example of the rule is that C++ rediscovers car/cdr at a glacial pace in the template language. In C++26 one can finally get the car of a typename parameter pack with Args...[0]. I've no idea why they don't introduce car/cdr functions and nil for empty parameter packs and allow to store parameter packs instead of the current syntax insanity.

C++ metaprogramming was done with cons cells already back in '98. The new syntax provides random access instead, which is completely different from linked lists.

Re: Lisp implemented in Rust macros

#69

Post by samatman »

krick wrote: post #26
munificent wrote: post #13

Earlier quoted context omitted.

I like that the "sufficiently complicated" part bothered you, but not the "ad hoc", "informally-specified", "bug-ridden", or "slow" parts.

No, I think it's pretty fair. One could argue about these, but except for "slow" these are more quality qualifiers, rather than quantity. So you either agree it's "bug-ridden" or not (i.e. the number and seriousness of bugs in it is negligible by whatever standards). And I think even "slow" can be discussed in the same manner, the actual speed is quantitative, of course, but in the end one either argues that this spe…

A man of culture would never refer to an epigram as a definition.

Re: Lisp implemented in Rust macros

#70

Post by pjmlp »

Nevermark wrote: post #46
kazinator wrote: post #29

Earlier quoted context omitted.

This is correct. Greenspun's Tenth Rule is not meant to be interpreted as applying to projects that are consciously creating a Lisp implementation. It's about programs which are not meant to be language implementations at all reinventing ad hoc infrastructure that is designed in Lisps according to established patterns. For instance, badly reinventing something that functions as symbols.

I conjecture the line is not so easy to draw. If you are creating Lisp because you want to create Lisp, like creating Lisp, want to show off creating Lisp, that obviously is not what the Law is about. Furthermore, if you create Lisp because you know the Law, know it is inevitable, and want to avoid the caveats and missed bars by doing so explicitly, well then that also is not what the Law is about. But if you are goi…

Except it is been like 60 years that any proper Lisp implementation has more than plain cons lists.
Post reply on HN