·········@yahoo.com (Nelson Marcelino) wrote in message news:<····························@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.
Such discussions don't do anything good for Haskell.
I'll try to clarify some things anyway.
Kaz Kylheku wrote:
> 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!
You may find it interesting:
David Espinosa, Semantic Lego,
http://www.swiss.ai.mit.edu/users/dae/papers/thesis.ps.Z
It can be interesting to know that Guy Steele wrote a paper on monads
using Haskell notation :)
http://citeseer.ist.psu.edu/steele94building.html
> 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!
I agree with you to some degree.
Knowing how to parse a language with infix operators can be essential,
but I don't consider it necessary to remembery operator precedence and
associativity of every programming language I use. I often insert
superfluous parentheses when I am not sure.
With Haskell I can even switch to prefix notation - every binary
operator can be used as a normal function, eg. you can write
((+) ((*) 1 2) 3)
instead of
1 * 2 + 3
The most important thing to know about precedence in Haskell is that
function application binds strongest.
> 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.
I think that of all non-lispy languages Haskell isn't the one that
deserves such critique. I'm sure that most Haskell's designers and
implementers know Lisp and appreciate its expressivity. However, they
try to achieve most of this expressivity in different ways, using
higher-order functions, monads, type-classes or laziness.
Of course some things you can do in Lisp are difficult or infeasible to
do in Haskell without meta-programming facilities. That's why we have
Template Haskell, an extension which allows to manipulate Haskell's
Abstract Syntax Trees at compile-time, just like in Lisp.
> 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.
That's your opinion. I find Haskell very suitable for many practical
tasks in my job. This includes various networking applications, CGI and
system scripting, text processing, parsing, data processing and others.
>> Why not have just one or two standard looping methods to accomplish
>> something?
OP missed that there are many ways to do looping in Haskell. You have
recursion, polymorphic recursion, higher-order functions for mapping,
folding, unfolding, looping in monadic context (like imperative loops),
lazy lists (can be used as generators and you can simulate unix pipes
with them), etc. Therefore the following critique doesn't apply to
Haskell.
>> With languages like Haskell flow of control is not an issue.
Same here - an oversimplification.
>> 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.
And here - Haskell doesn't force you to program in a declarative style.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
···@ashi.footprints.net (Kaz Kylheku) writes:
> 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!
This paper uses Scheme:
Jonathon Sobel, Erik Hilsdale, Kent Dybvig, and Dan Friedman.
"Abstraction and Performance from Explicit Monadic Reflection".
http://www.cs.indiana.edu/hyplan/jsobel/Parsing/explicit.ps
To motivate you, here's the first sentence:
"Much of the monadic programming literature gets the types right but
the abstraction wrong."
Helmut.
In article <··············@stud3.tuwien.ac.at>, Helmut Eller wrote:
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
>> 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!
>
> This paper uses Scheme:
>
> Jonathon Sobel, Erik Hilsdale, Kent Dybvig, and Dan Friedman.
> "Abstraction and Performance from Explicit Monadic Reflection".
> http://www.cs.indiana.edu/hyplan/jsobel/Parsing/explicit.ps
>
> To motivate you, here's the first sentence:
>
> "Much of the monadic programming literature gets the types right but
> the abstraction wrong."
That's not true, actually. See the discussion on the weblog Lambda the
Ultimate of this paper -- Oleg's comment is particularly informative.
<http://lambda.weblogs.com/discuss/msgReader$11342>
I tried to write a useful monad faq (using Scheme) a few months ago,
and posted it to comp.lang.functional.
<http://groups.google.com/groups?selm=slrnc3781u.oor.neelk%40gs3106.sp.cs.cmu.edu>
Be sure to read the whole thread, because there are some errors in
this message that got corrected in followups.
--
Neel Krishnaswami
·····@cs.cmu.edu
···@ashi.footprints.net (Kaz Kylheku) wrote:
> Formal verification of any real world program is impossible.
That's a strange thing to say when so many readers of this
newsgroup are using microprocessors whose arithmetic cores
have been verified by formal means.
> 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.
That seems like a odd thing to say about the purely functional
subset of Common Lisp known as ACL2.
> 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.
You're saying ACL2 hasn't found many applications?
> 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.
Not for all kinds of control constructs, but for some. Where
adequate, TAGBODY often works even better than more general
constructs such as CALL-WITH-CURRENT-CONTINUATION.
> I don't want some tool promoting something at me.
http://www.clueless.com/jargon3.0.0/tool.html
Will