On 1 apr 2008, at 13.02, Bulat Ziganshin wrote:

Hello Simon,

Tuesday, April 1, 2008, 2:18:25 PM, you wrote:

...

How can one answer the question--why choose Haskell over Scheme?

1. static typing with type inference - imho, must-be for production code development. as many haskellers said, once compiler accept your program, you may be 95% sure that it contains no bugs. just try it!

2. lazy evaluation - reduces complexity of language. in particular, all control structures are usual functions while in scheme they are macros

3. great, terse syntax. actually, the best syntax among several dozens of languages i know

4. type classes machinery, together with type inference, means that code for dealing with complex data types (say, serialization) is generated on the fly and compiled right down to machine code

3 and 4 are no convincing arguments for a Scheme programmer. Syntax is subjective and there Scheme implementations that can serialize entire continuations (closures), which is not possible in Haskell (at least not without GHC-API). Static typing, though it might sound constraining at first, can be liberating! How that? Because it allows you to let the type-checker work for you! By choosing the right types for your API, you can enforce invariants. For example you can let the type-checker ensure that inputs from a web-application are always quoted properly, before using them as output. A whole class of security problems is taken care of forever, because the compiler checks them for you. If you're used to REPL-based programming, it can be a bit annoying that you can't run non-type-checking code, but you get used to it. After a while you will miss the safety when you program in Scheme again. There's more, but I count on others to step in here.

Loup Vaillant wrote:

Thanks to some geniuses (could someone name them?), we have type classes and higher order types in Haskell (and even more).

As far as names go: ... for type classes, of course Wadler, but also Blott and Kaes. ... for higher order types, well, where to start? -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

apfelmus wrote:

Janis Voigtlaender wrote:

...

Loup Vaillant wrote:

...

Thanks to some geniuses (could someone name them?), we have type classes and higher order types in Haskell (and even more).

As far as names go:

.... for type classes, of course Wadler, but also Blott and Kaes.

.... for higher order types, well, where to start?

Girard and Reynolds?

Yes, that's the obvious suspects, of course. But I'm not sure I would say they brought polymorphism (assuming that's what is meant by "higher order types") to Haskell. Not in the same way Wadler and co. brought type classes, quite specifically, to Haskell. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

Loup Vaillant wrote:

By "higher order types", I meant the type of runST (ST monad), or dpSwich (in yampa). I meant things like "(forall a, a-> b) -> a -> b"

That's then usually called "higher-rank polymorphic types", just in case you need more keywords for literature search ;-) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

On Tue, Apr 1, 2008 at 1:02 PM, Bulat Ziganshin wrote:

Hello Simon,

Tuesday, April 1, 2008, 2:18:25 PM, you wrote:

...

How can one answer the question--why choose Haskell over Scheme?

Well as a longtime Scheme and OCaml programmer, and Haskell-cafe lurker, I'll take a stab at this...

1. static typing with type inference - imho, must-be for production code development. as many haskellers said, once compiler accept your program, you may be 95% sure that it contains no bugs. just try it!

I think this is the biggest, and most obvious, difference to consider when choosing either Scheme or Haskell over the other -- for a particular problem. Dynamic and static typing each have their advantages, depending on the context. I think it's dangerous to try to answer the question "Scheme or Haskell?" without a problem context.

2. lazy evaluation - reduces complexity of language. in particular, all control structures are usual functions while in scheme they are macros

Well, if I don't have side effects (and don't mind extra, unneeded evaluations), I can write my conditionals as functions in Scheme too. Heck, now that I think of it I can even avoid those extra evaluations and side-effect woes if i require promises for each branch of the conditional. No macros required... I think some problems are just more naturally modeled with lazy thinking, and a language with implicit support for lazy evaluation is a _huge_ win then. I written plenty of lazy Scheme, and OCaml for that matter, code where I wished and wished that it just supported lazy evaluation semantics by default. Again, I think this is highly problem dependent, though I think you win more with lazy evaluation in the long run. Do more experienced Haskellers than me have the opposite experience? I mean, do you ever find yourself forcing strict evaluation so frequently that you just wish you could switch on strict evaluation as a default for a while?

3. great, terse syntax. actually, the best syntax among several dozens of languages i know

