Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

There's no valid direct technical reason other than financial resource constraints to justify compiling to C (... or JS, for that matter) instead of a more suitable and expressive IR/bytecode.

How does one do call/cc in LLVM, or delimited continuations, for that matter?



The same way you'd do it in any runtime? Adopt an adequate representation model of the machine state, and save that state.


Why would I save "a representaion model" when I can simply save the process/thread state?


You can't do that in portable C as-is. Watch what happens when you try to restore thread state on a different system thread using an OS that instrisically ties system threads to user threads to thread local variables to the stack.

And no, getcontext() and setcontext() aren't portable.


Why would I care if it's portable or not? I've never understood the mentality of "but it's not portable". If something isn't not portable, you put #+ and #- on top of it. I'd rather go for "straight-forward and performant" than for some abstract code transformations to make it runnable on platforms that almost nobody uses to the detriment of everyone else.

LLVM is the lowest common denominator. I'm really not fond of lowest common denominators. (Not to mention the fact that it's bloatware in the first place - it's about twice the size of my favourite compiler, and that's before you add the actual language you're trying to compile.)


> Why would I care if it's portable or not? ...

Because you literally cannot implement it safely or correctly from the C level on Mac OS X, and any other platform with similar thread/stack/thread-state constraints.

Unless that's a platform you think "nobody uses" ...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: