On 9/9/10 7:30 PM, Raoul Duke wrote: > On Fri, Sep 3, 2010 at 9:39 PM, wren ng thornton<[email protected]> wrote: >> Indeed. This is often advocated as one of the reasons for >> lazy-by-default in Haskell. Laziness allows you to implement most >> control structures directly in the language, rather than having them as >> built-ins: short-circuiting boolean ops, if-then-else, do-while,... > > i'm probably confused. couldn't you also do that if you instead had a > way to mark something as lazy?
For the most part, yes. Though that also introduces problems. In particular, if you have strict by default with annotated laziness, then people will underutilize laziness which means you'll miss out on a lot of the compositionality that laziness provides. They'll avoid it partly due to social stigma for using "complex features" of the language, and partly due to, er, laziness. There are also certain patterns of using laziness that become extremely painful to use when you have to add explicit annotations everywhere; and hence, they would not have been developed in strict-by-default languages and would only be ported in by "outsiders" coming from a lazy-by-default language. These outsiders will face the same sort of stigma as people who advocate using functional style in imperative languages or extensive use of design patterns in OO languages (when they're appropriate). It's the Black Sheep principle of language design: if you make your syntax tell you something is abnormal, then people will treat it as abnormal. > short-circuiting boolean ops in > scheme/lisp don't have to be "built-ins", can be macros, no? they are > in the Clojure sources, anyway. (just thinking of arguments i've heard > for /not/ having laziness be the default - mainly that it can be a > stretch for mere humans to follow the performance implications.) so > your 2nd sentence doesn't seem to bolster the 1st iiuc. Meh. As a practicing Haskeller, my experience is that the performance characteristics aren't nearly as arcane as newcomers make them out to be. The reason, IMHO, that people complain about performance reasoning is that you *do* need to stop and take a second to think, whereas in mainstream languages you aren't generally trained to think about performance (beyond some trivialities). The reason you have to stop and think is because you do get non-compositional behavior[1], but that doesn't mean you get unpredictable behavior that can't be reasoned about; it just means you have to stop and do the reasoning. Once you've been made aware of the major potholes, it's easy to develop a coding style that incorporates these rules of thumb and thus alleviates the need to actually think about them. It's more about learning how to think and what to look for than it is about the topic being inscrutable. [1] Particularly when you have many layers of higher-order functions interacting. Traditional mainstream languages don't have the same kind of layering of HOFs, and so it isn't clear that they *don't* have similar reasoning difficulties; they've just been avoiding the hard problems. On the other hand Haskell encourages the rampant use of HOFs, which throws you into worrying about things a lot sooner. -- Live well, ~wren _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