I think this is possibly the weakest reason to choose Haskell over Scheme. Lispers like the regularity of the syntax of S-expressions, the fact that there is just one syntactic form to learn, understand, teach, and use. For myself, I find them to be exactly the right balance between terseness and expressiveness. For me, Haskell syntax can be a bit impenetrable at times unless I squint (and remember I'm also an OCaml programmer). Once you "get it," though, I agree that the brevity and expressiveness of Haskell is really beautiful.

4. type classes machinery, together with type inference, means that code for dealing with complex data types (say, serialization) is generated on the fly and compiled right down to machine code

This is obviously related to #1, and Haskell sure does provide a lot of fancy, useful machinery for manipulating types -- machinery whose functionality is tedious at best to mimic in Scheme, when even possible. In short, I think the orginal question must be asked in context. For some problems, types are just a natural way to start thinking about them. For others dynamic typing, with _judicious_ use of macros to model key aspects, is the most natural approach. For the problems that straddle the fence, I usually pick the language I am most familiar with (Scheme) if there are any time constraints on solving it, and the language I'm least familiar with (Haskell, right now) if I have some breathing room and can afford to learn something in the process. Cheers, -Andy

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, Apr 1, 2008 at 4:55 PM, Loup Vaillant wrote:

2008/4/1, Andrew Bagdanov :

...

In short, I think the orginal question must be asked in context. For some problems, types are just a natural way to start thinking about them. For others dynamic typing, with _judicious_ use of macros to model key aspects, is the most natural approach.

Do you have any example? I mean, you had to choose between Scheme and Ocaml, sometimes, right? Ocaml is not Haskell, but maybe the reasons which influenced your choices would have been similar if you knew Haskell instead of Ocaml.

Sure. This may not be the best example, but it's the most immediate one for me. I'll try to be brief and hopefully still clear... Years ago I implemented an image processing system based on algorithmic patterns of IP defined over algebraic pixel types (algebraic in the ring, field, vector space sense). Here's a link to the chapter from my dissertation, for the chronically bored: http://www.micc.unifi.it/~bagdanov/thesis/thesis_08.pdf This was partially motivated by the observation that a lot of image processing is about _types_ and about getting them _right_. There's a complex interplay between the numerical, computational and perceptual semantics of the data you need to work with. A functional programming language with strict typing and type inference seemed ideal for modeling this. You get plenty of optimizations for "free" when lifting primitive operations to work on images (except OCaml functors really let me down here), and you don't have to worry figuring out what someone means when convolving a greyscale image with a color image -- unless you've already defined an instantiation of the convolution on these types that has a meaningful interpretation. Where "meaningful" is of course up to the implementor. In retrospect, if I had it all over to do again, I might choose Scheme over OCaml specifically because of dynamic typing. Or more flexible typing, rather. To completely define a new pixel datatype it is necessary to define a flotilla of primitive operations on it (e.g. add, mul, neg, div, dot, abs, mag, ...) but for many higher-level operations, only a handful were necessary. For example, for a standard convolution, mul and add are sufficient. In cases like this, I would rather explicitly dispatch at a high level -- in a way that admits partial implementations of datatypes to still play in the system. In retro-retrospect, the structural typing of OCaml objects could probably do this pretty well too... Oh well. This is a case where the resulting system was difficult to use in the exploratory, experimental it was intended to be used, in my opinion because typing got in the way. Strict typing and type inference were a huge boon for the design and implementation. I would consider Haskell this time around too (I think I did all those years ago too), as I think lazy evaluation semantics, direct support of monadic style, and yes, even it's terse syntax, could address other aspects of the domain that are untouched. I don't have a clear enough understanding of or experience with Haskell type classes, but my intuition is that I'd have the same problems with typing as I did with OCaml. Cheers, -Andy

Cheers, Loup

On Tue, Apr 1, 2008 at 5:37 PM, Chris Smith wrote:

Just random thoughts here.

Same here...

Andrew Bagdanov wrote:

...

Well, if I don't have side effects (and don't mind extra, unneeded evaluations), I can write my conditionals as functions in Scheme too. Heck, now that I think of it I can even avoid those extra evaluations and side-effect woes if i require promises for each branch of the conditional. No macros required...

This is essentially doing lazy evaluation in Scheme. It's certainly possible; just clumsy. You must explicitly say where to force evaluation; but if you think about it, the run-time system already knows when it needs a value. This is very analogous to having type inference instead of explicitly declaring a bunch of types as in Java or C++.

Boy is it ever clumsy, and I like your analogy too. But lazy evaluation semantics typically come with purity, which is also a fairly heavy burden to foist onto the user... Certainly not without benefits, but at times a burden nonetheless...

...

Again, I think this is highly problem dependent, though I think you win more with lazy evaluation in the long run. Do more experienced Haskellers than me have the opposite experience? I mean, do you ever find yourself forcing strict evaluation so frequently that you just wish you could switch on strict evaluation as a default for a while?

The first thing I'd say is that Haskell, as a purely functional language that's close enough to the pure lambda calculus, has unique normal forms. Furthermore, normal order (and therefore lazy) evaluation is guaranteed to be an effective evaluation order for reaching those normal forms. Therefore, forcing strictness can never be needed to get a correct answer from a program. (Applicative order evaluation does not have this property.)

I thought that in a pure functional language any evaluation order was guaranteed to reduce to normal form. But then it's been a very, very long time since I studied the lambda calculus...

Therefore, strictness is merely an optimization. In some cases, it can improve execution time (by a constant factor) and memory usage (by a lot). In other cases, it can hurt performance by doing calculations that are not needed. In still more cases, it is an incorrect optimization and can actually break the code by causing certain expressions that should have an actual value to become undefined (evaluate to bottom). I've certainly seen all three cases.

