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

Compiler Development: Rust or OCaml?

hirrolot.github.io

Post reply on HN
Print view View original

91–100 of 107 posts

Re: Compiler Development: Rust or OCaml?

#91

Post by foldr »

timeon wrote: post #59
reikonomusha wrote: post #43

Earlier quoted context omitted.

It would be nice if somebody could offer what they consider to be an idiomatic Rust solution to this very routine problem in compilation if they believe the author is being intentionally deceiving. The Rust and OCaml code from the article looked decent to me. m

> The Rust and OCaml code from the article looked decent to me > RefCell I'm not sure.

Although I think the implementation of the gensym function is broken, the article does explain that it wasn’t possible to use &mut u32 because multiple references to the value were required. It would be more idiomatic to use Cell rather than RefCell, but there’s nothing really wrong with using RefCell as far as I can see.

Re: Compiler Development: Rust or OCaml?

#92

Post by pjmlp »

freeopinion wrote: post #63
tester756 wrote: post #50

Earlier quoted context omitted.

>while also having high runtime efficiency as a requirement (the reason why C/C++ are such prominent languages for compilers I'd want to believe that compiler engineers really put effort into compilers performance, but I just don't buy it. LLVM, GCC, MSVC, etc, etc all of them touch C/C++ and are slow as hell For compilers written in other languages I'd say that still LLVM is the bottleneck >It avoids the cost of aut…

Did Microsoft rewrite their C++ compiler in C#?

They did in the past, in something like LLVM, but based on MSIL, it was called Phoenix done by Microsoft Research.

In any case, it wouldn't make sense from having a bootstraped compiler point of view.

Re: Compiler Development: Rust or OCaml?

#93

Post by Karliss »

whimsicalism wrote: post #61
hardwaregeek wrote: post #24

I skimmed the article, and comparing the two programs, yes, the OCaml one is shorter and more elegant. But it also reads like a math magic spell. There's no type annotations for me to figure out what the heck each term is. The naming conventions lean extremely terse. Perhaps it's my lack of experience with OCaml, but it doesn't feel as legible. The Rust one reads like...well a program. A program that's not as beautif…

> There's no type annotations for me to figure out what the heck each term is. If types can be perfectly inferred, I don't see why I wouldn't take advantage of it. Whatever Ocaml IDE you use will easily be able to tell you the types anyways

I have no problems with type interference that happens within limited scope. Once you get into territory of type interference across multiple functions you get a similar problem as c++ template errors (before c++20), where the compiler can tell that types aren't correct but it's not clear where the actual mistake was made: did you pass a wrong value with with wrong type to a function at the top, did you use a wrong function call 5 levels deeper or did you access a wrong property somewhere in the middle. I am not sufficiently familiar with Ocaml to tell how much of a problem it's for the specific example in article, but I have some experience with C++ template errors and I remember similar problem in Haskell if type annotations were used too sparingly. Not every programing language will have as bad looking errors as c++ templates, but even if errors are short it doesn't change the inherent problem that compiler can't know what the intention behind large block of type interfered region was. More explicit types split the type interference into smaller regions which means that error message will be closer to the actual place of mistake made by programmer, it also allows checking each region individually for correctness.

Re: Compiler Development: Rust or OCaml?

#94

Post by liampulles »

hardwaregeek wrote: post #24

I skimmed the article, and comparing the two programs, yes, the OCaml one is shorter and more elegant. But it also reads like a math magic spell. There's no type annotations for me to figure out what the heck each term is. The naming conventions lean extremely terse. Perhaps it's my lack of experience with OCaml, but it doesn't feel as legible. The Rust one reads like...well a program. A program that's not as beautif…

Conversely, I'm not familiar with Rust, and Rust looks pretty illegible to me. Probably we need more experience with these languages before we judge.

Re: Compiler Development: Rust or OCaml?

#95

Post by derriz »

brmgb wrote: post #36
hardwaregeek wrote: post #30

Earlier quoted context omitted.

Can you explain what Menhir does better than other parser frameworks? For what it's worth, I'm not a huge fan of parser frameworks. I tend to prefer hand written parsers, either via a combinator library or fully manually. Rust has a pretty darn good ecosystem too btw. chumsky for parsing, rowan for syntax trees, salsa for incremental computation, miette for errors, inkwell/walrus for code generation.

It can generate elegant and efficient parsers for LR(1) grammars. > I tend to prefer hand written parsers, either via a combinator library or fully manually. That’s common with people used to languages which provide poor parser generators.

I don’t think so - I’ve written parsers using flex/lex yacc/bison, antlr, a bunch of functional combinator libraries and maybe others I’ve forgotten but now would never consider anything except hand-written recursive descent with an embedded Pratt parser for expressions and precedence.

Simple to write, debug, recover from errors, provide decent error messages, unit test, integrate into build systems, IDEs etc.

I also believe that nearly all the popular compilers these days do something similar - gcc was rewritten a few years ago in this fashion because of the technical benefits I’ve listed above.

Re: Compiler Development: Rust or OCaml?

#96

Post by medo-bear »

> Lisps can be very flexible, but they usually lack static type safety, opening a wide and horrible door to run-time errors.

People should do basic research before writing something silly like this. Qualifying your statement with 'usually' is just a chicken sh*t approach. Common Lisp and Racket have optional strong typing, leaving the responsibility and choice to the developer. Common Lisp is great for implementing compilers. You also have things like Typed Racket and Coalton. The latter is completely statically typed ala MLTON

https://github.com/coalton-lang/coalton

Re: Compiler Development: Rust or OCaml?

#97

Post by bjourne »

beaub wrote: post #41

Compilers are in this weird spot where they are really mathematically defined programs (which OCaml excels at implementing), while also having high runtime efficiency as a requirement (the reason why C/C++ are such prominent languages for compilers). With such requirements, I think a point that is fair to make is that Rust acts as a great middle-ground. It avoids the cost of automatic memory management and provides l…

The cost of automatic memory management is latency and increased memory usage. In a soft real-time system like a game, the garbage collector may cause lag spikes so you miss the head-shot on your opponent. You also require at least 50% more memory for efficient automatic memory management. Throughput, however, is not one of the costs. You can in fact achieve higher throughput with automatic memory management than with manual memory management.

Re: Compiler Development: Rust or OCaml?

#98

Post by hardwaregeek »

brmgb wrote: post #90
hardwaregeek wrote: post #66

Earlier quoted context omitted.

That's great and I agree for these use-cases a parser generator makes sense. But that doesn't answer my question about what makes these parsers particularly elegant. Nor does it seem to be a benefit specific to Mehnir, since any parser generator has the quick iteration speed. I don't mean to blame you for that; you are answering a question about something that you did not say. But I find it frustrating that Mehnir se…

> with a good example of how it's better than any other parser generator. I already told you that it has full support for disambiguating LR(1) grammar and still generating a parser which is easy to read. How do you want me to paste a full parser in a HN comment? Most generators only support LALR(1) grammar which is limiting and don’t deal with corner cases as gracefully. I get that you are hell bent on wanting Rust t…

Okay…so it accepts more grammars than other parser generators. That doesn’t seem massive if I’m being honest. If you had said mehnir works with your IDE (navigating C code inside bison drove me nuts), and had good support for error recovery and idk, gave you syntax highlighting for free, I’d agree. But a minor upgrade in grammars? Not exactly Christmas here.

I have a question for you then: why is it that so many projects that are not performance bound, that are not low level systems projects, why do they use Rust and not OCaml? OCaml had a 22 year head start after all.

Re: Compiler Development: Rust or OCaml?

#99

Post by tester756 »

JonChesterfield wrote: post #67
tester756 wrote: post #50

Earlier quoted context omitted.

>while also having high runtime efficiency as a requirement (the reason why C/C++ are such prominent languages for compilers I'd want to believe that compiler engineers really put effort into compilers performance, but I just don't buy it. LLVM, GCC, MSVC, etc, etc all of them touch C/C++ and are slow as hell For compilers written in other languages I'd say that still LLVM is the bottleneck >It avoids the cost of aut…

Any compiler that gets used at runtime (branded JIT, usually) ends up growing performance hacks or being written from scratch to run quickly. Javascript is prone to using multiple compilers based on how frequently code was executed. That's also what the whole -O0 -O3 -flto -thin-lto -pgo etc flags are about, granting permissions to burn different amounts of time during compilation. It's really easy to accidentally wr…

Ehh, I don't think we were talking about just JITs.

JITs are just some part of what's under the general "compilers" term

Re: Compiler Development: Rust or OCaml?

#100

Post by funcDropShadow »

tyg13 wrote: post #82
solomonb wrote: post #68

Earlier quoted context omitted.

So the solution to writing idiomatic code in the language whose essential feature is the ownership semantics and borrow checker is to not use the ownership semantics and borrow checker?

This is sort of a flippant response, but I'll answer it seriously. The premise of this question is incorrect: you can't not use the borrow checker in Rust. Instead, you are satisfying the borrow checker by ensuring at the point of use (deref of the ID) that there is valid data by providing a provably-live reference to the arena in which it was allocated. In another language like C/C++, you'd just use a raw pointer, w…

But compilers deal usually with trees not general graphs.
Post reply on HN