Date: 2013-04-18 11:49 pm (UTC)
winterkoninkje: shadowcrane (clean) (Default)
I also believe that effects can be handled much more intuitively than is currently done in haskell. Every time I have to write "do x' <- x ; case x' of ..." or "f <$> g x <*> g y <*> ..." I die a little inside. I assume someone, somewhere has done research into streamlining this, perhaps by overloading function application or doing some fancy elaboration during typechecking? I haven't looked into this at all, but it seems like an obvious avenue of inquiry.

(1) The Habit language introduces new keywords if<- and case<- which do exactly what you want about getting rid of intermediate names there. I'm not sure why it's been so hard to get this backported into Haskell...

(2) The original paper on applicative functors also shows how to define "idiom brackets" which have the effect of overloading application. It's as unobtrusive as writing iI f (g x) (g y) Ii (if you name your brackets iI/Ii). With more liberal abilities to name things (à la Agda) we could use better names without even touching the language semantics. Unfortunately, in spite of the apparent desirability of idiom brackets, this style has never really caught on. As it turns out, this only covers a very small corner of the things we actually do with applicative functors, so the weight/power ratio is actually very bad.

(3) I'm unaware of any work on DWIM idiom brackets. However, I believe that the proper course of action here (as with monads before them) is not to add more special support for side effects, but rather to eliminate the special support for pure code. The main problem here is the imbalance between pure and effectful code. But given that purity is an effect —the identity monad— the only way to reconcile the imbalance, IMO, is to treat everything as effectful[1]. Ironically, the associative/chiastic lambda calculi I've been working on have this property. I've been ignoring effects so far, since they're not needed for the linguistic work, but that might be a fruitful avenue of research. Another place to look is DDC which has a first-class effect system, rather than repurposing the type system to track effects. Unfortunately, of course, having a first-class effect system means you need to bake in certain effects as part of the language (IO, memory regions,...) whereas others remain second-class (lists as nondeterminism, Maybe/Either as fallible computations,...)

[1] The deeper I look into things, the more I disbelieve in the existence of "pure" code in the first place. Whenever we write "pure" code we're ignoring the fact that the code has observable side effects like how much memory it allocates, how long it takes to run, etc. While many would discount these effects as being "benign", they are the source of some of Oleg's recent rants on the evils of unsafeInterleaveIO since the fact that these side-effects do exist means that they can be observed from any IO code which reflects on the state of the computation. And, in fact, we want to be able to perform such reflection since it means we can do things like choose between different "pure" algorithms based on the current memory pressure.

In addition to all this, ever since hearing a talk David MacQueen gave on one of the ugly parts of ML, I've come to believe that the very ability to give things names is itself an effect. This was something that had been nagging me for a while, but MacQueen's talk really drove it home. But if the very ability to give things names is indeed an effect, then "pure" code is anything but pure— at a deep level that noone has been willing to explore.
Anonymous( )Anonymous This account has disabled anonymous posting.
OpenID( )OpenID 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.
Account name:
If you don't have an account you can create one now.
HTML doesn't work in the subject.


Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.



April 2013

14151617 181920

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 28th, 2017 05:43 pm
Powered by Dreamwidth Studios