[bitc-dev] Call by need?

[wren ng thornton]

On 9/9/10 7:30 PM, Raoul Duke wrote:
> On Fri, Sep 3, 2010 at 9:39 PM, wren ng thornton<wren at freegeek.org>  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