Create a Dreamwidth Account
Site and Account
Reload page in style:
2013-04-19 12:06 am (UTC)
I'm quite against your proposed way of handling state, for the same reasons I'm against ML doing things that way. For one, the types
() -> T
should always be isomorphic IMO. The only thing I'd even consider allowing to break the isomorphism is if eta fails for functions due to nontermination, as it does in Haskell, meaning that you get an extra bottom in the latter. But even that is something I think should be fixed (e.g., by actively distinguishing pointed CPOs and unpointed CPOs).
For two, one of the big problems with code like this is the exact same problem you run into in imperative languages. Failing to distinguish the side-effecting nature of reading/writing to mutables leads to all sorts of ugliness that breaks equational reasoning. This is part of the reason why coding in C is so ugly. And in order to clean that ugliness up, we already have to explicitly decompose things in order to store intermediate results in local variables; so why not just require it up front as Haskell's reader/writer/state monads do? It'd be good to make the "syntax" more lightweight than it is currently —especially re introducing spurious intermediate names— but not, IMO, by sacrificing the explicitness of those effects nor by muddying the waters with lvalues vs rvalues.
Thread from start
This account has disabled anonymous posting.
You can comment on this post while signed in with an account from many other sites, once you have confirmed your email address.
Sign in using OpenID
If you don't have an account you can
create one now
HTML doesn't work in the subject.
Check spelling during preview
This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.
Expand Cut Tags
No cut tags
Page generated Jun. 28th, 2017 05:43 pm
Top of page