Conversation

Notices

1. Embed this notice
   Eniko Fox (eniko@mastodon.gamedev.place)'s status on Monday, 07-Jul-2025 00:20:04 JST Eniko Fox

   i love code generation

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 07-Jul-2025 00:19:56 JST ✧✦Catherine✦✧

     in reply to

     • ROTOPE~1 :yell:
     • Björkus "No time_t to Die" Dorkus

     @thephd @eniko @rotopenguin hey wanna learn an upsetting fact

     ocaml did the same thing... but worse. the bytecode compiler and the native compiler for the same platform have the order of arguments reversed

   • Embed this notice
     Björkus "No time_t to Die" Dorkus (thephd@pony.social)'s status on Monday, 07-Jul-2025 00:19:59 JST Björkus "No time_t to Die" Dorkus

     in reply to

     • ROTOPE~1 :yell:

     @eniko @rotopenguin that's a theoretical thing, and when someone investigated it turned out the perf hit was largely made up.

   • Embed this notice
     ROTOPE~1 :yell: (rotopenguin@mastodon.social)'s status on Monday, 07-Jul-2025 00:20:01 JST ROTOPE~1 :yell:

     in reply to

     @eniko but what if a relay-and-thermionic-emission-drum computer from 1952 needs that behaviour?

   • Embed this notice
     Eniko Fox (eniko@mastodon.gamedev.place)'s status on Monday, 07-Jul-2025 00:20:01 JST Eniko Fox

     in reply to

     • ROTOPE~1 :yell:

     @rotopenguin i dont think its even a compatibility thing iirc the justification is "we can emit better machine code if we can arbitrarily reorder operands" and like yeah cool how about we take that small perf hit instead thanks

   • Embed this notice
     Eniko Fox (eniko@mastodon.gamedev.place)'s status on Monday, 07-Jul-2025 00:20:02 JST Eniko Fox

     in reply to

     oh right and

     3. C wasn't just like "¯\_(ツ)_/¯" when asked what the evaluation order of operands is

   • Embed this notice
     Eniko Fox (eniko@mastodon.gamedev.place)'s status on Monday, 07-Jul-2025 00:20:03 JST Eniko Fox

     in reply to

     this wouldn't be such a problem if
     1. C didn't have side effects all over the place
     2. C statement expressions were universally supported

   • Embed this notice
     ROTOPE~1 :yell: (rotopenguin@mastodon.social)'s status on Monday, 07-Jul-2025 00:24:19 JST ROTOPE~1 :yell:

     in reply to

     • ✧✦Catherine✦✧
     • Björkus "No time_t to Die" Dorkus

     @whitequark @thephd @eniko there must be some optimally-cursed design that has operator precedence in some shit like "LFSR order", because it saved two valves in a prototype (which was subsequently destroyed by a guy dropping a firebomb out of a Sopwith Camel).

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 07-Jul-2025 00:26:32 JST ✧✦Catherine✦✧

     in reply to

     • ROTOPE~1 :yell:
     • Björkus "No time_t to Die" Dorkus

     @rotopenguin @thephd @eniko i don't even think the ocaml thing is because it's faster. back when it was decided the compiler was _definitely_ not smart enough to exploit it, and i doubt it is today

     no, i think it's because it's marginally easier to write codegen for? and i guess it keeps people on their toes. you know, makes ur code more functional

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 07-Jul-2025 00:42:36 JST ✧✦Catherine✦✧

     in reply to

     • ROTOPE~1 :yell:
     • Björkus "No time_t to Die" Dorkus
     • Alice

     @prophet @thephd @eniko @rotopenguin I was unaware of this detail! I will admit that it's very slightly more reasonable

   • Embed this notice
     Alice (prophet@functional.cafe)'s status on Monday, 07-Jul-2025 00:42:37 JST Alice

     in reply to

     • ROTOPE~1 :yell:
     • ✧✦Catherine✦✧
     • Björkus "No time_t to Die" Dorkus

     @whitequark @thephd @eniko @rotopenguin it's (slightly) more reasonable because of their way of compiling curried functions (push/enter) though, isn't it?

     at least, that's how the ZINC paper justifies it (section 2.2.3): https://inria.hal.science/inria-00070049/document

   • Embed this notice
     Andy Wingo (wingo@mastodon.social)'s status on Monday, 07-Jul-2025 03:43:16 JST Andy Wingo

     in reply to

     • ROTOPE~1 :yell:
     • ✧✦Catherine✦✧
     • Björkus "No time_t to Die" Dorkus
     • Alice

     @whitequark @prophet @thephd @eniko @rotopenguin very slightly ;) since you can just expand the set of ordering terms to include operator and operands, unspecified order gains you only this dubious optimization at the cost of introducing ambiguous semantics for a class of programs.

     racket went for specifying left-right eval order and i think it was the right thing