Is it just me or do the first few examples seem worse than doing the same things without effects?
I can have a function fail by having it invoke an “exception” effect that doesn’t continue it. Or I can return a result and have that result contain the failure. If I use effects, I need to thread the effect through the call tree. (The effect has one nice property that a stack trace may be available, but this has runtime cost.)
If I’m writing a generator, then I can express it with effects, but it’s not immediately obvious to me that the resulting in-progress generation can be captured as a first-class value, whereas a conventional Iterable can, even in languages like Rust without a heavy runtime. (Maybe it’s in the article.)
And effects that continue twice are gross. Okay, there are cases where a continuation wants to be continued more than once and that a full-powered continuation should be used instead of a some more restrictive at-most-once or exactly-once scheme, but the function being continued really needs to be prepared for it, and the compiler cannot generate decent code without knowing how many times something can return. And I don’t see anything in the declaration of effects that gives any bounds on number of times that something can be continued.
I feel the author’s pain. LLMs take over right as we’re finally figuring out the unifying models and algorithms for programming languages.
Some time back I went on a tour of the fort at Dry Tortugas. Largest brick masonry fort in the world. Many innovations of the form. It was abandoned right as it was completed because barrel rifling had just been invented, dramatically increasing the penetrating power of artillery, rendering brick masonry forts obsolete virtually overnight.
I can have a function fail by having it invoke an “exception” effect that doesn’t continue it. Or I can return a result and have that result contain the failure. If I use effects, I need to thread the effect through the call tree. (The effect has one nice property that a stack trace may be available, but this has runtime cost.)
If I’m writing a generator, then I can express it with effects, but it’s not immediately obvious to me that the resulting in-progress generation can be captured as a first-class value, whereas a conventional Iterable can, even in languages like Rust without a heavy runtime. (Maybe it’s in the article.)
And effects that continue twice are gross. Okay, there are cases where a continuation wants to be continued more than once and that a full-powered continuation should be used instead of a some more restrictive at-most-once or exactly-once scheme, but the function being continued really needs to be prepared for it, and the compiler cannot generate decent code without knowing how many times something can return. And I don’t see anything in the declaration of effects that gives any bounds on number of times that something can be continued.
reply