Closed miniBill closed 1 year ago
Oh man, this dents my hopes. I'll keep the code as it is, but will remove the claim that this code will induce a bottom.
Short of an invasive surgery, have you a suggestion that I might pursue to induce a bottom, at least for the immediate future? Perhaps disable the TCO?
Thank you for pointing out something I didn't know. Cheers!
On Tue, 22 Aug 2023 at 13:36, Leonardo Taglialegne @.***> wrote:
This is not as issue per se, because impossible cases are... well, impossible.
But when you do something like
ins x y = case x of E -> ins x y T _ -> ...
The compiler will do Tail Call Optimization on it, so it will not actually crash with a stack overflow, but rather wedge the browser tab, which is unfortunate, especially because it won't give you a "nice" stack trace like a stack overflow would
— Reply to this email directly, view it on GitHub https://github.com/amenzwa/pfd/issues/2, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN2PC2P36RBFK2C7PEL4XDXWTUYHANCNFSM6AAAAAA32IPFNU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I think the simplest thing is to do something like identity (ins x y)
. This will not be TCOd, so it will "correctly" explode.
Alternatively, TCO is only applied if the function calls itself, so you could have two functions recursively calling each other as an explosion.
Example of loop vs explosions (you can inspect the right frame and look at the generated JS, it's relatively readable if you search for the function names) https://ellie-app.com/nJq6fSJpwDra1
Alternatively-alternatively... if you're sure the case is never reached, how about returning the wrong result? Like, just return empty
from ins
. It will typecheck, and it's not reachable anyway.
Alternatively-alternatively-alternatively, sometimes it's possible to change the datatypes such that impossible states are outside the values, but I guess it's not possible here.
Much obliged. I was just typing a question on whether a spurious double recursion might circumvent TCO. But I like your elegant id call solution.
I'm currently using elm-test at the console. I'll follow your advice of testing in the browser debugger.
Thanks so much for your guidance.
On Tue, 22 Aug 2023 at 13:55, Leonardo Taglialegne @.***> wrote:
I think the simplest thing is to do something like identity (ins x y). This will not be TCOd, so it will "correctly" explode.
Alternatively, TCO is only applied if the function calls itself, so you could have two functions recursively calling each other as an explosion.
Example of loop vs explosions (you can inspect the right frame and look at the generated JS, it's relatively readable if you search for the function names) https://ellie-app.com/nJq6fSJpwDra1
— Reply to this email directly, view it on GitHub https://github.com/amenzwa/pfd/issues/2#issuecomment-1688657718, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN2PCZDXKK5XMZ625HNYYDXWTXAVANCNFSM6AAAAAA32IPFNU . You are receiving this because you commented.Message ID: @.***>
In the pre-init-commit version, I used the Error return. But this propagates the Error all the way up the chain, and my code diverged significantly from Okasaki's original implementation. Since the intent of this project is to expose CS undergrads to Elm and Okasaki, I opted to stick to the book, thereby making it easier for the intended audience to trace the code back to its origin. Likewise, if I return empty, it would alter the semantics of some functions. I've injected the id calls, as per your suggestion. Thank you!
Leonardo, with your concurrence, I'd like to close this issue. I've already prefixed identity
to the $\bot$ calls, as per your suggestion.
This is not as issue per se, because impossible cases are... well, impossible.
But when you do something like
The compiler will do Tail Call Optimization on it, so it will not actually crash with a stack overflow, but rather wedge the browser tab, which is unfortunate, especially because it won't give you a "nice" stack trace like a stack overflow would