Lisp implemented in Rust macros
51–60 of 85 posts
Re: Lisp implemented in Rust macros
#52I wish there was a well-supported Lisp in Rust, not just the macros. I wonder how much memory safety you would retain or lose being based in Rust. Is it even possible to leverage the borrow checker any any sane way?
Steel seems alright: https://github.com/mattwparas/steel There are other Lisps too ( https://github.com/alilleybrinker/langs-in-rust ) though I think they’re less actively maintained.
Re: Lisp implemented in Rust macros
#53Re: Lisp implemented in Rust macros
#54Greenspun's tenth rule strikes again! https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
What defines "sufficiently complicated" I wonder? Seems like a shit definition.
Re: Lisp implemented in Rust macros
#55But C++ is not a sane language because templates are Turing-complete, right?
Re: Lisp implemented in Rust macros
#56Everyone 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.
(I checked; I win this bet: https://github.com/kchanqvq/CSP )
Re: Lisp implemented in Rust macros
#57Earlier quoted context omitted.
It would, but lisp has prefix operators, so you wouldn’t have to worry about it getting confused.
Although in a Lisp such as Scheme, you could pass around the negation operator in something like (map - '(1 2 3)), so it would be a valid concern that it might clash.
(defvar |do i 10| 1.100)Re: Lisp implemented in Rust macros
#58Re: Lisp implemented in Rust macros
#59Earlier quoted context omitted.
Pretty sure it applies to Common Lisp itself too.
The corollary to Greenspun’s rule is that any sufficiently complicated Common Lisp program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Prolog.
Re: Lisp implemented in Rust macros
#60Earlier quoted context omitted.
Pretty sure it applies to Common Lisp itself too.
The corollary to Greenspun’s rule is that any sufficiently complicated Common Lisp program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Prolog.