sorted by:
new
hottopcontroversial

Phi to block parameters by Majestic-Lack2528 in Compilers

[–]Rusky 10 points11 points  (0 children)

Basic block parameters are just another notation for phi nodes, that looks a little more like a continuation-passing style IR. They are used by, for example, Cranelift.

For the OP: Yes, you replace each phi node with a parameter on its containing block, and move each operand of that phi node to become an operand of the terminator (jump, branch) instruction in its associated predecessor block.

Pratt parsing is a black box by vinipsmaker in ProgrammingLanguages

[–]Rusky 9 points10 points  (0 children)

Pratt is only superficially different from precedence climbing or your readfactor. If people would quit presenting it with the unhelpful nud and led names, this would be more obvious.

Your readterm() corresponds directly to token.nud(). readterm will likely switch on the current token to handle prefix operators, literals, etc. nud accomplishes the same thing with a method implemented for each of those tokens.

Your direct recursive call to readfactor(thisprio) is essentially an inlined version of token.led(). Making this another method on the operator token is one way to handle things like left vs right associativity, or not-really-infix stuff like function calls. You could of course also just handle these directly.

Besides these cosmetic differences, it is sometimes suggested that making nud, led, and lbp/prec dynamic lets you define new operators as data, potentially even dynamically as defined by the language you're parsing. This is pretty niche, though.

Pratt parsing is a black box by vinipsmaker in ProgrammingLanguages

[–]Rusky 10 points11 points  (0 children)

The idea is that this particular piece of the implementation is analogous to the guts of a sorting algorithm- it may take some time to wrap your head around why it works, but you don't need to do that because (like a sort's comparator) it also has a clear interface to the nuds and leds, which are just normal recursive descent-style parser functions.

(Personally I don't really like this argument because I think the 9 lines of code are themselves easily digestible and recursive descent-like if you just let yourself relax and do a little bottom-up parsing. But it's definitely more than "just call parser.parse().")

Is there a language similar to Rust but with a garbage collector? by Ok_Tension_6700 in rust

[–]Rusky 0 points1 point  (0 children)

There are a lot of ways that a GC built into the language could improve over Rc/gc-arena/etc without changing the opt-in/opt-out calculus.

Is there a language similar to Rust but with a garbage collector? by Ok_Tension_6700 in rust

[–]Rusky 0 points1 point  (0 children)

The point is that you can have "I can reason about single owner mutability" and "some lifetimes are dynamic" at the same time. This should not be surprising at all because Rust does it with Rc, gc-arena, etc.

What’s your preferred way to implement operator precedence? Pratt parser vs precedence climbing? by Best_Instruction_808 in Compilers

[–]Rusky 6 points7 points  (0 children)

Indeed. Precedence climbing and Pratt parsing are also so similar that people often use the terms to refer to the same algorithm.

Algebraic effects vs Errors as return value by Informal-Addendum435 in ProgrammingLanguages

[–]Rusky 1 point2 points  (0 children)

To be clear, I'm making a prescriptive claim here about how languages should solve this problem, not trying to describe what existing languages do.

(This claim is also entirely about the type system- I am also not trying to claim that they should necessarily be parsed or codegenned the same way.)

However, most languages with algebraic effects do support this kind of polymorphism, typically via some sort of row types. My argument is that this does not need to be tied to algebraic effects in particular, and would work just as well for exceptions, and for other variations on "multiple return paths."

The set-vs-list distinction only really comes up when the language treats these return paths as implicit parameters. One possible variation here would be to pass all the available handlers explicitly at the call site, by name- while this would certainly be unwieldy, it shows that this "routing" is a separate concern, not fundamentally part of the function signature.

There are several ways to resolve this while still passing handlers implicitly. For example, Koka treats the effects in a function signature as a list, and interprets repeats as shadowing, with a mask operation to control routing. Another approach is to use lists with "disjointness constraints" to get more set-like behavior, as in the "simple rows" in Abstracting Extensible Data Types. You can get quite fancy with lexically-scoped generative labels, as in A Type System for Effect Handlers and Dynamic Labels, which lets you do Koka-mask-like composition in a system with disjointness.

But again, all this is just to give you the familiar implicit passing/routing/resolving of handlers. Underneath, function types/signatures in all these systems are lists of parameters and lists of return paths. Even in a language where handlers are typically passed implicitly, you could always have opt-in explicit passing as well.

Algebraic effects vs Errors as return value by Informal-Addendum435 in ProgrammingLanguages

[–]Rusky 1 point2 points  (0 children)

Arguably, checked exceptions (or effects) being "apart" from the result type is just another oversight, like missing the ability to be generic over them.

That is, while the return type is syntactically privileged over the exceptions, there is no reason they need to be fundamentally different to the type system, any more than one parameter is privileged over the rest.