There are certainly situations where Haskell uses a lot of strictness annotations. For example, see most of the shootout entries. In practice, though, code isn't written like that. I have rarely used any strictness annotations at all. Compiling with optimization in GHC is usually good enough. The occasional bang pattern (often when you intend to run something in the interpreter) works well enough.

(As an aside, this situation is quite consistent with the general worldview of the Haskell language and community. Given that strictness is merely an optimization of laziness, the language itself naturally opts for the elegant answer, which is lazy evaluation; and then Simon and friends work a hundred times as hard to make up for it in GHC!)

Yeah, I'm actually pretty convinced on the laziness issue. Lazy evaluation semantics are a big win in many ways.

...

I think this is possibly the weakest reason to choose Haskell over Scheme. Lispers like the regularity of the syntax of S-expressions, the fact that there is just one syntactic form to learn, understand, teach, and use.

I am strongly convinced, by the collective experience of a number of fields of human endeavor, that noisy syntax gets in the way of understanding. Many people would also say that mathematical notation is a bit impenetrable -- capital sigmas in particular seem to scare people -- but I honestly think we'd be a good ways back in the advancement of mathematical thought if we didn't have such a brief and non-obstructive syntax for these things. Mathematicians are quite irregular. Sometimes they denote that y depends on x by writing y(x); sometimes by writing y_x (a subscript); and sometimes by writing y and suppressing x entirely in the notation. These are not arbitrary choices; they are part of how human beings communicate with each other, by emphasizing some things, and suppressing others. If one is to truly believe that computer programs are for human consumption, then striving for regularity in syntax doesn't seem consistent.

All good points, but "noisy" is certainly in the eye of the beholder. I'd make a distinction between background and foreground noise. A simple, regular syntax offers less background noise. I don't have to commit lots of syntactic idioms and special cases to memory to read and write in that language. Low background noise in Scheme, and I'm responsible for whatever foreground noise I create with my syntactic extensions. Haskell, with more inherent syntax, has more background noise but perhaps limits the amount of foreground noise I can introduce because it constrains me from the beginning... OK, this analogy is starting to suck, so I'll move on... More on the mathematical notation analogy below.

Initially, syntax appears to be on a completely different level from all the deep "semantic" differences; but they are in reality deeply interconnected. The earlier comment I made about it being clumsy to do lazy programming in Scheme was precisely that the syntax is too noisy. Other places where lazy evaluation helps, in particular compositionality, could all be simulated in Scheme, but you'd have to introduce excessive syntax. The result of type inference is also a quieter expression of code. So if concise syntax is not desirable, then one may as well throw out laziness and type inference as well. Also, sections and currying. Also, do notation. And so on.

Well, yes. However, I think, and have found through personal experience, that notation is one of the most personal aspects of mathematics, and one of the most difficult things to get "right." Or even "pretty good." Good notation that conveys meaning without distraction and confusion (ah yes, the interconnection between syntax and semantics rears it's head again) is extremely difficult to invent. Like in mathematics, at the boundaries of creativity, I prefer the freedom to create my own notation and syntax in order to express my ideas about computation, and to adapt them to whatever relevant community standards are appropriate (physicists, signal processors, and image processing folks all have their own notations for convolution). Haskell has an elegant and expressive, but already quite defined and complex, syntax that is not particularly malleable. Returning to your line of reasoning, why should one have to commit to a single, already defined syntax instead of a minimal, regular one which admits the possibility of extending and modifying the syntax to fit my needs? It's a double-edged blade, obviously, because if I botch my syntax extensions I ruin the regularity and simplicity I originally had and don't communicate clearly to others or myself. It's the same risk as in mathematics, and just a hard to get "right." Do notation and sections are both syntactic constructs that irk me at an almost visceral level about Haskell syntax, but I certainly see the convenience of both and recognize that my opinion is wholly subjective. That Scheme applications are non-currying by default is one of the things that irks me now about Scheme...

...

In short, I think the orginal question must be asked in context. For some problems, types are just a natural way to start thinking about them. For others dynamic typing, with _judicious_ use of macros to model key aspects, is the most natural approach.

I wouldn't completely rule out, though, the impact of the person solving the problem on whether type-based problem solving is a natural and useful way to solve problems. Indeed, I would guess this probably ends up being a greater factor, in the end, than the problem. Unfortunately, we (as a general programming community) have caged ourselves into a box with the mantra "use the right tool for the job" such that we find it far too easy to dismiss something as the wrong tool merely because it is unfamiliar. My not being able to use a tool well may be a good reason for me, but it's a lousy reason for me to advise someone else.

Yes and no. I see your point about the person being central to the problem solving itself, and "the right tool for the right job" implicitly assumes that there is on "right" solution for a problem. However, I can pretty much only base my advice to someone about what tools to use on my own experience with those tools (qualified, of course, with the upfront admission that it's based on personal experience), and I would likewise be wary myself of someone giving advice that wasn't tempered by experience. Theoretical discussions about the theoretical underpinnings of tools seem to be an equally lousy basis for such advice. Cheers, -Andy

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe