4 ms·

A description of one thing you can do with this is at https://github.com/moonjit/moonjit/issues/84 https://github.com/moonjit/moonjit/issues/84 It's not a comm

A description of one thing you can do with this is at https://github.com/moonjit/moonjit/issues/84 https://github.com/moonjit/moonjit/issues/84 It's not a common feature. Usually it's present in a language that has "continuations" and the api is something dreadful like call/cc. But you can use it in Lua with the above mentioned patch, and you can use it in byuu/co with memcpy.

simias 7y ago
I object to the use of "dreadful" for call/cc, it's just a different paradigm that requires a different way of thinking but it's not a bad thing per-se. It's not like goto or setjmp which are fundamentally unsound constructs that completely break the flow of the program.
- anonymoushn 7y ago
  When designing these primitives, I think there are a few considerations: When creating a new execution context, which one should begin executing, and which one should be bound to a local variable in the executing one? Should there be any primitive that switches to an already-existing execution context without creating a copy of it? How many primitives should there be? call/cc answers: "The new execution context should begin executing and the old one should be bound to a local variable, no, one" As a person who occasionally explains these things to people who have never been exposed to them, I strongly prefer: "The old execution context should continue executing and the new one should be bound to a local variable, yes, as many as we need to produce the preceding answers" I think without trying too hard you can get the number of primitives in the latter case down to three, "create", "copy", and "switch." If you wanted to bug your users you could get it down to two.
- wbl 7y ago
  Call/cc is not very composeable.
- tsimionescu 7y ago
  Well, call/cc usually makes it impossible to add a construct like 'finally' to a language, so it does at least block some options.
  - anonymoushn 7y ago
    Depending on what you want from this, you can maybe use dynamic-wind. But yeah.

simias 7y ago

I object to the use of "dreadful" for call/cc, it's just a different paradigm that requires a different way of thinking but it's not a bad thing per-se. It's not like goto or setjmp which are fundamentally unsound constructs that completely break the flow of the program.

anonymoushn 7y ago
When designing these primitives, I think there are a few considerations: When creating a new execution context, which one should begin executing, and which one should be bound to a local variable in the executing one? Should there be any primitive that switches to an already-existing execution context without creating a copy of it? How many primitives should there be? call/cc answers: "The new execution context should begin executing and the old one should be bound to a local variable, no, one" As a person who occasionally explains these things to people who have never been exposed to them, I strongly prefer: "The old execution context should continue executing and the new one should be bound to a local variable, yes, as many as we need to produce the preceding answers" I think without trying too hard you can get the number of primitives in the latter case down to three, "create", "copy", and "switch." If you wanted to bug your users you could get it down to two.
wbl 7y ago
Call/cc is not very composeable.
tsimionescu 7y ago
Well, call/cc usually makes it impossible to add a construct like 'finally' to a language, so it does at least block some options.
- anonymoushn 7y ago
  Depending on what you want from this, you can maybe use dynamic-wind. But yeah.