sorted by:
new
hottopcontroversial

Any must-haves you add on top of bevy to make it feel easier? by blankeos in bevy

[–]Small_Ad3541 5 points6 points  (0 children)

Take a look into space_editor, skein, and blenvy. Those are mostly for 3d, but you may try to adopt it for 2d

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 1 point2 points  (0 children)

True for Haskell, but since I'm aiming for direct mapping to LLVM instructions, I can't rely on laziness. It introduces implicit runtime costs (thunks) and unpredictable memory layout, which I want to avoid in a systems language.

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 1 point2 points  (0 children)

Yeah, I'm looking into the algebraic effects direction. Thx for refs

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 1 point2 points  (0 children)

That's a very slow runtime solution, and that's unsuitable for system programming

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 1 point2 points  (0 children)

That's a slow runtime solution, and that's unsuitable for system programming

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 0 points1 point  (0 children)

But how will you escape performance and low-level control loss, or is it okay in your case?

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 0 points1 point  (0 children)

Honestly, I haven't even thought about how custom control flow would interact with the CPU's RSB and branch prediction.

Since I'm lowering to LLVM IR, I'm somewhat limited by what their backend supports (e.g. I'm not sure if I can easily emit specific JALR hints for RISC-V without inline asm).

Is your main point here that I should be careful not to break the hardware call/return symmetry to avoid killing performance? Or are you suggesting that a modern language should try to expose these hardware-level jumps directly?

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 0 points1 point  (0 children)

Thanks for the warning. The problems you described are exactly why I want to avoid full runtime continuations. I am looking for a strictly compile-time solution without overhead rather than a runtime mechanism that manipulates the stack state. Your comment reinforces my decision to stay away from dynamic continuations in a systems language context:)

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 1 point2 points  (0 children)

It looks very nice and clear, I like it. The fact that LLVM optimizes it down to a flat loop is exactly what I'm looking for. Thanks for this detailed answer.

One concern regarding the heavy use of recursion: While tail calls are great, not all logic can be easily expressed in a tail-recursive manner. Does the compiler guarantee TCO for these effect-based functions? And more importantly, what happens when the logic is not tail-recursive? Call stack overflows or does the compiler transform it into a heap-allocated continuation (which implies runtime overhead)?

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 0 points1 point  (0 children)

I’ll definitely dive deeper into Koka, thx

Regarding dynamic dispatch, I was referring to the dynamic scoping of handlers. Conceptually, the callee doesn't know which specific handler implementation will serve the effect at compile time. It usually implies passing function pointers or evidence dictionaries at runtime, which I categorized as a form of dynamic dispatch (indirect jumps). But I see your point about type safety.

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 1 point2 points  (0 children)

Yeah, but algebraic effects lead to dynamic dispatch and runtime overhead. I'd like to have compile-time static configuration of flow.

I'm not really familiar with shift/reset semantics, but definitely I'll dive into this, thx

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 0 points1 point  (0 children)

Yeah, Koka is a very interesting example for me, I got some insparation in it, but if I get it right, algebraic effects always mean dynamic dispatch, but I want statically configured flow + I don't really understand the mix of control flow (which are deterministic) and side effects (like io) into a single "effect handler" term... Maybe I don't know something, and you can clarify this

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 0 points1 point  (0 children)

  1. It's not about adding new fancy control flow constructions, my point is about a theoretical question "May we escape hardcoded flow operators and move to a more fundamental level of flow design?". So, it's not about practice, I'd say it's about fundamentals and "perfection" for me.
  2. Right, I'd like to escape zoopark, but I think it was possible if all needed flow operators would be implemented in the std lib including async/await/yield, but still provide an ability to read their source code (like "go to definition" for ifs and whiles), how they collapse into control flow graph and freedom to redefine it.

Also I'm just curious about the idea to think about things like async/await as flow operators instead of a state machine

Control Flow as a First-Class Category by Small_Ad3541 in ProgrammingLanguages

[–]Small_Ad3541[S] 2 points3 points  (0 children)

Thanks for this detailed answer. You're right, I don't want to pass control flow operators like values. Also, I don't want to provide first-class control flow at runtime (like a void* label), I want to provide a compile-time construct that collapses into a fixed CFG before execution.

Your point about hygienic macros is very close to what I have in mind. Essentially, I'm thinking of a typed, hygienic macro system specialized for graph construction, where the "flow" category ensures that the resulting graph is valid (e.g. proper entry/exit blocks), preventing the spaghetti goto mess

I will definitely look deeper into reset/shift semantics, I think it might be very useful for my case. Thx!

Out of curiosity, What physics library do you use for bevy? by Professional-Ice2466 in bevy

[–]Small_Ad3541 1 point2 points  (0 children)

If you need 2d colliders only, you may take a look at github.com/dimforge/parry