What do you LISPers think of Haskell?

On 19 ago, 21:07, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Actually, what the lisp type system means is that in lisp we program
> in generic mode by default.
>
> When you write:
>
> * *int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> it's statically typed, but it's also SPECIFICALLY typed.

Yes.

> When you write in lisp:
>
> * *(defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> it's already a generic function

Not quite. More on that in a moment.

> to get the same in C++ you would have to write:
>
> * #include <rational.hxx>
> * template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
>
> * ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...

The C++ example with template is far more generic than the Lisp one:
it's defined for all types T capable of handling operatotions <= and
*, whereas the Lisp one just takes them for granted over numbers.

Of course, in the case of factorial, it doesn't matter, but it means
you can have complex datatypes redefining useful operators (or
functions) *at compile time*. Same for Haskell. Functions are
defined and dispatched per type.

You could of course do something like this, say, in Scheme:
(define +
(let ((o+ +))
(lambda (a b . more)
(apply (if (string? a)
string-append
o+)
(cons a (cons b more))))))

and use it more "generically" like this:
(+ 1 2 3 4 5) => 15
(+ "foo" "bar") => "foobar"

In implementations which actually permit redefining such fundamental
functions.

But then, you gotta do run-time checks on the arguments not present in
the Haskell and C++ compile-time functions. Note such checks can go
on as you nest deep into possibly yet previous redefinitions of the
operator that do almost like the above.

> But you can easily get even more genericity, either using non CL
> operators that you can easily redefine (eg. as lisp generic
> functions), by shadowing them to the same effect, or by using
> functions passed in argument. *CL:SORT is generic because it takes a
> LESSP function, so it can be applied on sequences of any kind of
> object.

These are all fine workarounds, even though perhaps more verbose than
simply being able to do function "overloading" per types. Sorry if I
sound froggy.

On 19 ago, 22:15, "xah...@gmail.com" <xah...@gmail.com> wrote:
> I love math. I respect Math. I'm nothing but a menial servant to
> Mathematics. Who the fuck is this David guy, who proclaims that he's
> no mathematician, then proceed to tell us he doesn't fucking care
> about math? Then, he went on about HIS personal fucking zeal for
> physics, in particular injecting the highly quacky “quantum mechanics”
> with impunity.

Physics and engineers don't care much about math, it's just a useful
tool for their more pragmatic goals.

> Btw, Jon, you often attack Lisp, Haskell. However, i don't think i've
> ever seen you criticize OCaml.

Oh, he does criticize OCaml at every oportunity there is to sell
F#.

On Aug 19, 1:31 pm, ssecorp <circularf...@gmail.com> wrote:
> What are you LISPers opinion of Haskell?
>

I recently did some Haskell (and Erlang) hacking, too. Although I like
both languages and they both have their niches, the biggest feature
that takes me back to Common Lisp every time is macros. Whenever I use
another language (does not matter what it is), deep down I wish the
language had macros like Common Lisp.

--
Ralph

On Aug 19, 10:11 pm, Ralph Allan Rice <ralph.r...@gmail.com> wrote:
> On Aug 19, 1:31 pm, ssecorp <circularf...@gmail.com> wrote:
>
> > What are you LISPers opinion of Haskell?
>
> I recently did some Haskell (and Erlang) hacking, too. Although I like
> both languages and they both have their niches, the biggest feature
> that takes me back to Common Lisp every time is macros. Whenever I use
> another language (does not matter what it is), deep down I wish the
> language had macros like Common Lisp.

You could try Liskell: http://liskell.org/

I haven't tried it, but it looks interesting.

-- Scott

xahlee@gmail.com wrote:
> Btw, Jon, you often attack Lisp, Haskell. However, i don't think i've
> ever seen you criticize OCaml.

Despite my foray into other FPLs, OCaml has remained my favourite language
for getting work done (F# is arguably better for making money) but OCaml
does have some problems:

.. OCaml lacks a concurrent garbage collector and, consequently, is unable to
leverage shared-memory parallelism on a wide range of tasks. F# fixed this.

.. OCaml's has unsafe built-in polymorphic functions such as equality,
comparison and hashing. These can silently break if they are accidentally
applied to abstract types and the subsequent bugs can be almost impossible
to fix.

.. OCaml has a cumbersome foreign function interface.

.. OCaml lacks run-time type information and, consequently, type-safe
serialization and generic printing. F# solved this problem.

.. OCaml lacks operator overloading so mathematical expressions involving
many different numeric types are unnecessarily. F# solved this problem.

.. OCaml lacks many basic types such as int8, int16, float32, complex32. F#
solved this problem.

.. OCaml lacks value types so complex numbers cannot be unboxed. F# solved
this problem and, consequently, is 5.5x faster at complex FFTs than
naively-written OCaml.

.. OCaml has an old fashioned one-stage compiler design. F# improves upon
this with the CLR's ahead-of-time compilation. For example, the CLR
generates type specialized native code whereas OCaml uses a uniform generic
representation that can incur substantial performance hits.

.. OCaml's uniform generic representation includes tagged 31- and 63-bit
integers. F#'s unboxed representation is ~3x faster.

.. The OCaml implementation cannot be contributed to and we cannot pay INRIA
to fix or improve it. For example, I filed a bug with a verbatim source
code fix that was only actually instigated a year later.

I believe these problems can be solved in a future open source FPL without
sacrificing the key features that make OCaml so productive. However, many
of these problems do not constitute research and, consequently, they are
unlikely to be fixed by academic programming language researchers.

I am not sure how to proceed with such a project (e.g. build upon LLVM or
build upon Mono?) but there appears to be growing interest in this idea.
Ideally, FPL communities would collaborate to build a common language
run-time for OCaml, Lisp, Scheme, Haskell and so on but I cannot see that
happening for social reasons. Without such collaboration, I doubt any of
these languages will ever get a concurrent GC approaching the efficiency
of .NET's.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

DeverLite wrote:
> On Aug 19, 9:27*pm, Kenny <kentil...@gmail.com> wrote:
>> I would have added OCaml but I saw
>> some investment bank in NYC was Actually Using It, and The Kenny hasa
>> soft spot for Programmers Actually Programming.
>
> Also I think FFTW3, the very well used open source Fourier transform
> library, uses OCaml to generate optimized C code...

And FFTW is part of MATLAB. Intel, Microsoft and Citrix all have huge OCaml
code bases as well...

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

namekuseijin wrote:
> Oh, he does criticize OCaml at every oportunity there is to sell
> F#.

You realize we sell OCaml products as well:

http://www.ffconsultancy.com/product..._scientists/?u
http://www.ffconsultancy.com/products/ocaml_journal/?u

In fact, there is currently more money in OCaml than F#...

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

Haskell is awesome. I heard it might be better to start with ML if it
is your first strongly-typed FP, though.

On Aug 20, 2:55*am, Scott Burson <FSet....@gmail.com> wrote:
> You could try Liskell:http://liskell.org/
>
> I haven't tried it, but it looks interesting.

Whoa! Looks mighty fine to me!

http://liskell.org/fifteen-minute-tour

The syntax and semantics look like a nice mix of Scheme and Haskell.
I the ease of defining ADTs:

(defdata Point3DType
(Point3D Rational Rational Rational))

and pattern matching on function definition without destructuring-bind
or other verbose macro workaround:
(define (distance3D (Point3D x y z))
(sqrt (+ (^ x 2)
(+ (^ y 2) (^ z 2)))))

or function definitions in let with the same syntax sugar as in define
(no lambda):
(define (scalar-multiply s point)
(let (((Point3D x y z) point)
((p x) (* s x)))
(Point3D (p x) (p y) (p z))))

Perhaps it also comes full with lazy semantics? A project to watch
closely.

Who knows, perhaps it attracts even more interest than Haskell or Lisp
alone... now Arc has some tough competition! :P

On Aug 20, 1:01*am, namekuseijin <namekusei...@gmail.com> wrote:
> On 19 ago, 21:07, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Actually, what the lisp type system means is that in lisp we program
> > in generic mode by default.
>
> > When you write:
>
> > * *int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> > it's statically typed, but it's also SPECIFICALLY typed.
>
> Yes.
>
> > When you write in lisp:
>
> > * *(defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> > it's already a generic function
>
> Not quite. *More on that in a moment.
>
> > to get the same in C++ you would have to write:
>
> > * #include <rational.hxx>
> > * template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
>
> > * ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
>
> The C++ example with template is far more generic than the Lisp one:
> it's defined for all types T capable of handling operatotions <= and
> *, whereas the Lisp one just takes them for granted over numbers.
>
> Of course, in the case of factorial, it doesn't matter, but it means
> you can have complex datatypes redefining useful operators (or
> functions) *at compile time*. *Same for Haskell. *Functions are
> defined and dispatched per type.
>
> You could of course do something like this, say, in Scheme:
> (define +
> * * (let ((o+ +))
> * * * (lambda (a b . more)
> * * * * (apply (if (string? a)
> * * * * * * * * * *string-append
> * * * * * * * * * *o+)
> * * * * * * * *(cons a (cons b more))))))

or Common Lisp (with semi-Prolog naming convention).

(defmethod +//2 ((x string) (y string))
(concatenate 'string x y))
(defmethod +//2 ((x number) (y number))
(cl:+ x y))

(defun extmath:+ (x y &rest more-summable-things)
(reduce '+//2 more-summable-things
:initial-value (+//2 x y)))

You can expand on this code as much as you want.

Cheers
--
Marco