Haskell: functional languages vs Lisp

From: Kaz Kylheku (kaz_at_ashi.footprints.net)
Date: 05/28/04 

Date: 28 May 2004 12:49:58 -0700

marcelin7@yahoo.com (Nelson Marcelino) wrote in message news:<d4626d19.0405280530.3c7c259f@posting.google.com>...
> I am curious to know what advantages does Lisp have over Haskell.

Lisp is a mature, ANSI-standardized language with a plethora of free
as well as proprietary, commercial implementations.

Lisp has many features, in it, too numerous to list here.

A Lisp application can be shipped as a native code executable. Yet,
even while that that application is running, it can be patched live
with newer versions of compiled functions. Moreover, the Lisp lexical
scanner and compiler are available at run time. An application can
scan data represented in Lisp syntax to obtain a data structure, and
process data into code and then compile and execute it.

  As
> far as I know the Haskell Prelude as well as its modules implement
> most of the functionality that lisp provides but with a much cleaner
> and succinct syntax.

The Haskell syntax is terrible. It's full of cryptic operators and
ambiguities that can only be resolved if one is familiar with its
associativity and precedence rules.

To me, that syntax has been a huge obstacle when I tried to educate
myself about Haskell by reading Haskell literature.

Speaking of which, if someone has written a decent paper about monads
whose examples use a decent syntax (perhaps S-expressions or something
unambiguous along those lines), I'd love to hear about it!

I'm no longer willing to invest the time to learn someone's
masturbatory lexical syntax. Syntax looked cool to me when I was 19
years old, because I thought that there might be something behind it.
So when I encountered C, I happily digested the precedence and
associativity. I felt smart when I could eliminate all unnecessary
parentheses from an expression without changing its meaning, and
understand it six months later!

In reality these syntaxes are reduced to abstract syntax trees in the
earliest stages of processing, and such trees can be annotated without
ambiguity as nested, parenthesized lists. Moreover, it's possible for
such a notation to universally annotate *any* abstract syntax tree,
including ones that have no lexical syntax.

Haskell's design choice means that Haskell source code is defined at
the character level only. There is no inner representation which is
available to the programmer; in effect, the syntax is erected as a
barrier between the programmer and the language. In Lisp, the
character-level source code specifies a data structure, and that data
structure is the true source code of the program.

In a Lisp system, it's possible to have compiled programs to which
there never existed any character-level source code; the source code
was a data structure which was assembled together by a program and
then passed to the compiler.

> Furthermore, Paul Hudak claims that lisp is not based on lambda
> calculus (as many people think) and is not a true functional language;
> therefore in some instance this can make formal verification of lisp
> programs difficult.

Formal verification of any real world program is impossible. In the
real world, you modularize the program, validate all inputs, and
provide a way to recover when there is bad input.

Languages that are geared toward formal verification sacrifice so many
other goals that they are useless outside of academia, or some other
very limited application domain.

Once in a while you hear some success story about some company X that
implemented some in-house language to write some application for their
proprietary hardware. That language invariably has functional features
and allows for formal verification, and so forth. But what's always
missing is that part of the story where the language escapes from that
environment and finds lots of other applications in the rest of the
world.

> I am aware that lisp has many great features such
> as multiple programming paradigms, that it is extensible, adaptable,
> and that it takes a pragmatic view to many things. However providing
> multiple ways to accomplish something such as providing 20 different
> ways to do looping seems very confusing. Why not have just one or two
> standard looping methods to accomplish something?

Why not just have two functional combinators and build everything out
of them?

Why not just have a read-write head that can move along a tape of
symbols?

Hopefully, in some future semester you will learn that equivalence and
expressivity are two very different beasts.

A given computation may be expressed in a clear, straightforward way
in one set of language constructs, but muddled beyond recognition in
another language construct. Sometimes it happens that the only way to
get the expressivity of some language B within language A is to write
an A interpreter in B which understands the expressions of A and
translates them into execution pathways through a B program, or a
compiler which translates A to B and then calls it.

Then there are efficiency considerations too. Just because some neat,
axiomatic building blocks can be combined to do any computation
doesn't mean they are efficient. Sometimes you run into this problem
called abstraction inversion: you combine some building blocks that
have complex internals to express something simple, something that
ought to correspond to a few machine instructions on the given
processor. For example, you have a rendezvous mechanism for
inter-thread communication, and you use it to construct a simple
counting semaphore.

> Lisp provides many flow of control constructs with branching and
> execution of different sections of programming code -- the (cond)
> construct is an example.

In fact Lisp, via the TAGBODY construct, Lisp supports goto. Some
programs are best represented by such a body full of labels and gotos,
period. TAGBODY makes an ideal target language for all kinds of
control constructs.

> With languages like Haskell flow of control is not an issue.

Nonsense. The requirements and design dictate whether or not something
is an issue. The language becomes an issue when it can't express the
design, or can't do so efficiently.

If I have straightforward imperative algorithm, but I have to warp it
to suit some functional paradigm, *that* is an issue.

> Equational reasoning promotes a declarative style of program
> implementation and allows such things as parallel proccessing to be
> implicit.

I don't want some tool promoting something at me.

You have failed to add an argument why a declarative style is
superior, and under what conditions, and what you are going to do when
that style is all you have, but it's not appropriate for the problem
at hand!

You could just as well be saying that a hammer promotes a
board-and-nail style of construction. Well, that is true, but so what
and who cares?
 
> I would like to know what people think of newer languages such as Lisp
> OCAML SML
> and how they compare to Lisp. Also functional programming contests
> held each year allow any language to compete. And it always seems that
> languages such as OCAML, Haskell, Dylan etc alls fare well where other
> languages such as Lisp never make it to the semifinals.

That's because these languages are optimized for writing programs that
win functional programming contests. And in fact many of the
participants are the language designers, who use these contests as
feedback to hone their language for ... next year's contest.

> Paul Graham
> says he is creating a new language called Arc. Apparently there are
> some things about lisp that he does not like. But I don't think Graham
> knows about some of the newer functional languages.

Graham knows how to sell a program to Yahoo and make millions of
dollars.

You are unfairly underestimating Graham if you think he knows nothing
about these languages. Maybe he's simply not excited enough by these
languages to write anything about them, that is all.

Relevant Pages

  • Re: Lies, damn lies, ....
    ... language group. ... This puts Lisp at number 14 with a rating of .718% ... looked, and saw the plans for dumping paren syntax, as well as the lack of a good macro system, and decided to pass. ... That said, if you look past the syntax, Dylan is right in between ...
    (comp.lang.lisp)
  • Re: Whats the best language to learn...
    ... on processors designed to run Lisp and Lisp OSes. ... sence that the language make effective use of them. ... No other programming language can do what lisp can do. ... is exactly because of its syntax. ...
    (comp.programming)
  • Re: Xah on Lisp
    ... Lisp relies on a regular nested syntax. ... Whether the syntax "irregularities" due to the five mentioned characters ... You want me to define the power of a computer language? ...
    (comp.lang.lisp)
  • Re: C++ sucks for games
    ... have been shown Lisp code that is shorter than your C++ code. ... the Lisp syntax here scales very well ... That a language which you presumably rarely, ...
    (comp.lang.lisp)
  • Re: C++ sucks for games
    ... have been shown Lisp code that is shorter than your C++ code. ... the Lisp syntax here scales very well ... That a language which you presumably rarely, ...
    (comp.lang.cpp)
Loading