Re: Glasgow haskell vs. Lispworks

In article <1186834189.429035.22350@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Stuart Cook <scook0@xxxxxxxxx> wrote:

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*.

It talks that there are different equalities and you have to
say which you want:

* identity (is this really the same thing?)
* value (does it have the same value?)
* structural (does is have the same structure?)
* fuzzy (is it same up to some limit?)

and so on.


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.

The compiler can't discover my intentions. That would be AI.


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?

Sure, why not? In Lisp you are using all kinds of data structures which
are not build out of conses.

--
http://lispm.dyndns.org
.

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: newbie question about quote
    ... > Hi I'm new to LISP. ... > "Quote may seem a bit of a foreign concept because few other languages ... This is a pain because the C compiler we are using does this, ... like a program but I want to pretend it is a data structure". ...
    (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: How Lisps Nested Notation Limits The Languages Utility
    ... same grammar and they both parse to the same data structure. ... structure is neither infix nor prefix. ... In lisp it is hard coded into the compiler ) in a number ...
    (comp.lang.lisp)
  • Re: Glasgow haskell vs. Lispworks
    ... equals, equalp and other data structure specific versions. ... Haskell denies you this particular flexibility, ... At a broad level of generalization, I suppose you could say that Lisp ... A Haskell compiler tries to keep you ...
    (comp.lang.functional)