4 ms·
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 no
by 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 agoWhen 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 agoCall/cc is not very composeable.
- tsimionescu 7y agoWell, 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 agoDepending on what you want from this, you can maybe use dynamic-wind. But yeah.