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

A MOS6502 assembler impleme​nted as a Rust macro

play.rust-lang.org

Post reply on HN
Print view View original

51–59 of 59 posts

Re: A MOS6502 assembler impleme​nted as a Rust macro

#51

Post by SixSigma »

nickpsecurity wrote: post #33
sklogic wrote: post #29

Earlier quoted context omitted.

> It's so easy to write useful but awful things with them, and they're really hard to fix and debug. And it is even easier to write useful, beautiful things with macros, which are really easy to fix and debug.

Back when I did a 4GL with them, my amateur trick was to write and test them like normal programs first. Then in the templated form as a normal program. Then do macros. On first two, I can use any technique known to benefit software quality. For programming in the large, interface checks that enforce correct usage are a straight-forward solution. Curious, with your LISP and ML background, what method or methods do yo…

I can't remember the exact quote but :

LISP's FOR macro got so clever that LISP programmers do everything they can to avoid using it

Re: A MOS6502 assembler impleme​nted as a Rust macro

#52

Post by Soft »

bsaul wrote: post #50
pcwalton wrote: post #24

Earlier quoted context omitted.

This is silly. Rust could not achieve its performance and safety goals without macros and generics. Generics may have been optional for Go (I don't agree, but let's go with it), but there is no way to achieve zero-cost memory safety without generics (while supporting first-class references and dynamic allocation). Rust generics are deliberately less expressive than C++ templates, in that they're strongly typed. That'…

Maybe there still should be a compiler option to automatically evaluate the degree of abstraction complexity of a code, much like cyclomatic complexity, to prevent abuses ?

Not that I agree with your point, but cyclomatic complexity checks are actually implemented as a compiler plugin in rust-clippy project[1]. You'll get a compile time warning if your function becomes too complex.

[1]: https://github.com/Manishearth/rust-clippy/wiki#cyclomatic_c...

Re: A MOS6502 assembler impleme​nted as a Rust macro

#53

Post by sklogic »

evincarofautumn wrote: post #47
sklogic wrote: post #21

Earlier quoted context omitted.

Macros should never be ugly. There are multiple ways of using compile-time metaprogramming in a nice and clean way. Maybe even in Rust, although I have not tried it yet.

If your macro is ugly, but it makes your code pretty, it might mean you’ve successfully sequestered some ugliness, which is probably a good thing.

Of course. But there is no need to write ugly macros. Any macro of any complexity can be written in a nice and clean way.

Re: A MOS6502 assembler impleme​nted as a Rust macro

#54

Post by ilurkedhere »

Lisp user here.

This reminded me of https://github.com/kingcons/cl-6502 where the opcodes are defined using a defasm macro https://github.com/kingcons/cl-6502/blob/master/src/cpu.lisp... and implemented here https://github.com/kingcons/cl-6502/blob/master/src/opcodes....

Are Lisp macros pretty much on par with Rust macros?

Re: A MOS6502 assembler impleme​nted as a Rust macro

#55

Post by FreeFull »

ilurkedhere wrote: post #54

Lisp user here. This reminded me of https://github.com/kingcons/cl-6502 where the opcodes are defined using a defasm macro https://github.com/kingcons/cl-6502/blob/master/src/cpu.lisp... and implemented here https://github.com/kingcons/cl-6502/blob/master/src/opcodes.... Are Lisp macros pretty much on par with Rust macros?

I was under the impression Lisp macros are more powerful/flexible than Rust's macro_rules! macros, although I don't know enough about Lisp macros to be sure.

Re: A MOS6502 assembler impleme​nted as a Rust macro

#56

Post by Manishearth »

Animats wrote: post #23
JustSomeNobody wrote: post #19

Earlier quoted context omitted.

Being a developer myself, I'm well aware of this. Still, it's ugly.

When I see this, I understand why the Go crowd didn't put generics or macros in Go. It's so easy to write useful but awful things with them, and they're really hard to fix and debug. This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this. Remember "Diesel", the Rust compiler for SQL, from a few days ago? Just because you can doesn't mean you should. Too…

> This is getting to be a big problem with Rust.

I haven't seen any examples of this happening in actual code. Sure, you have lots of toy things but that's just stuff people do for fun.

And as was adequately explained in that thread, ORM is an existing pattern from other languages that people like using. It's got some nifty benefits to it; so while it's not what you'd usually do it's not an overcomplication. Like Patrick said, its only "problem" is that it's an ORM.

> Overly elaborate templates damaged C++; nobody could figure out what was going on. Use of C++ for new work declined.

This happens because C++ templates aren't typechecked, so working with them requires you to understand their internals to some degree ("what kind of type does this expect?"). Rust generics are typesafe. Rust macros aren't, but they're not encouraged as much as generics/templates are so you don't see much convoluted things except as fun experiments (who doesn't want to write a brainfuck interpreter in rust macros?). People understand that macros will give substandard error traces and mostly only use them for quick and straightforward deduping of code.

Re: A MOS6502 assembler impleme​nted as a Rust macro

#57

Post by Manishearth »

pjmlp wrote: post #48
pcwalton wrote: post #39

Earlier quoted context omitted.

No Rust production program will ever transitively depend on a library with a 6502 assembler written in the macro language.

You are missing the point. It is not the ORM library or the 6502 Assembler. It is the library written by the clever guy on the third floor from blue team, for the new product being developed at Corpo X. However I also have seen lots of convoluted code, exactly because such expressiveness is missing from the language. For example, JVM bytecode manipulation or use of external code generators.

> However I also have seen lots of convoluted code, exactly because such expressiveness is missing from the language.

That's the operating point here. Leave out expressivity, and tons of programmers write convoluted code. Leave it in, and a couple of clever people use it in an over-clever way.

Re: A MOS6502 assembler impleme​nted as a Rust macro

#58

Post by EvenThisAcronym »

pcwalton wrote: post #46
EvenThisAcronym wrote: post #42

Earlier quoted context omitted.

> That's why we get so many complaints from C++ and D developers that you can't do certain things. But Rust sticks with its strongly-typed generics, because Rust has always tried hard to strike a balance between code expressivity and maintainability. In what sense are Rust macros "strongly-typed"? D and C++ templates are also strongly typed, just like the rest of the language.

Rust generics are strongly typed. C++ and D templates are, however, untyped. You can get errors at template instantiation time in C++ and D, because the compiler makes no attempt to ensure that the types your template operates on actually support the operations you're performing on them at the time you declare the template. In Rust (and basically every other language), though, the compiler typechecks your templates a…

Ah, I see. I'm assuming then that Rust generics are not generative templates like C++/D, but closer to Java/C#.

Re: A MOS6502 assembler impleme​nted as a Rust macro

#59

Post by comex »

EvenThisAcronym wrote: post #58
pcwalton wrote: post #46

Earlier quoted context omitted.

Rust generics are strongly typed. C++ and D templates are, however, untyped. You can get errors at template instantiation time in C++ and D, because the compiler makes no attempt to ensure that the types your template operates on actually support the operations you're performing on them at the time you declare the template. In Rust (and basically every other language), though, the compiler typechecks your templates a…

Ah, I see. I'm assuming then that Rust generics are not generative templates like C++/D, but closer to Java/C#.

They're like Java/C# syntactically. Implementation-wise, they're monomorphized (code is generated for each specialization at compile time) like C++.
Post reply on HN