HASKELL vs CLISP 
Author Message
 HASKELL vs CLISP

Hello group, i've an interesting question.
What are the differences between CLISP and HASKELL?
IN What aspects one languaje is better than other?
I know LISP is older than Haskell but... ?Is more powerfull than the last
one?
NOTE : THIS is a CONSTRUCTIVE question, and i like both of them,however
scientific comunity prefer CLISP to implement IA applications. ?Is for any
particular aspect this preference?

THANKS TO ALL.



Sat, 09 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP
[ Sergio ]

Quote:
> What are the differences between CLISP and HASKELL?

Common Lisp has all the common imperative structures of e.g. the Algol
family of languages and some extra, and nowadays iterative structures
(like do and loop) is used much more than recursion, which is the only
method of iteration in functional languages like Haskell. Also, having
such a long history, Common Lisp is IMHO a more mature language than
most, and has well-proven syntax and semantics. Furthermore there are
several vendors of good compilers/IDEs, and at least some of them can
generate machine code that can compete with C/C++ in performance.

Haskell on the other hand is purely functional, which probably scare
away many programmers with only practice in imperative programming. As
a "pure", functional language, Haskell might do certain things better
than Common Lisp, but in many aspects, I think Common Lisp with its
ability to do both functional-style and imperative-style programming
is superior. OTOH, as it's still a young language, Haskell might grow
and evolve to a much greater popularity.

Quote:
> I know LISP is older than Haskell but... ?Is more powerfull than the last
> one?
> NOTE : THIS is a CONSTRUCTIVE question, and i like both of them,however
> scientific comunity prefer CLISP to implement IA applications. ?Is for any
> particular aspect this preference?

Tradition is a big factor, but I think someone with more experience in
these matters than me could give a better answer.

Martin
--
"Plus I remember being impressed with Ada because you could write an
 infinite loop without a faked up condition.  The idea being that in Ada
 the typical infinite loop would normally be terminated by detonation."
                                             -Larry Wall



Sat, 09 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

Quote:
> What are the differences between CLISP and HASKELL?

Haskell is statically typed, LISP is dynamically typed. In Haskell
more is done at compile time, bindings of names are statically resolved.
LISP does more at runtime, you can define functions on the fly etc.

Haskell is purely functional: function application has no side effects,
I/O is separate from expression evaluation, there are no mutable
variables in the language standard (but there exist extensions). LISP
is semi-functional, any function can mutate the world as it is applied,
it can happen that making a copy of an object is necessary if it may
get mutated later.

Haskell is lazy, LISP is strict. (Purity is necessary for being lazy.)

They of course differ in syntax much, and in some conventions (Haskell
uses currying, LISP does not).

Haskell's classes allow "overloading" on the context of usage. This
is generally not possible in dynamically typed languages.

--

 \__/              GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-



Sun, 10 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP


Quote:

[...]
> Haskell's classes allow "overloading" on the context of usage. This
> is generally not possible in dynamically typed languages.

I haven't used Haskell - would this be similar to dispatching on an
object's class?  If so, it is possible in Common Lisp (which includes
CLOS - support for OOP).

Andrew

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 10 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

Quote:
> > Haskell's classes allow "overloading" on the context of usage.
> > This is generally not possible in dynamically typed languages.

> I haven't used Haskell - would this be similar to dispatching on an
> object's class?  If so, it is possible in Common Lisp (which includes
> CLOS - support for OOP).

I haven't used CLOS - I don't know, but I doubt it.

Examples:

Values minBound are maxBound can have any type which have defined
bounds. When maxBound is used in the context that expects the Bool
type, it equals True. Treated as Int, it might be 2147483647.
This is done without specific support from the compiler, using
general mechanism of Haskell classes (which should probably be called
"interfaces").

pi can have any floating type. I can define my own type, provide
a value of pi for it together with a bunch of functions (which
are needed for a type to conform to the Floating class) and the
expression sqrt(2*pi), when used in the context of my type, will
use specific implementation of pi.  Basic arithmetic operators are
similarly overloaded.

Numeric literals are overloaded. It requires compiler magic to
have this syntactic sugar. An expression like 5 is rewritten to
fromInteger 5, where fromInteger has the type:
    fromInteger :: Num a => Integer -> a
i.e. for any numeric type a, it can be used as a function from Integer
to a. An expression like 123*456 multiplies two Doubles where used
in the context expecting a Double, and similarly for other types; it
does not get promoted to the target type after performing operations.

Probably the most common case of overloading on context, besides
numeric literals, is using monads, in the function "return". Monads
are hard to explain briefly. The expression
    return 5
can denote an I/O action that does nothing and produces 5, a parser
that consumes nothing and succeeds yielding 5, a stateful computation
that does not change the state and produces 5, a singleton list
consisting of 5, a possibly failing function that succeeds and returns
5, etc. The compiler statically ensures type consistency and infers
from the context what this occurence of return really means.

--

 \__/              GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-



Sun, 10 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

Quote:

> > > Haskell's classes allow "overloading" on the context of usage.
> > > This is generally not possible in dynamically typed languages.

