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

21–30 of 85 posts

Re: Lisp implemented in Rust macros

#21

Post by quasigloam »

throwup238 wrote: post #19
quasigloam wrote: post #18

Earlier quoted context omitted.

Yes, at the moment I just assume that all atoms are rust idents because that makes it easier to implement (I can just match against $x:ident), so it doesn't support dashes in atoms. I guess you could match against `$x:ident $(- $y:ident)*` instead? That should work I think, I'd have to change some details in some of the arms but it seems like that would be possible.

Wouldn’t that match “(foo - bar)” as well as “(foo-bar)”? I don’t think you can get around token whitespace in macro_rules

Yes it would match both, this would require us to assume that "foo - bar" can only be an atom. It's not a great solution.

Re: Lisp implemented in Rust macros

#23

Post by throwup238 »

anothername12 wrote: post #20
quasigloam wrote: post #18

Earlier quoted context omitted.

Yes, at the moment I just assume that all atoms are rust idents because that makes it easier to implement (I can just match against $x:ident), so it doesn't support dashes in atoms. I guess you could match against `$x:ident $(- $y:ident)*` instead? That should work I think, I'd have to change some details in some of the arms but it seems like that would be possible.

Does Rust have something like a reader macro where you can have arbitrary syntax for a bit?

It's almost but not quite arbitrary. It still has to be a valid Rust token stream with matching braces/parens. Since it's whitespace insensitive with respect to tokens and "-" is its own token, "(foo-bar)" and "(foo - bar)" result in the same token stream minus the span information.

You can use proc_macro::Span.line()/column() [1] to track how much whitespace there is between tokens and merge them, but the macro will have to rename them to valid Rust identities ("foo-bar" to "foo_bar") and make sure there's no collisions.

[1] https://doc.rust-lang.org/proc_macro/struct.Span.html#method...

Re: Lisp implemented in Rust macros

#25

Post by wild_egg »

dokyun wrote: post #14
gleenn wrote: post #3

I 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?

Some Lisp compilers like SBCL are already capable of more extensive compile-time type-checking, but its information that the programmer is up to supply, and tends to be the part of the optimization stage rather than normal, incremental development. Lisp is usually defined by its dynamic nature, and run-time type checking is a big part of this. Making the programmer have to worry about how objects are managed before t…

> perhaps something that reflects the losing characteristics of both philosophies.

Oof. With how much love Rust gets here, I didn't expect to see it being called out like that.

How about "The Worse Thing"?

Re: Lisp implemented in Rust macros

#26

Post by krick »

munificent wrote: post #13
dgfitz wrote: post #7

Earlier quoted context omitted.

What defines "sufficiently complicated" I wonder? Seems like a shit definition.

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 speed is "slow" or isn't. So, given some rhetoric skills of your opponent it's at least possible for that statement to be proven false, if he convinces you the implementation actually isn't slow nor bug-ridden, or at least if there's no Lisp-implementation indeed.

But what is "sufficiently" complicated? Now it's a silly statement that just doesn't pass Popper criterion: even if nobody dares to deny your program is complicated, one can always say it isn't sufficiently complicated, hence the fact it doesn't contain Lisp-interpreter disproves nothing. A man of culture wouldn't use such definitions.

Re: Lisp implemented in Rust macros

#27

Post by krick »

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.

Re: Lisp implemented in Rust macros

#28

Post by zxexz »

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.

Rust is definitely not a simple language, I agree there.

I am quite likely a bit naïve here, but I'm having trouble understanding why you hate that this is possible. Now, the macro system definitely can generate near infinitely-complex code, but I'm not getting how implementing a sandboxed lisp using macros is a particularly potent example of the language being less manageable than at its genesis.

On another note, the fact that the type system is turing-complete, like with C++ templates or the Haskell type system (variously dependent on which GHC languages extensions you're using...), makes me want to see a lisp implemented that way!

Re: Lisp implemented in Rust macros

#29

Post by kazinator »

bigdict wrote: post #24
duetosymmetry wrote: post #5

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

nah, this is about codebases that are not themselves primarily lisp implementations

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.

Re: Lisp implemented in Rust macros

#30

Post by kazinator »

dgfitz wrote: post #7
duetosymmetry wrote: post #5

Greenspun'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.

That's explicitly encoded right in the rule itself! When the program contains a bug-ridden, ad-hoc simulacrum of half (or more) of Common Lisp, then it has become sufficiently complicated. When it has less than half, it is not yet sufficiently complicated.
Post reply on HN