syntax...(strings/interpolation/here docs)

Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Wed, 20 Feb 2002 17:48:53 +1100


Ian Zimmerman <itz@speakeasy.org> wrote,

> Mark> Ultimately, it comes down to a question of what you're trying to
> Mark> achieve.  Do you envisage Haskell as an elegant scripting
> Mark> language that competes with perl and ruby for quick but useful
> Mark> hacks?  Or do you think it might better serve as a platform for
> Mark> writing significant user level applications with fancy user
> Mark> interfaces and international appeal?
> 
> Neither.
> 
> The chief advantage of functional languages is supposed to be their
> clean semantics with straightforward formalization, which allows one
> to be confident in the correctness of relatively large and complex
> bodies of code.  That advantage is forfeited when trying to interface
> directly to messy GUI toolkits (and _all_ GUI toolkits in existence
> are messy).

I don't agree.  The clean semantics of FP languages has led
to language features that are very useful, especially in
messy contexts.

I have myself written many thousand lines of what I like to
call "C in Haskell syntax", much of this as part of the
Haskell binding to the GTK+ GUI toolkit.  This code uses
pointers, side-effects, calls to C routines as well as
explicit memory allocation and deallocation all over the
place.

Do I think Haskell is suited for writing such code?  Yes,
definitely.  As long as you don't need close control over
your memory and runtime consumption (like in an OS kernel),
I would say, Haskell is the better C.[1]

Haskell's type system and excellent support for higher-order
functions in combination with the facilities for data
structures (pattern matching etc) make it a powerful tool
for everybody who knows to use these features.  For example,
if you use suitable types for your functions (eg,
parametrised pointers), the type checker will still pick up
many more mistakes than that of an imperative language.

Cheers,
Manuel

[1] And mind you, I have programmed much more code in
    imperative than in functional languages.