> > I haven't used Haskell - would this be similar to dispatching on an
> > object's class?  If so, it is possible in Common Lisp (which includes
> > CLOS - support for OOP).

> I haven't used CLOS - I don't know, but I doubt it.

What do you doubt? That dispatching on an objects class is possible in
Common Lisp? Now it is possible and it is not just possible on one
object but on all parameters of a generic function.

Regards
Friedrich



Mon, 11 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP
Centuries ago, Nostradamus foresaw a time when Marcin 'Qrczak' Kowalczyk
would say:
Quote:
>Wed, 24 May 2000 19:11:29 GMT, Andrew Cooke


Quote:

>> > Haskell's classes allow "overloading" on the context of usage.
>> > This is generally not possible in dynamically typed languages.

>> I haven't used Haskell - would this be similar to dispatching on an
>> object's class?  If so, it is possible in Common Lisp (which includes
>> CLOS - support for OOP).

>I haven't used CLOS - I don't know, but I doubt it.

Methinks you remain a mite too skeptical.  Multiple dispatch is a
pretty powerful notion.

Quote:
>Examples:

>Values minBound are maxBound can have any type which have defined
>bounds. When maxBound is used in the context that expects the Bool
>type, it equals True. Treated as Int, it might be 2147483647.
>This is done without specific support from the compiler, using
>general mechanism of Haskell classes (which should probably be called
>"interfaces").

The nearest equivalent in CLOS is somewhat reversed from this; the
following represents a way of "coercing" a particular value to the
desired type.

;;; minBound/maxBound...
(defmethod MB ((v single-float))
  most-positive-single-float)
(defmethod MB ((v fixnum))
  most-positive-fixnum)
(defmethod MB ((v t))
  T)
(defmethod LB ((v single-float))
  most-negative-single-float)
(defmethod LB ((v fixnum))
  most-negative-fixnum)

; 0] (MB 25)

; 536870911
; 0] (LB 25)

; -536870912

The behaviour here is sort of equivalent but opposite; CLOS does its
dispatching based on the classifications of the _inputs_.
--


Millihelen, adj:
        The amount of beauty required to launch one ship.



Mon, 11 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

Quote:
> > I haven't used CLOS - I don't know, but I doubt it.

> What do you doubt? That dispatching on an objects class is possible in
> Common Lisp?

That you can dispatch basing on what type of result is expected.

Quote:
> Now it is possible and it is not just possible on one object but
> on all parameters of a generic function.

Great - most OO languages require 1. CLOS allows >=1, but Haskell
allows >=0.

What about dispathing on the type of elements of the list passed as an
argument, where the list may be empty? The following standard function:

sequence :: Monad m => [m a] -> m [a]
sequence []     = return []
sequence (m:ms) = do x <- m; xs <- sequence ms; return (x:xs)

when given a list of IO actions, produces the IO action that runs
them in sequence, collecting their outputs in a list; when given
a list of parsers, produces the parser that... etc.

The list may be empty, in which case it produces the IO action that
does nothing and returns the empty list, etc.

Dispatching is based not on values passed, but on the way a function
is instantiated.

If you want dispatching on values, use another technique, e.g. closures.
Or a Haskell extension of existential quantification, which allows
some more dynamic things like heterogenic collections, while still
having guaranteed type safety.

--

 \__/              GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-



Mon, 11 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

[List of how Haskell is different from CLISP]

I would think the class system in Haskell is rather different from
most traditional languages.  It certainly took a while for me to get
used to it.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants



Mon, 11 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

Quote:
> Values minBound are maxBound can have any type which have defined
> bounds.

You should be able to do this in OO languages (I don't know Common
LISP very well, but some others) by having these values be the
equivalent of static class members.

Quote:
> pi can have any floating type.

Ditto.

Quote:
> Numeric literals are overloaded.

This is only necessary because Haskell is so static.  In most other
languages, constants will be automatically converted, probably at run
time.

Quote:
> Probably the most common case of overloading on context, besides
> numeric literals, is using monads, in the function "return".

Again, I feel this is sort of irrelevant for most languages, but most
OO languages will be able to have different implementations for
different classes and/or type signatures.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants



Mon, 11 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

Quote:

> The nearest equivalent in CLOS is somewhat reversed from this; the
> following represents a way of "coercing" a particular value to the
> desired type.

Not quite the same, since you'd have to be explicit about the type
with a dummy argument.  Of course, CLOS being dynamic and all, it's
hard for the compiler (and it might even be interpreted) to deduce it
from the expression.

Quote:
> ;;; minBound/maxBound...
> (defmethod MB ((v single-float))
>   most-positive-single-float)
> (defmethod MB ((v fixnum))
>   most-positive-fixnum)

This is more like pattern matching, I think:

mb :: a -> a
mb Int x = 2^31-1
mb Float x = 2.956*10^38 -- or whatever

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants



Mon, 11 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

Quote:

> Haskell is lazy, LISP is strict. (Purity is necessary for being lazy.)

This (the last statement) seems to be a bit far from the Full Truth.
There are lazy streams in an impure CAML.
And in a very impure Scheme.

