Re: Glasgow haskell vs. Lispworks

On Aug 11, 10:10 am, Rainer Joswig <jos...@xxxxxxx> wrote:
In article <f9id4j$9u...@xxxxxxxxx>,
"Rene de Visser" <Rene_de_Vis...@xxxxxxxxxxx> wrote:

Equals works correctly in Haskell. Not need to decide between eq, eql,
equals, equalp and other data structure specific versions.

Equal can't work 'correctly'. You might want to read Kent Pitman's
article about it.

http://www.nhplace.com/kent/PS/EQUAL.html

[Disclaimer: I'm a Haskell fan, and not a Lisper, so take my words
with an appropriate grain of salt.]

That article describes why generic equality can't work *in (Common)
Lisp*.

The fundamental problem for CL is that given a cons cell, it's
impossible to reliably determine whether it should be interpreted as a
cons-pair, a list, a tree, or something else entirely. This is because
CL gives you the flexibility to use conses in many different ways
without having to explicitly declare your intention.

Haskell denies you this particular flexibility, but in exchange you
gain the ability to have compiler discover your intentions using the
types of your terms. Pairs, lists and trees all have distinct types,
and Haskell can use the appropriate comparison function automatically.

So this is a nice example of a feature that CL can't[1] have -- not
because CL somehow isn't powerful enough, but because in this case it
has *too much* unrestricted power. "With great power comes great
responsibility", after all.

At a broad level of generalization, I suppose you could say that Lisp
compilers tend to assume you know what you're doing, as long as it
looks like it might make sense. A Haskell compiler tries to keep you
"honest", and in exchange does its best to assist you using the
information you provide.


(There are some other nice properties of Haskell arising from
typeclasses, purity etc., but I won't go into these right now.)


I have less choices in Haskell.For me this simplifies programming. Code
sometimes follows directly form the types.

Yes, this can be good.

Come to think of it, this is my entire post in a nutshell.


Stuart Cook

[1] Well, you might be able able to come close by avoiding raw conses
entirely, but would you be able call the result Lisp?

.

Relevant Pages

  • Re: Does purely functional way requires static typing?
    ... Compared to typical Haskell code, ... They think that static typing and ... Lisp does define the precise ... A compiler is nothing; it's just a subroutine for optimizing code. ...
    (comp.lang.lisp)
  • Re: Haskell: functional languages vs Lisp
    ... > do eventually wind up with a lazy eval function. ... The CMU AI repository contains the sources of the Yale Haskell ... The compiler is written in Common Lisp (with lots of ... functions are translated to Lisp. ...
    (comp.lang.lisp)
  • Re: Glasgow haskell vs. Lispworks
    ... equalp and other data structure specific versions. ... Haskell denies you this particular flexibility, ... The compiler can't discover my intentions. ... At a broad level of generalization, I suppose you could say that Lisp ...
    (comp.lang.functional)
  • Re: A.C
    ... if you could get that forward slash into the equals sign then that ... Haskell programs! ... So there are people out there actually using Haskell, ...
    (talk.origins)
  • Re: A.C
    ... if you could get that forward slash into the equals sign then that ... So there are people out there actually using Haskell, ... You are the first 'functional' or 'applicative' language programmer ... programming language they encounter as 'the way computers do it'. ...
    (talk.origins)