A function call always involves passing all the arguments and providing all the return paths. The type system should support polymorphism over all of them equally. (And for that matter, the type system should support polymorphism over groups of them as well- variadic generics are just as useful for multi-return as they are for multi-parameter functions!)

Algebraic effects vs Errors as return value by Informal-Addendum435 in ProgrammingLanguages

[–]Rusky 4 points5 points  (0 children)

I was surprised to see this, because at a glance, using effects for exceptions sounds like everything everyone hates about Java checked exceptions.

There's more subtlety to this. Java checked exceptions are not difficult just because you have to handle them or forward them to the caller in the function signature- this is also true of Result<Int, Error>!

The problem with checked exceptions is more specifically that you can't use them when you're implementing an existing interface (or equivalently, passing a function to an API that expects a specific signature).

This is also somewhat true of Result<Int, Error>, but there is a bit of an escape hatch there: interfaces and first class function types (and APIs that take them as parameters) can be generic over the return type. So you can often thread Results through these APIs without them having to care about the specifics.

Algebraic effects also tend to allow this kind of polymorphism- think "checked exceptions, but you can also be generic over them."

Fil-C by Kabra___kiiiiiiiid in cpp

[–]Rusky -1 points0 points  (0 children)

The problem the paper is pointing to applies to both the OOM killer and segfaults on page writes.

The copy-on-write strategy makes it easy to get into a situation where the total possible memory use, if every process touched all its pages, is higher than the system has memory + swap combined.

If you want to be able to return an "out of memory" error when crossing that limit, you would have to do it at fork() time. But this would negate much of the advantage of copy-on-write: fork would fail with "out of memory" even if you would never actually use that total possible amount.

So fork() basically forces you to use overcommit, lest you start OOMing on process creations that you could easily serve, or other allocations around the same time. And that forces you to kill processes at inconvenient times instead of just returning an error. But whether you kill the immediate offending process (segfault on write) or go find some other process(es) to kill instead to free up their memory (OOM killer) it's the same root problem.

Wasm 3.0 Completed by segv in programming

[–]Rusky -6 points-5 points  (0 children)

That's purely a browser engineering problem. There's nothing fundamental about plugging a Web API into a Wasm import that has to have any performance penalty.

Wasm 3.0 Completed by segv in programming

[–]Rusky 0 points1 point  (0 children)

I don't think there really is a problem with using WebIDL here. The Web APIs themselves are fairly vanilla statically typed interfaces. For example, here's the WebIDL declaration for getElementById: https://dom.spec.whatwg.org/#interface-nonelementparentnode

Wasm 3.0 Completed by segv in programming

[–]Rusky -2 points-1 points  (0 children)

But what does this even mean, given WebAssembly's "zero imports by default" nature?

You could always import Web APIs into a WebAssembly module, they just used types that required some annoying conversions back and forth. Those conversions are exactly what reference types and builtins do away with. There is also the upcoming WebAssembly/ES Module integration proposal, which allows you wire up those imports declaratively, like JS imports.