And laziness is something not too far from the "call by name"
protocol in a horribly impure Algol.

Lazy objects such as co-expressions are present in a more-than-impure
Icon.

===

If the inherent evaluation semantics of the language is lazy, it
is better not to have uncontrolled imperative constructs, sure,
otherwise there is Chaos. But the word "necessary" - as I see it -
is an overstatement.

Jerzy Karczmarczuk
Caen, France



Mon, 11 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

Quote:
> I would think the class system in Haskell is rather different from
> most traditional languages.  It certainly took a while for me to get
> used to it.

It was different in my case: I almost reinvented it :-)

I always wanted to design my own programming language (who never did?)
because I was not comfortable enough with what I knew that time.

I knew C++, liked the idea of templates, but not the way C++ does
them: does not allow specifying constraints on template parameters,
requires separate compilation for each instantiated type, does not
allow separate compilation of modules providing templates, has horrible
rules of binding identifiers in templates to definitions.

OTOH I never liked the OO approach of making one function argument
special, specifying all supported operations at the place of definition
of a type, dispatching basing on a single parameter, having type
information at each value, and not being able to accurately describe
the type of equality (second argument of type Object? no!).

I felt signatures implemented in GNU C++ was a step in the right
direction. At least the requirement of specifying all operations at
the definition of a type was dropped. But still the first parameter
was special.

14 months ago the problem began to clarify. I was designing a system
of unifying templates with dynamic dispatch, deliberately skipping
the OO way. Template parameters should be constrained, and only
operations resulting of these constraints should be available in
the template. Interface of a type should not be limited to a set of
operations having the first parameter of the type we are describing
interface of, e.g. equality has two parameters of this type. And
we should be able to specify constraints on several types at once,
e.g. that a value of type A indexed by B yields C. Or something
like that.

I still felt the necessity of implicit type conversions and
unconstrained overloading. I asked for advice on type conversions on

probably undecidable. Oops. I am stuck. What to do?

Then I discovered Haskell. Functional - how strange. But hey, it just
unified templates (called polymorphism) with dynamic dispatch, exactly
as I wanted to do! No overloading - but the unified system makes it
quite unnecessary. No implicit conversions - surprisingly they are
not needed, especially as being functional avoided having references.
Functionalness happened to be very convenient after getting used to it.

How nice. After many years I stopped designing my own language,
because Haskell did many things better than I could imagine. And most
other languages are as blind as I was before.

--

 \__/              GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-



Mon, 11 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

Quote:


> > Values minBound are maxBound can have any type which have defined
> > bounds.

> You should be able to do this in OO languages (I don't know Common
> LISP very well, but some others) by having these values be the
> equivalent of static class members.

No, that does not work. You don't have dynamic dispatch for static
members - opposed to `nullary methods' in Haskell type classes.

The main difference between OO dispatch and dispatch in Haskell is that
in OO it is done through objects, ie. you need actual values to select
the proper method. With type classes, dispatch is completely separated
from values, it is based purely on types. That approach is more general.
Marcin gave some examples.

Quote:
> > Numeric literals are overloaded.

> This is only necessary because Haskell is so static.  In most other
> languages, constants will be automatically converted, probably at run
> time.

Please, not that discussion again. Just note that the Haskell solution
allows the user to easily extend the set of types that can be denoted by
literals (or other language syntax, such as lists), and without
compromising the static type system. I am not sure whether some
mechanism for implicit runtime conversions can give you similar
flexibility.

--

:: be declarative. be functional. just be. ::



Mon, 11 Nov 2002 03:00:00 GMT  
 HASKELL vs CLISP

Quote:

> The main difference between OO dispatch and dispatch in Haskell is that
> in OO it is done through objects, ie. you need actual values to select
> the proper method.

Not necessarily, you can specify e.g. MyClass::maxbound.  Of course,
that's not particularly attractive, general, or dynamic :-)

Quote:
>> This is only necessary because Haskell is so static.  In most other
>> languages, constants will be automatically converted, probably at run
>> time.
> Please, not that discussion again. Just note that the Haskell solution
> allows the user to easily extend the set of types that can be denoted by

Right, I didn't mean to imply that one solution was superior to the
other, only that Haskell's static typing probably makes this simpler
to achieve, and that run time conversion is another way of handling
it.  

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants



Mon, 11 Nov 2002 03:00:00 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Question about CLisp, Dylan, Haskell, Ocaml

2. Question about CLisp, Dylan, Haskell, Ocaml

3. Question about CLisp, Dylan, Haskell, Ocaml

4. Question about CLisp, Dylan, Haskell, Ocaml

5. Question about CLisp, Dylan, Haskell, Ocaml

6. Question about CLisp, Dylan, Haskell, Ocaml

7. HASKELL VERSUS CLISP

8. Scheme vs Haskell vs Erlang

9. Lispworks vs CLisp

10. ACL vs. CLISP

11. CL (CLISP vs CMUCL) performance on Linux

12. gclisp vs clisp

 

 
Powered by phpBB® Forum Software