[bitc-dev] Call by need?
wren ng thornton
wren at freegeek.org
Thu Sep 9 20:15:02 PDT 2010
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
> 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, 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.
 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.
More information about the bitc-dev