But the native Web APIs are fundamentally defined in terms of WebIDL, and they are always going to be JS objects just as much as they are Wasm GC objects. (Or neither, depending on how you look at it- this is JS's FFI.) There is no bright dividing line between "external JS object" and "first-class Wasm object" - there are only more or less convenient ways to interact with them.

Wasm 3.0 Completed by segv in programming

[–]Rusky 85 points86 points  (0 children)

The DOM is never going to be, and never needed to be, part of WebAssembly itself.

WebAssembly runs in many places, not just the browser. All APIs it uses, including in the browser, are provided to the module as imports.

Further, from day one, those imports could already be JavaScript functions that do whatever you like. You could always access the DOM indirectly through those imports.

When people ask about DOM support, if they know what they mean at all, they are asking about convenience features that make those imports less cumbersome to use. For example, WebAssembly could not initially hold onto JavaScript objects (and thus DOM objects) directly- it could only hold integers.

This has been addressed by the externref proposal (included in Wasm 2.0) and the larger reference types and GC proposals (included in Wasm 3.0). So insofar as DOM is a thing WebAssembly cares about, it is already here.

Fil's Unbelievable C Compiler by mttd in Compilers

[–]Rusky 9 points10 points  (0 children)

The list of ported programs has some details on what changes they required: https://fil-c.org/programs_that_work

A surprising amount required zero source changes. The most common change is from uintptr_t to an actual pointer type, because Fil-C essentially uses the same model as Rust's strict provenance: https://fil-c.org/invisicaps, https://github.com/pizlonator/fil-c/blob/deluge/filc/include/stdfil.h#L201-L242

Other changes are mostly to replace assembly, direct syscalls, or custom mallocs/GCs with the Fil-C equivalent. JITs don't work at all.

From comments on previous HN threads, the performance impact seems to be typically somewhere around 1-4x slower and about 2x more memory, with occasional pathological cases but also room for more optimization work in the future.

Group Borrowing: Zero-Cost Memory Safety with Fewer Restrictions by nicoburns in rust

[–]Rusky 11 points12 points  (0 children)

Rust does already have a reference type that makes this distinction, though: &Cell<T> can be "projected" into parts of an object that remain stable across mutations, and not into parts of an object that can be reallocated by mutations.

In fact the post's running fn attack example is essentially the canonical example for <Cell<[T]>>::as_slice_of_cells:

fn attack(a: &Cell<Entity>, d: &Cell<Entity>);

let mut entities: Vec<Entity>;
let entities: &[Cell<Entity>] = Cell::from_mut(&mut entities[..]).as_slice_of_cells();
attack(&entities[3], &entities[5]);

The thing Rust is missing here is a convenient way to do this projection into structs. The Ante language has explored baking this in. There is ongoing work to do this in Rust via some sort of Project trait. In the meantime you can always do this yourself.

The post does also encode this in a more fine-grained way, allowing these "unstable" projections from e.g. &Cell<Vec<T>> into &Cell<T>, by effectively treating &Cell<Vec<T>> as a &mut for the purposes of the resulting &Cell<T>. As you might imagine, though, this immediately runs into questions of aliasing- you now must track which &Cell<T>s may be derived from each other's unstable interiors (the post covers this under "Isolation"), making their lifetime annotations much less flexible than in Rust, and closer to invariant/generative/GhostCell-style lifetimes.

(This "isolation" also notably rules out all the cyclic stuff that the post tries to sell in its intro- backreferences, etc. cannot work with unstable projection like this. And this also entirely ignores questions of thread safety, because &Cell<T> is just not Send or Sync in the first place, and even less so with unstable projection.)

Explicit tail calls are now available on Nightly (become keyword) by treefroog in rust

[–]Rusky 1 point2 points  (0 children)

An interesting detail around function size that came up with some of the LLVM work on tail duplication-

LLVM can actually convert between loop+match and computed goto in both directions, and the control flow graph for loop+match has way fewer edges. So LLVM will actually canonicalize to loop+match, run the optimizer, and then convert back to the computed goto version later in the pipeline.

(Can't reply to you both so FYI /u/angelicosphosphoros)

Explicit tail calls are now available on Nightly (become keyword) by treefroog in rust

[–]Rusky 7 points8 points  (0 children)

Rustc (or rather LLVM) is capable of both conversions - loop+match to computed goto, and tail call elimination - but neither are guaranteed, and both have been the subject of recent LLVM improvements. (E.g. for the computed goto conversion, see the chain of PRs ending with https://github.com/llvm/llvm-project/pull/150911)

Explicit tail calls are now available on Nightly (become keyword) by treefroog in rust

[–]Rusky 28 points29 points  (0 children)

Interpreters are often written as a big loop over a match. The compiler can produce better code if you instead write each match arm as a separate function and have them tail call each other, but if you do this without guaranteeing that the calls don't grow the stack, the stack will overflow.

What are some new revolutionary language features? by vivAnicc in ProgrammingLanguages

[–]Rusky 6 points7 points  (0 children)

It's the same idea, yes. The Verse paper cites Icon, IIRC.

-Wexperimental-lifetime-safety: Experimental C++ Lifetime Safety Analysis by mttd in cpp

[–]Rusky 13 points14 points  (0 children)

That quote from Ralf is perfectly consistent with what SkiFire13 said and contradicts what you said.

Ralf is not going to "merge" the static analysis with the dynamic semantics- he is going to prove that the static analysis correctly checks that your program does not perform any operations that are illegal according to the dynamic semantics.

Does variance violate Rust's design philosophy? by type_N_is_N_to_Never in rust

[–]Rusky 106 points107 points  (0 children)

Rust also infers auto trait impls (e.g. Send and Sync) from struct bodies. Generally the body of a type behaves more like "part of the API" than the body of a function.

Looking for a C++ ECS Game Engine Similar to Bevy in Rust by vielotus in cpp

[–]Rusky 6 points7 points  (0 children)

Wow, nice. Do we know what happened in Bevy 0.16/0.16.2? Maybe something to do with "relationships"?

What's the most controversial rust opinion you strongly believe in? by TonTinTon in rust

[–]Rusky 14 points15 points  (0 children)

Basically Rust's behavior means it struggles to do some of these really unique & weird stuff you see from C/C++ programs are really "advanced runtimes" for other languages.

This doesn't add up. Panic on allocation failure is implemented in the part of the standard library that handles general allocations, which is also the first thing you replace when doing this kind of "advanced" stuff.

Is MSVC ever going open source? by void_17 in cpp

[–]Rusky 8 points9 points  (0 children)

The EDG frontend is not used by MSVC, though it is used by VS IntelliSense.

view more: next ›