Re: The importance and relevance of FP

[Jeffrey Straszhiem]

On Mon, Aug 21, 2000 at 10:28:41AM +0200, Ketil Malde wrote:

> Or just a mail server witout buffer overruns would be great. *Sigh*

Just this sort of thing is so often sugested as a proving ground for
all sorts of "fringe" languages.  I know it is frequently suggested on
both the Eiffel and Ada lists.  Yet it never seems to get done.

I think Haskell would be perfect for this task.  Perhaps for the beta
level project just focus on SMTP and local mail delivery, and not on
all the strange mail systems that sendmail endevors to cover.

Let's hear some thoughts on this.

-- 
-- Jeffrey Straszheim  |  A sufficiently advanced
-- Systems Engineer, Programmer|  regular expression is
-- http://www.shadow.net/~stimuli  |  indistinguishable from
-- stimuli AT shadow DOT net   |  magic

RE: The importance and relevance of FP

[Manuel M. T. Chakravarty]

Frank Atanassow <[EMAIL PROTECTED]> wrote,

> Sorry, I got carried away with my silly "hacker" post.
> 
> Manuel M. T. Chakravarty writes:
>  > Frank Atanassow <[EMAIL PROTECTED]> wrote, > Proposition > Hackers can like
>  > FP.  [..]  > Proof 1: > By contradiction.
>  > > 
>  > >   Nothing could be more obscure or esoteric to a hacker than FP. (They
>  > >   even seem to admit it themselves.)
>  > 
>  > I don't see the validity of this point.  Especially, given that much of
>  > todays hackerdom originated in the Lisp communities.  For example, when I
>  > talked with ESR about programming languages, he said that one of the things
>  > he misses in Python is fully-fledged lambda abstractions.
> 
> I was going to mention Stallman and Emacs; but by my
> definition Stallman was a guru, not a hacker...

I guess, the problem here is that by a hacker's definition
of a hacker, what you call a guru is a hacker - and many of
those that you call hackers are wannabees :-)

> ESR and RMS may like LISP, but clearly they aren't "converts" in the same
> sense as most of the list members here; Emacs and Guile aside, most of the
> code they produce seems to be in conventional languages.

I don't really agree with that.  RMS advocates C a lot for
systems projects, but that's largely because of the
portability issues and frankly, a language like Haskell in
its current form is about as unportable as it gets (ok, VB
is worse, but that's about it).

OSS programs often use Lisp-based extension languages:
Emacs, GIMP, Gnome has Guile support, the window manager
sawfish (formerly know as sawmill), and others.  Python also
gets more and more popular and it includes FP concepts.  In
fact, AFIK RMS advocates writing core programs in C and
adding a Lisp-based extension language to program the rest
(like with Emacs).

>  > > Of course, many hacker sapiens are something less than open-minded. You
>  > > only need to look at /. to convince yourself of that.
>  > 
>  > Never confuse wannabees
>  >  with the real
>  > thing.
> 
> OK, different names, same denotation. My "guru" is your "hacker"; my "hacker"
> is your "wannabee". Your hackers are still in the minority, and the
> proposition is that something needs to be done about convincing the masses. I
> was suggesting that if you hook the gurus, then the rest will follow.

Ok :-)

>  > > And if you _can't_ convince a guru and write better programs faster, then
>  > > maybe FP isn't so good after all... unless you plan on writing all the
>  > > world's programs yourself.
>  > [..]
>  > I think, the critical thing here is not outperforming existing
>  > applications, but saving time developing new applications.  If there is one
>  > thing a hacker hates, then it is wasting time on doing a job that could be
>  > done more efficiently[1] or repeatedly doing a job that could be automated.
>  > [..]
>  > [1] The exception is of course where doing the job is the
>  > end, not a means.
> 
> Not if the cost in efficiency is too high. The situation isn't that black and
> white. I really do believe that the imperative camp's valuation of the
> correctness vs. efficiency tradeoff is different.
> 
> 
> Also, I've observed many FP/LP people argue that slow or memory-hungry
> applications aren't such a big deal because "in 5 years, Moore's law will make
> them efficient."  The problem with this argument is that consumers and
> programmers don't reason this way. They don't say to themselves, "Now I have a
> shiny new computer, three times faster and with twice the memory of my old
> one. NOW I can run functional programs!" :) They say, "Now I have a shiny new
> computer, three times faster and with twice the memory of my old one. NOW I
> can run twice as many applications three times as fast!" As machines get
> better, program functionality also increases. "Perceived performance" seems to
> remain fairly constant, if you see what I mean.
> 

In the days of Java and Word, I think, the claim that users
expect fast programs doesn't cut it anymore.  They have long
ago given up.

Nevertheless - if I understand you correctly - I agree with
the core of your statement anyway: It is time to make
Haskell a practically useful language, rather than just a
beautiful language.  AFAIK now there is a substantial number
of people on this list who are working towards this goal.

Cheers,
Manuel

Re: The importance and relevance of FP

[Ketil Malde]

Frank Atanassow <[EMAIL PROTECTED]> writes:

> Also, I've observed many FP/LP people argue that slow or memory-hungry
> applications aren't such a big deal because "in 5 years, Moore's law will make
> them efficient."

No FP people would admit to producing slow and memory-hungry
applications! :-)

YMMV, but the only functional program that I find slow enough to be
bothersome, is GHC, and it is rather complex, and anyway uses GCC (or
so I gather).  Of course, I don't use that many.  I do use a lot  of
applications written in C++ or similar languages, though. 

> They say, "Now I have a shiny new computer, three times faster and
> with twice the memory of my old one. NOW I can run twice as many
> applications three times as fast!"

No, they say "NOW I might get Word to act fast enough to be as useful
as a typewriter once was".  (And then their IT guy upgrades Word.)  I
bet we lose more cycles due to unintelligent software, than we do to
garbage-collectors and laziness.

And there's plenty of software just aching to be written with a FPL.
Why not start making software *smart*?  Where's a grammar analyzer
that actually works?  For that matter, where's a program that
understands language semantics?  

Or just a mail server witout buffer overruns would be great. *Sigh*

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

RE: The importance and relevance of FP

[Frank Atanassow]

Sorry, I got carried away with my silly "hacker" post.

Manuel M. T. Chakravarty writes:
 > Frank Atanassow <[EMAIL PROTECTED]> wrote, > Proposition > Hackers can like
 > FP.  [..]  > Proof 1: > By contradiction.
 > > 
 > >   Nothing could be more obscure or esoteric to a hacker than FP. (They
 > >   even seem to admit it themselves.)
 > 
 > I don't see the validity of this point.  Especially, given that much of
 > todays hackerdom originated in the Lisp communities.  For example, when I
 > talked with ESR about programming languages, he said that one of the things
 > he misses in Python is fully-fledged lambda abstractions.

I was going to mention Stallman and Emacs; but by my definition Stallman was a
guru, not a hacker...

ESR and RMS may like LISP, but clearly they aren't "converts" in the same
sense as most of the list members here; Emacs and Guile aside, most of the
code they produce seems to be in conventional languages.

I should admit that I am not one of those people who feel we should be so
gung-ho about using different languages for different purposes, i.e., it may
be impractical to do otherwise now, but it's not a state of affairs we should
be perpetuating. The differences between languages within each paradigm
(imperative, FP, LP) are not very significant. Constructing a reasonably
"universal" language in each class is not that far outside our reach. And the
distinctions between each class are starting to break down too (witness
imperative monads). Even for very domain-specific languages, there are
substantial benefits to treating them in an internal fashion, and it's
becoming increasingly practical to do so (witness combinator-style libraries).

 > > Of course, many hacker sapiens are something less than open-minded. You
 > > only need to look at /. to convince yourself of that.
 > 
 > Never confuse wannabees
 >  with the real
 > thing.

OK, different names, same denotation. My "guru" is your "hacker"; my "hacker"
is your "wannabee". Your hackers are still in the minority, and the
proposition is that something needs to be done about convincing the masses. I
was suggesting that if you hook the gurus, then the rest will follow.

 > > And if you _can't_ convince a guru and write better programs faster, then
 > > maybe FP isn't so good after all... unless you plan on writing all the
 > > world's programs yourself.
 > [..]
 > I think, the critical thing here is not outperforming existing
 > applications, but saving time developing new applications.  If there is one
 > thing a hacker hates, then it is wasting time on doing a job that could be
 > done more efficiently[1] or repeatedly doing a job that could be automated.
 > [..]
 > [1] The exception is of course where doing the job is the
 > end, not a means.

Not if the cost in efficiency is too high. The situation isn't that black and
white. I really do believe that the imperative camp's valuation of the
correctness vs. efficiency tradeoff is different.


Also, I've observed many FP/LP people argue that slow or memory-hungry
applications aren't such a big deal because "in 5 years, Moore's law will make
them efficient."  The problem with this argument is that consumers and
programmers don't reason this way. They don't say to themselves, "Now I have a
shiny new computer, three times faster and with twice the memory of my old
one. NOW I can run functional programs!" :) They say, "Now I have a shiny new
computer, three times faster and with twice the memory of my old one. NOW I
can run twice as many applications three times as fast!" As machines get
better, program functionality also increases. "Perceived performance" seems to
remain fairly constant, if you see what I mean.


Rapid application development is not enough. There are imperative languages
for that already: Python, Perl, Tcl... They fit into the imperative mold, and
they seem to give imperative programmers the things they want. Probably Haskell
can provide equal benefits, but to convince people to change paradigms,
you need to provide quite substantial advantages _beyond_ that.

"Extraordinary claims require extraordinary evidence."

OK, enough ranting. All this is pretty incidental to Haskell, so, for the
benefit of others who have already been put off by the recent excess of
off-topic posts, I'll reply to any replies in e-mail, and you are all free to
sling mud at me, since I probably deserve it anyway...

-- 
Frank Atanassow, Dept. of Computer Science, Utrecht University Padualaan 14,
PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-1012, Fax +31
(030) 251-3791

RE: The importance and relevance of FP

[Manuel M. T. Chakravarty]

Frank Atanassow <[EMAIL PROTECTED]> wrote,

> D. Tweed writes:
>  > However, the issue that lots of the simple & productive ideas
>  > from FP are culturally alien & even suspect to programmers in other
>  > languages is very true. I write lots of stuff in C++ and the fact that I
>  > have functions returning two results return a pair rather than either
>  > a specially created class or a copy-into-reference-parameter, or that I
>  > use STL vectors/lists rather than writing inplace code using
>  > arrays/pointers elicits cries of `Yuck' & `Too weird'. And I agree that
>  > this is a real phenomenon/problem which may well lead to Haskell remaining
>  > a language that's scorned (in both senses) and runtime systems which make
>  > it difficult to do simple Haskell things.
> 
> [Written with tongue only halfway in cheek.]
> 
> I disagree. "They just don't get it" doesn't cut it anymore.
> 
> Proposition
>   Hackers can like FP.
[..]
> Proof 1:
>   By contradiction.
> 
>   Nothing could be more obscure or esoteric to a hacker than FP. (They even
>   seem to admit it themselves.)

I don't see the validity of this point.  Especially, given
that much of todays hackerdom originated in the Lisp
communities.  For example, when I talked with ESR about
programming languages, he said that one of the things he
misses in Python is fully-fledged lambda abstractions.

> Of course, many hacker sapiens are something less than open-minded. You only
> need to look at /. to convince yourself of that. 

Never confuse wannabees

with the real thing.

> And if you _can't_ convince a guru and write better programs faster, then
> maybe FP isn't so good after all... unless you plan on writing all the world's
> programs yourself.
> 
> Unfortunately, I don't see many FP programs that are better or faster than
> conventional ones. Those that are are incestuous: things like compilers and
> program analyzers for FP languages. Hackers don't need those yet. They need
> things like Manuel's Gtk interface, or Daan's DB interface. Then they need to
> see them in action, outperforming existing applications in some way.

I think, the critical thing here is not outperforming
existing applications, but saving time developing new
applications.  If there is one thing a hacker hates, then it
is wasting time on doing a job that could be done more
efficiently[1] or repeatedly doing a job that could be
automated.

Manuel

[1] The exception is of course where doing the job is the
end, not a means.

Re: The importance and relevance of FP

[Manuel M. T. Chakravarty]

Frank Atanassow <[EMAIL PROTECTED]> wrote,

> Manuel M. T. Chakravarty writes:
>  > Florian Hars <[EMAIL PROTECTED]> wrote,
>  > 
>  > > To cite the comments of Olof Torgersson on Haskell
>  > > (www.cs.chalmers.se/pub/users/oloft/Papers/wm96/wm96.html):
>  > > 
>  > >As a consequence the programmer loses control of what is really
>  > >going on and may need special tools like heap-profilers to find out
>  > >why a program consumes memory in an unexpected way. To fix the
>  > >behavior of programs the programmer may be forced to rewrite the
>  > >declarative description of the problem in some way better suited to
>  > >the particular underlying implementation. Thus, an important
>  > >feature of declarative programming may be lost -- the programmer
>  > >does not only have to be concerned with how a program is executed
>  > >but has to understand a model that is difficult to understand and
>  > >very different from the intuitive understanding of the program.
>  > 
>  > What's the problem with using a heap profiler?  Sure, heap
>  > usage can get out of hand when writing a straight forward
>  > maximally declarative (whatever that means) version of a
>  > program.  Is this a problem?  No.
> 
> One might argue analagously that C/C++ programmers ought to use tools like
> proof assistants and model checkers to help reason about
> the correctness of their programs. The fact is that, when
> we talk about the operational behavior or denotational
> semantics of a program, any reasoning "tool" which is _in_
> the language is preferable to a tool which is _outside_
> the language.
> 
> Thus, when correctness is the more important, it is better
> to use Haskell, the language constructs of which encourage
> (partial) correctness, than it is to use a C + a verifier;
> and when efficiency is more important, it is better to use
> C, the language constructs of which encourage efficiency,
> rather than Haskell + profiling tools.

I don't completely agree, because I think the situation is
not as symmetric as you pciture it.  Of course, all
languages have their strengths and I personally have not the
slightest problem coding in C when I think C is more
appropriate for the job than Haskell.

However, I would claim that in your average program, rapid
prototyping and correctness first are winning over
efficiency first.  I think that this position is backed by
current software engineering principles.

>  > The trick about a language like Haskell is that you get to a
>  > working prototype of your program extremely quickly.  Then,
>  > you can improve performance and, eg, use a heap profiler to
>  > find the weak spots and rewrite them.  And yes, then, I
>  > usually lose the pure high-level view of my program in
>  > theses places in the code.
> 
> I would rather not lose it at all, by expressing the operational behavior
> which I demand in a declarative fashion. This is, IMO, part of the reason why
> notions such as monads (and linearity) are valuable: they give you some
> measure of control over operational details without sacrificing the "pure
> high-level view".

Nevertheless, optimising a program usually means imposing
more and more control taking into account operational
aspects of the program.  I am all for expressing this
additional control as nicely as possible, but ultimately it
means breaking abstraction levels.

>  > This is still a *lot* better then not having the high-level
>  > view at all and taking much longer to get the first working
>  > version of my program (even if it is already more efficient
>  > at that point).  I don't know about you, but I rather have
>  > 90% of my program in a nice declarative style and rewrite
>  > 10% later to make it efficient, then having a mess
>  > throughout 100% of the program.
> 
> A problem, as I see it, is that, although compilers like GHC do an admirable
> job of optimizing away the overhead of laziness, etc. in many circumstances,
> you can't be sure. You can use profiling tools and such after writing
> my code, but sometimes the changes that need to be made can be far-reaching,
> and you'll wish you had short-circuited this cycle in the first place.

I agree.  At some point a developer with a good intuition of
where the hot spots of the program will probably be and a
forward thinking design will always win.  But, I think, this
is true for every language.

> A lot of people who program extensively in Haskell have a good
> understanding of the underlying abstract machine, and can anticipate the
> changes that need to be made, or at least ensure that they are
> localized. For example, they know "tricks" like ways to increase laziness;
> when I see messages like Florian's, I am reminded that such tricks can be
> relatively obscure.
>
> In short, the problem is that in a language such as Haskell without a
> high-level abstract operational semantics, you don't see
> all the benefits of a declarative style, since, as far as
> efficiency

RE: The importance and relevance of FP

[Frank Atanassow]

D. Tweed writes:
 > However, the issue that lots of the simple & productive ideas
 > from FP are culturally alien & even suspect to programmers in other
 > languages is very true. I write lots of stuff in C++ and the fact that I
 > have functions returning two results return a pair rather than either
 > a specially created class or a copy-into-reference-parameter, or that I
 > use STL vectors/lists rather than writing inplace code using
 > arrays/pointers elicits cries of `Yuck' & `Too weird'. And I agree that
 > this is a real phenomenon/problem which may well lead to Haskell remaining
 > a language that's scorned (in both senses) and runtime systems which make
 > it difficult to do simple Haskell things.

[Written with tongue only halfway in cheek.]

I disagree. "They just don't get it" doesn't cut it anymore.

Proposition
  Hackers can like FP.

We give two proofs. First, a lemma.

Lemma
  Hackers like weird, obscure, esoteric, complicated stuff.
Proof:
  We exhibit a witness.

  Consider *NIX. Now there is a big sprawling mess of complicated
  interdependent gobbledygook if ever I saw one. And yet it attracts those
  critters like honey.

Back to our proposition.

Proof 1:
  By contradiction.

  Nothing could be more obscure or esoteric to a hacker than FP. (They even
  seem to admit it themselves.)

  Therefore, by the lemma, hackers can potentially like FP. QED.

Proof 2:
  Compared to *NIX, Haskell is cake. A simple functional language can
  be axiomatized in a few lines. There are concrete rules for reasoning about
  it. There are tangible implementations. That's more than enough.

  Therefore, hackers can like FP. QED.

Of course, many hacker sapiens are something less than open-minded. You only
need to look at /. to convince yourself of that. But their weakness is their
fawning admiration of hacker superioris, i.e., gurus and other gung-ho
gift-giving go-getters.

Now, a guru may not know much about adjunctions or omega-CPOs, but gurus are
typically rather open-minded (cause or effect?)---if it gets results, they'll
use it. So, to convert a guru, you need to show them some concrete results. So
write some useful applications, write them fast, write them well, show them to
a guru, and show the guru how to do it too. Then you'll convert the gurus;
convert gurus, and you'll convert their flock. Convert the flock and you're
halfway home. (Just look at the recent announcements about the GNOME
Foundation.)

[Musical interlude:

  You can't change the world
  But you can change the facts
  And when you change the facts
  You change points of view
  If you change points of view
  You may change a vote
  And when change a vote
  You may change the world.
-- Depeche Mode ("New Dress")
]

And if you _can't_ convince a guru and write better programs faster, then
maybe FP isn't so good after all... unless you plan on writing all the world's
programs yourself.

Unfortunately, I don't see many FP programs that are better or faster than
conventional ones. Those that are are incestuous: things like compilers and
program analyzers for FP languages. Hackers don't need those yet. They need
things like Manuel's Gtk interface, or Daan's DB interface. Then they need to
see them in action, outperforming existing applications in some way.

Of course, IANAH (I Am Not A Hacker) so you may take my hypocritical remarks
with a grain of salt or three.

-- 
Frank Atanassow, Dept. of Computer Science, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-1012, Fax +31 (030) 251-3791

Re: The importance and relevance of FP

[Frank Atanassow]

Manuel M. T. Chakravarty writes:
 > Florian Hars <[EMAIL PROTECTED]> wrote,
 > 
 > > To cite the comments of Olof Torgersson on Haskell
 > > (www.cs.chalmers.se/pub/users/oloft/Papers/wm96/wm96.html):
 > > 
 > >As a consequence the programmer loses control of what is really
 > >going on and may need special tools like heap-profilers to find out
 > >why a program consumes memory in an unexpected way. To fix the
 > >behavior of programs the programmer may be forced to rewrite the
 > >declarative description of the problem in some way better suited to
 > >the particular underlying implementation. Thus, an important
 > >feature of declarative programming may be lost -- the programmer
 > >does not only have to be concerned with how a program is executed
 > >but has to understand a model that is difficult to understand and
 > >very different from the intuitive understanding of the program.
 > 
 > What's the problem with using a heap profiler?  Sure, heap
 > usage can get out of hand when writing a straight forward
 > maximally declarative (whatever that means) version of a
 > program.  Is this a problem?  No.

One might argue analagously that C/C++ programmers ought to use tools like
proof assistants and model checkers to help reason about the correctness of
their programs. The fact is that, when we talk about the operational behavior
or denotational semantics of a program, any reasoning "tool" which is _in_ the
language is preferable to a tool which is _outside_ the language.

Thus, when correctness is the more important, it is better to use Haskell, the
language constructs of which encourage (partial) correctness, than it is to
use a C + a verifier; and when efficiency is more important, it is better to
use C, the language constructs of which encourage efficiency, rather than
Haskell + profiling tools.

For me, correctness is almost always paramount, but clearly some people feel
differently, or we would not be so ubiquitously plagued with buggy free and
commercial software, hardly any of which is written in declarative languages.

 > The trick about a language like Haskell is that you get to a
 > working prototype of your program extremely quickly.  Then,
 > you can improve performance and, eg, use a heap profiler to
 > find the weak spots and rewrite them.  And yes, then, I
 > usually lose the pure high-level view of my program in
 > theses places in the code.

I would rather not lose it at all, by expressing the operational behavior
which I demand in a declarative fashion. This is, IMO, part of the reason why
notions such as monads (and linearity) are valuable: they give you some
measure of control over operational details without sacrificing the "pure
high-level view".

Of course, some fiddling is always needed...

 > This is still a *lot* better then not having the high-level
 > view at all and taking much longer to get the first working
 > version of my program (even if it is already more efficient
 > at that point).  I don't know about you, but I rather have
 > 90% of my program in a nice declarative style and rewrite
 > 10% later to make it efficient, then having a mess
 > throughout 100% of the program.

A problem, as I see it, is that, although compilers like GHC do an admirable
job of optimizing away the overhead of laziness, etc. in many circumstances,
you can't be sure. You can use profiling tools and such after writing
my code, but sometimes the changes that need to be made can be far-reaching,
and you'll wish you had short-circuited this cycle in the first place.

A lot of people who program extensively in Haskell have a good
understanding of the underlying abstract machine, and can anticipate the
changes that need to be made, or at least ensure that they are
localized. For example, they know "tricks" like ways to increase laziness;
when I see messages like Florian's, I am reminded that such tricks can be
relatively obscure.

In short, the problem is that in a language such as Haskell without a
high-level abstract operational semantics, you don't see all the benefits of a
declarative style, since, as far as efficiency goes, we have only replaced the
conventional programmer's mental model of a traditional machine architecture,
with a more esoteric model which is some fuzzy idea of a lazy abstract
machine. The abstract machine may be simpler, but you still can't reason about
it in a formal way if it's not a part of the standard. The best you can do is
go off and read some papers, written by researchers for researchers, which
describe a lazy machine, and take a guess that your particular implementation
uses much the same thing. And hardly anyone will bother to go that far.

-- 
Frank Atanassow, Dept. of Computer Science, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-1012, Fax +31 (030) 251-3791

RE: The importance and relevance of FP

[John Hörnkvist]

D. Tweed wrote:
> On Fri, 18 Aug 2000, Doug Ransom wrote:
>
> > I do believe FP is current 90 degrees out of phase with OO.  I  
think the
> > isue with tuples, lists, conses, etc. it the big problem.  I  
currently see
> > no way for someone to write a clever matrix library in Haskell  
and have it
> > seamlessly integrate into the NGWS framework (the new object type and 
> > runtime system from MS likely here to stay for a long long time)  
and C#, VB,
> > etc.  The  impedance mismatch is just too high.
>
> I can't quite see why you say (at least twice) `is 90 degrees out  
of phase
> with OO' rather than `90 degrees out of phase with lots of  
assumptions &

I think there are two interpretations on what makes up an object  
oriented system; the interpretation founded in Simula, and the  
interpretation founded in Smalltalk. IIRC, the term object  
orientation was coined by Alan Kay, in reference to Smalltalk.

The great difference between object oriented languages with static  
method dispatch, like C++, and Java to some extent, and languages  
with dynamic method dispatch, such as Smalltalk, Objective-C and TOM,  
is vast --- but you have to be experienced in designing for such  
languages to notice the difference.

As far as I can see, using a state monad makes it possible to create  
a static object oriented language within Haskell. Haskell++ is an  
example of this.

However, the gap between Haskell and dynamic object oriented  
languages is much greater. The existence of a universal object type  
(id or Any) is central to the design paradigm of such languages ---  
collections of anonymous objects would be impossible without them.

Another issue is composition, an example of which is delegation:

- (void) forwardInvocation:(NSInvocation*) invocation
{
if ([delegate respondsToSelector:[invocation selector]])
{
[invocation invokeWithTarget:delegate];
}
else
[super forwardInvocation:invocation];
}
forwardInvocation is the method which gets called when an object  
gets send a message for a method that it doesn't implement. Here we  
can do error handling, in this case we check if our delegate  
implements the method, and in that case, we let the delegate handle  
the method.

A delegate is normally typed as
id delegate;
which means that it can be an instance of any class, or
id delegate;
which means that it can be any object responding to the methods in  
MyDelegateProtocol.

An example of objects using a delegate is a user interface window;  
it lets the delegate get final say on actions such as closing,  
resizing and so forth.

Another design pattern which becomes difficult without dynamic  
dispatch and object references is notification:
[[NSNotificationCenter defaultCenter] addObserver:self  
selector:@selector(handleWindowClosed:)  
name:NSWindowDidCloseNotification
object:nil];
This pattern lets an object observe, and react to, the actions of  
other objects without having to be directly aware of these objects.

Another example is action/target based user interface modelling:
[button setTarget:anObject action:@selector(buttonPressed:)];
Now, when pressed, the button object will invoke the buttonPressed:  
method of the object referred to by anObject. Since the action/target  
information part of the state of the object, rather than part of the  
program, we can trivially load user interfaces from at run time.

Dynamic dispatch also allows us to extend and amend objects without  
subclassing, we can just replace one method implementation with  
another at run time, as well as add methods to objects. TOM even  
allows adding instance variables at run time. Of course these  
abilities create new ways to wreck havoc, but it does not really  
matter once you have an imperative system.

Features such as these greatly simplify the design of flexible,  
loosely coupled and easily maintained systems.

Much as I like Haskell --- I write a lot of Haskell code and am very  
pleased with it, for a certain set of problems --- I'd think twice  
about writing a word processor in it --- although I'd consider  
writing the glyph layout algorithm in it.

Haskell could conceivably replace C++ and similar languages --- it  
probably comes down to improving compilers, creating a wealth of  
reusable libraries, and providing cook-book solutions.

However, getting Haskell to a point where it can compete with the  
ease of design of dynamic object oriented languages is another  
matter. O'Haskell's reactive object's get you part of the way, but  
nowhere near far enough.

Regards,
John Hörnkvist

--
ToastedMarshmallow, the perfect Cocoa companion
http://www.toastedmarshmallow.com

Re: The importance and relevance of FP

[Claus Reinke]

Tom Pledger:
> Florian Hars writes:
>  > efficiency improving no-ops like (fst (head x), snd (head x)): tail
>  > x !" (By the way, can anyone explain this section to me?)
..
> The (fst (head x), snd (head x)) : tail x construction assures the run
> time system that a parser for zero or more `a's is infallible

And this extra assurance tells us that we are not exactly talking about 
no-ops. Let me simplify the example a bit:

f :: (a,b) -> c
f x = .. x ..

g :: (a,b) -> (a,b)
g x = (fst x, snd x)

Both f and f.g operate on pairs - this seems to be guaranteed by the 
type system. But Haskell's type system only makes a slightly weaker 
guarantee for f, also referred to as partial correctness: if f's parameter 
is ever successfully computed, it will be a pair. In practice, the 
evaluation of f's parameter might fail to terminate, or terminate 
exceptionally (outside the expected type, by throwing an exception).

In these conditions, g is not quite a no-op: it takes a parameter that
will not normally be anything other than a pair and returns a result
that will (almost) definitely be a pair (almost, because the construction
of the result could still run out of resources). This still doesn't safeguard 
against resource problems or other exceptional conditions, but it does
safeguard against non-termination: if g's parameter fails to evaluate
successfully (is equivalent to bottom), then the components of g's 
result will not become available, but g's result will still be a pair.

This, in turn, can have an effect on the body of f: if some computation
in f's body (that is needed for the result) depends only on the structure 
of its parameter x, then the evaluation of (f x) will depend on the
evaluation of x, at least far enough to reveal the structure of x. 

In contrast, the evaluation of (f (g x)), under the same dependencies,
will not require the evaluation of x, because g guarantees the structure
of x to be that of a pair. This helps to decouple the evaluation of f from
that of its parameter, without otherwise changing the dataflow. Taking 
a more concrete example:

x :: (a,b) -- not quite a pair, but not anything else, either ;-)
x = x 

f :: (a,b) -> IO ()
f x = case x of { (_,_) -> print "hooray!" }

i :: (a,b) -> (a,b)
i x = x

g :: (a,b) -> (a,b)
g x = (fst x, snd x)

mainA = f (i x)

mainB = f (g x)

This should demonstrate the difference between no-ops and the
kind of constructions used for program optimizations. Both i and g
are identities, as far as their types can tell us, but they differ for
things at the borderline between promised structure and computed
structure, if that makes any sense.

Statically, the type (a,b) promises a pair without any guarantee that
a pair will be computed. Operationally, (g x) promises a pair before 
checking whether x actually evaluates to a pair. If it does, g is just 
an identity, but if it doesn't, g delivers more information than it gets. 
This is the source of the decoupling effect.

If we change f slightly, 

f' :: (Show a,Show b) => (a,b) -> IO ()
f' x = case x of { (a,b) -> do {print "hooray!";print a;print b} }

(and restrict x's type, to (Bool,Bool) say,) we get an example of 
how this decoupling of f' and x, via g, can influence resource usage. 
In (f' x), nothing can be done in the body of f' before x evaluates to
a pair, so everything in f' has to be put on hold until the evaluation of
x starts to deliver. In (f' (g x)), on the other hand, parts of the body 
can be executed, and their resources reclaimed, before the rest of 
the body demands the evaluation of x.

Others have mentioned that old equation: algorithm = logic + control.
One could say that non-no-ops, such as g above, allow us to add
control information without changing a working logic. 

My personal opinion in that matter is that FPLs enable us to focus 
on the logic aspect, but that we have neglected to provide good 
support for the other aspect of working programs. Working 
heap-profilers and work on operational semantics that permit the 
prediction of resource usage are good signs, showing that some 
researchers are working on this second aspect. 

What I'm not so sure about is how to make use of these results.
Rewriting programs to modify their control aspects mixes control
and logic aspects again. As Manuel said, that is better not having 
the choice at all. But I would prefer if I could specify both aspects
separately and then specify how they are to be combined into a
working program.

> Regards,
> a working Informix-4GL programmer  :-)

Ha! Living proof that there is hope for real-world programmers :-)

In rephrasing your answer, I didn't quite use all the technical terms 
you expected, so perhaps there's hope for us academics as well?-)


I don't want to get into the propagandistic aspects of this thread,
but earlier instances of this discussion (yes, there have been a few)
left one important message behind: 

* stop discussing why FP isn't used by others for all their projects, 
* star

RE: The importance and relevance of FP

[D. Tweed]

On Fri, 18 Aug 2000, Doug Ransom wrote:

> I do believe FP is current 90 degrees out of phase with OO.  I think the
> isue with tuples, lists, conses, etc. it the big problem.  I currently see
> no way for someone to write a clever matrix library in Haskell and have it
> seamlessly integrate into the NGWS framework (the new object type and
> runtime system from MS likely here to stay for a long long time) and C#, VB,
> etc.  The  impedance mismatch is just too high.

I can't quite see why you say (at least twice) `is 90 degrees out of phase
with OO' rather than `90 degrees out of phase with lots of assumptions &
attitudes prevailing in mainstream (imperative) programming', and surely
that's the big problem? I'm just pointing this out because I do believe
that (de-hyped) OO is a useful & productive way of programming some kinds
of thing, and that both type classes and the object oriented haskell
extensions (nb: only read the reports, not actually progammed with
these firsthand) are useful for solving problems using Haskell.

However, the issue that lots of the simple & productive ideas
from FP are culturally alien & even suspect to programmers in other
languages is very true. I write lots of stuff in C++ and the fact that I
have functions returning two results return a pair rather than either
a specially created class or a copy-into-reference-parameter, or that I
use STL vectors/lists rather than writing inplace code using
arrays/pointers elicits cries of `Yuck' & `Too weird'. And I agree that
this is a real phenomenon/problem which may well lead to Haskell remaining
a language that's scorned (in both senses) and runtime systems which make
it difficult to do simple Haskell things.

But unless I'm missing something, this has nothing in particular to do
with OO. (I may well be: I know nothing of NGWS)

___cheers,_dave
www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law:  however many computers
email: [EMAIL PROTECTED] |you have, half your time is spent
work tel: (0117) 954-5250  |waiting for compilations to finish.

Re: The importance and relevance of FP

[Tom Pledger]

Florian Hars writes:
 > [...] Show me any working programmer who reads the "Improving
 > laziness"-part in the Hutton/Meijer paper on monadic parser
 > combinators and says "Oh! What an elegant language! And these nifty
 > efficiency improving no-ops like (fst (head x), snd (head x)): tail
 > x !" (By the way, can anyone explain this section to me?)

Rather than a no-op, I prefer to think of it as a chiropractor: it
fixes up the spine.

In general, a parser may fail, which Hutton and Meijer represent by an
empty list of possible parses.  However, a parser which recognises
zero or more `a's - with the help of some other parser which
recognises exactly one `a' - is infallible.  It can always return
[([], s)] where s is the entire input string it was given, meaning "I
successfully found zero `a's."

The overly strict parse of zero or more `a's has this structure:

do { x  <- p;
 xs <- (
  do { x  <- p;
   xs <- (
--etc.
 );
   return (x:xs) } +++ return []
   );
 return (x:xs) } +++ return []

where p is a parser which recognises exactly one `a', and p1 +++ p2
means "return the first possible parse from p1 if p1 succeeds,
otherwise the first possible parse from p2."  In this case, the x <- p
part may fail (because there isn't an `a' next in the input) but the
return [] part always succeeds.

This is overly strict because the spine of the expression, which
contains all the (+++) nodes, must be evaluated before the run time
system can (reasonably be expected to) determine the outermost
data constructor in the resulting list of possible parses.

The (fst (head x), snd (head x)) : tail x construction assures the run
time system that a parser for zero or more `a's is infallible.  It
works because the outermost (+++) is now of the form

Foo (_:_) +++ Foo []

instead of

Foo _ +++ Foo []

where Foo stands for some additional structure which doesn't affect
the strictness issue, and _ stands for an expression node which is not
necessarily a data constructor.

To express the same hint even more niftily, we'd need to be able to
express laws like "for all p, p +++ return [] is infallible."

Terminology: Someone more confident with the terms WHNF, closure,
suspension and thunk, could probably have used them in an explanation,
where I've resorted to waffling.  If I've used terms like spine
inappropriately, will someone please say so (and explain)?

Regards,
a working Informix-4GL programmer  :-)

Re: The importance and relevance of FP

[Manuel M. T. Chakravarty]

Florian Hars <[EMAIL PROTECTED]> wrote,

> To cite the comments of Olof Torgersson on Haskell
> (www.cs.chalmers.se/pub/users/oloft/Papers/wm96/wm96.html):
> 
>As a consequence the programmer loses control of what is really
>going on and may need special tools like heap-profilers to find out
>why a program consumes memory in an unexpected way. To fix the
>behavior of programs the programmer may be forced to rewrite the
>declarative description of the problem in some way better suited to
>the particular underlying implementation. Thus, an important
>feature of declarative programming may be lost -- the programmer
>does not only have to be concerned with how a program is executed
>but has to understand a model that is difficult to understand and
>very different from the intuitive understanding of the program.

What's the problem with using a heap profiler?  Sure, heap
usage can get out of hand when writing a straight forward
maximally declarative (whatever that means) version of a
program.  Is this a problem?  No.

The trick about a language like Haskell is that you get to a
working prototype of your program extremely quickly.  Then,
you can improve performance and, eg, use a heap profiler to
find the weak spots and rewrite them.  And yes, then, I
usually lose the pure high-level view of my program in
theses places in the code.

This is still a *lot* better then not having the high-level
view at all and taking much longer to get the first working
version of my program (even if it is already more efficient
at that point).  I don't know about you, but I rather have
90% of my program in a nice declarative style and rewrite
10% later to make it efficient, then having a mess
throughout 100% of the program.

Cheers,
Manuel

RE: The importance and relevance of FP

[Doug Ransom]

I do 
believe FP is current 90 degrees out of phase with OO.  I think the isue 
with tuples, lists, conses, etc. it the big problem.  I currently see no 
way for someone to write a clever matrix library in Haskell and have it 
seamlessly integrate into the NGWS framework (the new object type and runtime 
system from MS likely here to stay for a long long time) and C#, VB, etc.  
The  impedance mismatch is just too high.
 
I 
think it is really far fetched to expect tuples, lists, etc. to be mainstream in 
an environment like NGWS -- the C#/Java/VB languages are just not going to make 
that step.  NGWS will just provide a cool runtime for Haskell to sit 
on, but Haskell will still be off in its own little corner.
 
 
 
 
 
 
 

  -Original Message-From: Jacques Lemire 
  [mailto:[EMAIL PROTECTED]]Sent: Tuesday, August 15, 2000 2:24 
  PMTo: haskellSubject: The importance and relevance of 
  FP
  Mr Rawson wrote:
   
  =
  However, almost no one is even thinking about 
  FP.  I think NGWS willbe the kiss of death for FP in the large -- OO 
  just seems 90 degrees out ofphase with FP.  
  =
   
  On the contrary,  languages like C++ (and 
  Java) and C#  are full of concepts and ideas coming from FP 
  languages.
  For example, the catch/try/throw construct is 
  coming directly from Common Lisp (Lisp is a (although impure) FP 
  language).
   
  I would n  ot be a bit suprise to see tuples, 
  lists and cons(es) introduce in the next generation of languages.
   
  FP languages are to VB or C++ what F1 cars are to 
  a Chevrolet or Diesel trucks.  You don't get a liter of milk with a F1 
  car!
   
  Moreover, OO is only one way of doing things: it 
  is amazing the numbers of projects (and working) that are *not* 
  programmed
  with C++. If you what to see the limitations of 
  OO and C++, take a look at the MFC, MFC architects had to introduce 
  macros.
   
  Jacques Lemire
  [EMAIL PROTECTED]
   

Re: The importance and relevance of FP

[Reuben Thomas]

> As another example, compare the propaganda version of quicksort in
> Haskell with a more realistic tail recursive one.

I remember thinking "wow!" when I first saw the Gentle Introduction
version of quicksort, then "hang on...that's not quicksort!". Whatever
happened to in-place update (one of the points of it, I thought), and can
I really be sure this will have the time behaviour I expect?

> Then you will only have to overcome the problem that most people are
> already hard pressed to understand functions as mappings from real
> numbers to real numbers, let alone as mappings from one function space
> to another.

This is a false problem, or rather, it's a question of presentation.
Most Haskell programmers know little category theory, but are quite happy
with monads. I find all sorts of problems that neophyte friends of mine
have (e.g. scientists who have to script a little for data collection and
analysis) that are down to arbitrary and stupid features of conventional
languages (C-like, BASIC-like) that would go away in a nice language (such
as Lua or Haskell; I'm not being FP-partisan here).

Personally, I find the source code for GHC much easier to read for being
written in Haskell, though of the three virtues I'm about to list, only
one is essentially FP: structurally based (pattern matching),
referentially transparent, syntactically clean. It bears a striking
resemblance to Martin Richards's BCPL compiler, written in BCPL (but my
initial reaction to the latter was "ugh, how verbose", because it's not a
style that BCPL supports elegantly; it's much better in MCPL).

-- 
http://sc3d.org/rrt/ | maxim, n.  wisdom for fools

Re: The importance and relevance of FP

[Florian Hars]

Doug Ransom <[EMAIL PROTECTED]> writes:
> none will miss spending a couple of weeks at the end of the
> development cycle trying to find a memory leak.

Apart from the fact that they are called space leaks, a lazy
functional language will not help them with this problem. It may
rather aggravate it by hiding the leaks in very wierd places. Show me
any working programmer who reads the "Improving laziness"-part in the
Hutton/Meijer paper on monadic parser combinators and says "Oh! What
an elegant language! And these nifty efficiency improving no-ops like
(fst (head x), snd (head x)): tail x !" (By the way, can anyone
explain this section to me?)

To cite the comments of Olof Torgersson on Haskell
(www.cs.chalmers.se/pub/users/oloft/Papers/wm96/wm96.html):

   As a consequence the programmer loses control of what is really
   going on and may need special tools like heap-profilers to find out
   why a program consumes memory in an unexpected way. To fix the
   behavior of programs the programmer may be forced to rewrite the
   declarative description of the problem in some way better suited to
   the particular underlying implementation. Thus, an important
   feature of declarative programming may be lost -- the programmer
   does not only have to be concerned with how a program is executed
   but has to understand a model that is difficult to understand and
   very different from the intuitive understanding of the program.

As another example, compare the propaganda version of quicksort in
Haskell with a more realistic tail recursive one.

If you want to increase the popularity of functional languages, remove
the possibility of unintended space leaks and the necessity to
make algorithms tail recursive manually (or solve the traveling
saleperson problem in O(n)). Then you will only have to overcome the
problem that most people are already hard pressed to understand
functions as mappings from real numbers to real numbers, let alone as
mappings from one function space to another.

Yours, Florian.

Re: The importance and relevance of FP

[Andrei Errapart]

On Thu, 17 Aug 2000, Craig Dickson wrote:
[]
> With such optimism about programmers, I'm astounded that you're writing from
> a .com rather than a .edu address. :-) My experience in industry has led me
> to quite different conclusions. Many C/C++ programmers seem not to recognize
> pointer issues as a problem, or at least, one with a viable solution;
> when offered languages with built-in GC, they say things like, "I like doing my
> own memory management; it gives me more control and makes it clearer what's
> really going on in the program." As I pointed out in a previous message,
> most of these people can't really handle the power that this "more control"
> gives them, but they have a blind spot that prevents them from recognizing
> that this is a problem.

I believe that stagnacy is more widespread than creativity and logical
thinking, too :(

That said, you don't have to use pointers in C++ that much. Legacy code
can be a problem, though. Besides, I think the management should be blamed
for that, too. They should listen to programmers and pay attention to
_recurrent_ problems.

Anyway, that my-language-is-better-than-yours war is ridiculous. But it
certainly pointed out one fact: a FPL isn't the first programming language
for most FP people!

Andrei

Having worked for poor management, they no longer value their jobs.
---
Geoffrey James, "Tao of Programming".

Re: The importance and relevance of FP

[Ralf Muschall]

Richard <[EMAIL PROTECTED]> writes:

> They still live in Emacs.  (Emacs Lisp's variables are dynamically scoped.)

OK. I tend to forget about this one, since I'm using it every day
(and use the macro "lexical-let" unless I am sure that no evil things
will happen).

Ralf

Re: The importance and relevance of FP

[Craig Dickson]

Doug Ransom wrote:

> I think you are mistakening ignorance for stupidity.  It
> is true that C/C++ programmers like to write OO and few
> have any idea about functional programming, but very few
> will miss the ability to constantly shoot themselves in
> the foot with uninitalized random pointers, weird memory
> access errors, and none will miss spending a couple of
> weeks at the end of the development cycle trying to find
> a memory leak.

With such optimism about programmers, I'm astounded that you're writing from
a .com rather than a .edu address. :-) My experience in industry has led me
to quite different conclusions. Many C/C++ programmers seem not to recognize
pointer issues as a problem, or at least, one with a viable solution; when
offered languages with built-in GC, they say things like, "I like doing my
own memory management; it gives me more control and makes it clearer what's
really going on in the program." As I pointed out in a previous message,
most of these people can't really handle the power that this "more control"
gives them, but they have a blind spot that prevents them from recognizing
that this is a problem.

Craig

RE: The importance and relevance of FP

[Doug Ransom]

> 
> If C# again makes it easy to write unsafe code, then in order 
> to avoid the learning curve, many current C/C++ programmers 
> are likely to continue programming in The Old Way.  The trick 
> lies in the learning curve.
> 

I think you are mistakening ignorance for stupidity.  It is true that C/C++
programmers like to write OO and few have any idea about functional
programming, 
but very few will miss the ability to constantly shoot themselves in the
foot with uninitalized random pointers, weird memory access errors, and none
will miss spending a couple of weeks at the end of the development cycle
trying to find a memory leak.  

Doug Ransom


> --Ben
> --
> Benjamin L. Russell
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> "Furuike ya!  Kawazu tobikomu mizu no oto."  --Matsuo Basho
> 

Re: The importance and relevance of FP

[Frank Atanassow]

Ralf Muschall writes:
 > > simplistic, binary distinction), then you have to decide where to draw the
 > > line between "functional languages" and other languages that may, to some
 > 
 > I think it became impossible to draw that line since the inventors
 > and maintainers of dysfunctional langauges learned that FP is cool
 > and added closures etc. (Perl has them since 5.001m, Javascript
 > since 1.2, just to mention a few).

First, you might well include first-order (algebraic) languages in your
definition of "functional".

Second, if your language has a semantics, it is not very hard to draw a
distinction: you just have to show an appropriate embedding of
lambda-calculus.

If your language has no semantics, then you are in for a world of trouble
anyway, and the question of whether your language is (higher-order) functional
will be the least of your worries.

-- 
Frank Atanassow, Dept. of Computer Science, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-1012, Fax +31 (030) 251-3791

Re: The importance and relevance of FP

[Lars Henrik Mathiesen]

> From: Ralf Muschall <[EMAIL PROTECTED]>
> Date: 16 Aug 2000 21:46:44 +0200

> "Craig Dickson" <[EMAIL PROTECTED]> writes:
> > simplistic, binary distinction), then you have to decide where to
> > draw the line between "functional languages" and other languages
> > that may, to some
> 
> I think it became impossible to draw that line since the inventors
> and maintainers of dysfunctional langauges learned that FP is cool
> and added closures etc. (Perl has them since 5.001m, Javascript
> since 1.2, just to mention a few).

Yes, but in Perl at least you have to call a closure, or any function
passed as a parameter, with a different syntax than a function defined
at top level. To my taste, that's an important difference from 'real'
functional languages. (Emacs Lisp wouldn't be a functional language
either by this criterion).

Lars Mathiesen (U of Copenhagen CS Dep) <[EMAIL PROTECTED]> (Humour NOT marked)

Re: The importance and relevance of FP

[Benjamin Leon Russell]

On Wed, 16 Aug 2000 08:13:16 -0700
 "Craig Dickson" <[EMAIL PROTECTED]> wrote:
> 
> 
> Ketil Z. Malde wrote:
> 
> > : functions, while pretty first class objects, reside
> in
> >   their own namespace, and need special operators.
> > : iteration and side effects are not particularly
> discouraged,
> >   and is probably as common as recursion and purity in
> actual
> >   code.
> 
> I agree, and would add (if I'm recalling correctly) that
> LISP lacks lexical
> scoping, which may not be an absolute requirement for
> functional programming
> but certainly enhances it, and is a common feature of
> functional languages.

Actually, I meant "lexical scoping" when I mentioned "closure properties" earlier (in 
comparing CL and Scheme--again, another reason to keep my copy of _Structure and 
Interpretation of Computer Programs,_ by Abelson, Sussman, and Sussman, around at all 
times :-) ).

> Friedrich Dominicus wrote:
> 
> > But saying Lisp isn't functional (to some extend) is
> > simply not true.
> 
> Well, it's that "to some exten[t]" that is the crux here,
> I think. If you
> are going to say that LISP "is" or "is not" a functional
> language (an overly
> simplistic, binary distinction), then you have to decide
> where to draw the
> line between "functional languages" and other languages
> that may, to some
> degree, include support for functional programming. LISP
> has much more
> support for FP than C++ or Perl, but not as much as
> Scheme, which in turn is
> less "pure" than Haskell or Erlang. So whether you want
> to say that it "is"
> functional or not is just a matter of where you draw the
> line. Scheme, which
> is undeniably more "functional" than LISP, is about the
> least purely
> functional language I would call "functional". So that's
> where I draw the
> line. Your mileage may vary.

One measure of functionality may also be how languages tend to be used.

At least where I studied it, Scheme usage tended to emphasize functional programming 
and de-emphasize side-effects more than CL usage.

Haskell usage emphasized functional programming even more than Scheme.

>From what I've seen, language usage tends to be based on two factors:

  1. How the language is designed.
  2. How people are already using it.

Simply adding features to a language does not necessarily automatically change how 
people use it.  If programmers are already used to writing functions (or methods, 
depending on the language) in a certain way in a given language, then just adding 
features will not necessarily change how they program in it unless the new features 
are significant enough to warrant the learning curve.

For example, maybe the newer varieties of CL now have lexical scoping.  However, when 
I learned it, it apparently didn't.  In any case, the structure of CL then encouraged 
me to try to master the myriad built-in functions to use side-effects to maximum 
benefit, so this affected how I learned to program in CL, so my CL programs were far 
from functional in style.

In contrast, when I learned Scheme, the compactness of the language encouraged me to 
write my own functions for almost everything.  Since I found it easier to follow the 
functional style when writing my own functions than to use side-effects extensively, 
my Scheme programs much more closely approached the functional style overall than my 
CL programs.

When I studied Haskell before, the structure of the language encouraged me to follow 
the functional style even more.

When many programmers have this kind of experience, it can change the direction that 
the language, overall, becomes headed.

IMHO, this seems to be one reason that Haskell tends to be more "functional" than 
Scheme, and Scheme than CL.

Going back to C# vs. Java, simply requiring unsafe code to be labelled as such is not 
necessarily going to keep former C/C++ programmers from writing unsafe code to the 
hilt in C#--any more than having classes built-in to C++ kept former C programmers 
from following the old procedural style straight into C++.

The reason that Java programmers tend to write safer, more object-oriented code is 
that Java makes it difficult, if not impossible, for them to do otherwise.  The 
learning curve for writing safe, object-oriented code in Java is actually lower than 
for writing unsafe, procedural code.

If C# again makes it easy to write unsafe code, then in order to avoid the learning 
curve, many current C/C++ programmers are likely to continue programming in The Old 
Way.  The trick lies in the learning curve.

--Ben
--
Benjamin L. Russell
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Furuike ya!  Kawazu tobikomu mizu no oto."  --Matsuo Basho

Re: The importance and relevance of FP

[Benjamin Leon Russell]

On 16 Aug 2000 13:40:29 +0200
 Friedrich Dominicus <[EMAIL PROTECTED]> wrote:
> 
> 
> 
> >I think if I had 
> > to use one language for everything, CL would definitely
> be a
> > candidate.  Of course, Haskell is so much prettier.
> I'm on my way learning both languages. IMO Lisp a more
> programmer
> friendly language. I guess both are simular difficult (or
> easy it's a
> matter of taste) to lean. And both have their special
> merits. But at
> the moment I think Lisp is much prettier than Haskell.

Well, just for the record, I've programmed in both Common LISP and Scheme, and am 
currently learning Haskell, but I found Scheme to be a much cleaner language than CL 
(so much so, in fact, that Scheme was my favorite in college, and CL was my least 
favorite).

Scheme is a compact language (when I studied it, it had only about 50 built-in 
functions); CL is a huge language (it had about 500 built-in functions).  Besides, 
some of the semantics (closure properties, in particular) are different (sorry, but I 
don't have my copy of _Structure and Interpretation of Computer Programs,_ by Abelson, 
Sussman, & Sussman, with me right now :-) ).

The emphases placed in the courses using them were different, too:  in CL, 
side-effects were used often; in Scheme, strict functional programming was stressed, 
and side-effects were rarely, if ever, used.

It just seemed that Scheme went much closer in the style of functional programming 
than CL--one CL course even had an optional book on object-oriented extensions to CL!

I'm not necessarily saying that this is either good or bad, but that, at least in the 
way it was taught, Scheme seemed more closer to the functional style of programming 
than CL did.

Of course, Haskell was much more functional than Scheme.  The issue seemed largely a 
question of degree.

--Ben
--
Benjamin L. Russell
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Furuike ya!  Kawazu tobikomu mizu no oto."  --Matsuo Basho

Re: The importance and relevance of FP

[Richard]

Ralf Muschall writes:

>Some old dead lisps might lack lexical scoping, at least CL has it
>since a long time. The only places I know about where old lisps still
>live are Reduce and Autocad (is this still dynamical?).

They still live in Emacs.  (Emacs Lisp's variables are dynamically scoped.)

Re: The importance and relevance of FP

[Ralf Muschall]

"Craig Dickson" <[EMAIL PROTECTED]> writes:

> I agree, and would add (if I'm recalling correctly) that LISP lacks lexical
> scoping, which may not be an absolute requirement for functional programming

Some old dead lisps might lack lexical scoping, at least CL has it
since a long time. The only places I know about where old lisps still
live are Reduce and Autocad (is this still dynamical?).

> simplistic, binary distinction), then you have to decide where to draw the
> line between "functional languages" and other languages that may, to some

I think it became impossible to draw that line since the inventors
and maintainers of dysfunctional langauges learned that FP is cool
and added closures etc. (Perl has them since 5.001m, Javascript
since 1.2, just to mention a few).

> degree, include support for functional programming. LISP has much more
> support for FP than C++ or Perl, but not as much as Scheme, which in turn is

This again is a matter of taste -- Lisp has series, which is hard to
do in scheme (the problem is not the formal behavior (this is IIRC in
SICP), but the optimizing macroexpansion (series redefines defun
etc. into codewalkers)).

Ralf

Re: The importance and relevance of FP

[Craig Dickson]

I see that the discussion has progressed considerably during the (for me, in
California) night, so I'll just make a couple of comments...

Ketil Z. Malde wrote:

> : functions, while pretty first class objects, reside in
>   their own namespace, and need special operators.
> : iteration and side effects are not particularly discouraged,
>   and is probably as common as recursion and purity in actual
>   code.

I agree, and would add (if I'm recalling correctly) that LISP lacks lexical
scoping, which may not be an absolute requirement for functional programming
but certainly enhances it, and is a common feature of functional languages.

Friedrich Dominicus wrote:

> But saying Lisp isn't functional (to some extend) is
> simply not true.

Well, it's that "to some exten[t]" that is the crux here, I think. If you
are going to say that LISP "is" or "is not" a functional language (an overly
simplistic, binary distinction), then you have to decide where to draw the
line between "functional languages" and other languages that may, to some
degree, include support for functional programming. LISP has much more
support for FP than C++ or Perl, but not as much as Scheme, which in turn is
less "pure" than Haskell or Erlang. So whether you want to say that it "is"
functional or not is just a matter of where you draw the line. Scheme, which
is undeniably more "functional" than LISP, is about the least purely
functional language I would call "functional". So that's where I draw the
line. Your mileage may vary.

Craig

Re: The importance and relevance of FP

[Adrian Hey]

On Tue 15 Aug, Doug Ransom wrote:
> I think NGWS will
> be the kiss of death for FP in the large -- OO just seems 90 degrees out of
> phase with FP.  

Have you looked at O'Haskell?
http://www.cs.chalmers.se/~nordland/ohaskell/

I'm blissfully ignorant of the details of C# and NGWS (and intend to stay
that way :-), but I don't understand why you think FP is incompatible with
OO in principal (in practice it might be awkward with Haskell at present).

Just so long as you remember that all these OO languages are essentially
imperative, so (to be safe) a functional language must deal with the
interface to OO components the same way it deals with any IO (I.E. the IO
monad in Haskell), I can't see any real problem.

What problems do you anticipate (other than the usual ones of incompatible
type systems, data representation, procedure call standards, and memory
management!)? Something more fundamental perhaps?

As for FP in the large (I.E. writing an entire system in a functional
language) this is something which interests me a lot. But if I was doing
that I wouldn't be using NGWS anyway, so there should be no problems.

Regards
-- 
Adrian Hey

Re: The importance and relevance of FP

[Friedrich Dominicus]

> > Why abused? Why should the "pure" functional way the best for
> > programming? Couldn't it be that a language which supports other
> > features besides functionl elements. 
> 
> Indeed.  Could it be that Lisp supports, yea, even encourages,
> non-functional programming?  Why, then,  is it important to you that
> it is considered a functional programming language?

It isn't so important to me. But saying Lisp isn't functional (to some
extend) is simply not true. Personally I think a nice combination of
different "paradigms" in a programming language might give a better
language. I do think that functional programming provided clear
advantags (what am I doing? this is a Haskell mailing list;-), but
it's not the end of all language development. 

I am a used Eiffel programmer but I do feel that Eiffel could gain
very much from functional extensions. In fact I'm sure that a langauge
combining FP and OOP (with imperative roots) is even better than e.g
Haskell of Eiffel alone. 


> 
> > I would think Lisp among other things is a functional language. 
> 
> Functional features like higher order functions are commonly used, so
> Lisp is certainly not as defunctional as e.g. Pascal.  Would you
> consider Python a functional language?
I have programmed a bit Python, but other Lisp Hackers have pointed
out that Python can be considered a FP language. But IMHO Lisp is much
more "functional" if I which than Python. But besided it's Object
System is one of the most amazing things I fouind. Lisp stands IMHO
for a degree of flexibility which is is unbeaten by any other
language. 
> 
> Finally, it isn't obvious that more "functionality" in languages is
> necessarily good, and I think Lisp illustrates that.  
I see, that we agree to soem extend, just IMHO every language gains
from functional extensions. As I would think that Haskell could gain
much by OO-extensions (which is a bit more on-topic than Lisp here, I
guess)


>I think if I had 
> to use one language for everything, CL would definitely be a
> candidate.  Of course, Haskell is so much prettier.
I'm on my way learning both languages. IMO Lisp a more programmer
friendly language. I guess both are simular difficult (or easy it's a
matter of taste) to lean. And both have their special merits. But at
the moment I think Lisp is much prettier than Haskell.

Regards
Friedrich

-- 
for e-mail reply remove all after .com 

Re: The importance and relevance of FP

[Ketil Malde]

Friedrich Dominicus <[EMAIL PROTECTED]> writes:

 Could you explain why Lisp isn't a FP language?

>>> functions (...) reside in their own namespace
>>> iteration and side effects are not particularly discouraged
>>> (...and commonly used)

>> Does that then not just make it a functional language that can be (and has
>> been) 'abused'?

Which in a nutshell exemplifies why we have these debates.  Let's
realize that whether a programming language is functional or not, is a 
question of semantics, and a question of degree.

Haskell is clearly more functional than Lisp, which is more functional 
than C++.  On the other hand, there's no good way to agree on where
exactly to draw the line, so some people (in particular coming from
the imperative camp?) think Lisp is functional, and therefore
incomprehensible and useless, and others (coming from the functional
camp, entrenched somewhere in academia) think Lisp is imperative, and
unworthy of attention.  *shrug*

> Why abused? Why should the "pure" functional way the best for
> programming? Couldn't it be that a language which supports other
> features besides functionl elements. 

Indeed.  Could it be that Lisp supports, yea, even encourages,
non-functional programming?  Why, then,  is it important to you that
it is considered a functional programming language?

> I would think Lisp among other things is a functional language. 

Functional features like higher order functions are commonly used, so
Lisp is certainly not as defunctional as e.g. Pascal.  Would you
consider Python a functional language?

Finally, it isn't obvious that more "functionality" in languages is
necessarily good, and I think Lisp illustrates that.  I think if I had 
to use one language for everything, CL would definitely be a
candidate.  Of course, Haskell is so much prettier.

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

Re: The importance and relevance of FP

[Manuel M. T. Chakravarty]

Ketil Malde <[EMAIL PROTECTED]> wrote,

> Friedrich Dominicus <[EMAIL PROTECTED]> writes:
> 
> > Could you explain why Lisp isn't a FP language?
> 
> Well, the obvious arguments would be that
> 
> : functions, while pretty first class objects, reside in their own
> namespace, and need special operators.
> : iteration and side effects are not particularly discouraged, and is
> probably as common as recursion and purity in actual code.

May I politely refer to the FP FAQ:

  http://www.cs.nott.ac.uk/~gmh/faq.html#functional-languages

I guess that there are heaps of people on this list who have
heard this type of discussion already a million times and
are a bit wary of it.

Thank you,
Manuel

Re: The importance and relevance of FP

[Friedrich Dominicus]

Julz <[EMAIL PROTECTED]> writes:

> > > Could you explain why Lisp isn't a FP language?
> > 
> > Well, the obvious arguments would be that
> > 
> > : functions, while pretty first class objects, reside in their own
> > namespace, and need special operators.
> 
> > : iteration and side effects are not particularly discouraged, and is
> > probably as common as recursion and purity in actual code.
> 
> Does that then not just make it a functional language that can be (and has
> been) 'abused'?

Why abused? Why should the "pure" functional way the best for
programming? Couldn't it be that a language which supports other
features besides functionl elements. 


> People do tend to be lazy (as in water) and take the easiest path.
> Not necessarily the 'right' one.
What's the "right" way. I hardly believe something simular will exist.

> I ask the question,  If Lisp is not a 'functional language', then what is
> it?

I would think Lisp among other things is a functional language. 

Regards
Friedrich

 

-- 
for e-mail reply remove all after .com 

Re: The importance and relevance of FP

[Julz]

> > Could you explain why Lisp isn't a FP language?
> 
> Well, the obvious arguments would be that
> 
> : functions, while pretty first class objects, reside in their own
> namespace, and need special operators.

> : iteration and side effects are not particularly discouraged, and is
> probably as common as recursion and purity in actual code.

Does that then not just make it a functional language that can be (and has
been) 'abused'?
People do tend to be lazy (as in water) and take the easiest path.
Not necessarily the 'right' one.

If something is used for a purpose that it was not originally intended
for, does that change _what_ it is?

I ask the question,  If Lisp is not a 'functional language', then what is
it?


Best Regards,

Julz.

--
Student, University of Otago, New Zealand.

Re: The importance and relevance of FP

[Ketil Malde]

<004301c00704$16d9a5c0$4d01140a@inkpad> 
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
From: Ketil Malde <[EMAIL PROTECTED]>
In-Reply-To: Friedrich Dominicus's message of "16 Aug 2000 08:09:54 +0200"
Date: 16 Aug 2000 11:17:25 +0200
Message-ID: <[EMAIL PROTECTED]>
Lines: 14
User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/20.4 (Emerald)
Sender: [EMAIL PROTECTED]
Original-Sender: Ketil Malde <[EMAIL PROTECTED]>
MIME-Version: 1.0

Friedrich Dominicus <[EMAIL PROTECTED]> writes:

> Could you explain why Lisp isn't a FP language?

Well, the obvious arguments would be that

: functions, while pretty first class objects, reside in their own
namespace, and need special operators.
: iteration and side effects are not particularly discouraged, and is
probably as common as recursion and purity in actual code.

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

Re: The importance and relevance of FP

[Ketil Malde]

Friedrich Dominicus <[EMAIL PROTECTED]> writes:

> Could you explain why Lisp isn't a FP language?

Well, the obvious arguments would be that

: functions, while pretty first class objects, reside in their own
namespace, and need special operators.
: iteration and side effects are not particularly discouraged, and is
probably as common as recursion and purity in actual code.

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

Re: The importance and relevance of FP

[Friedrich Dominicus]

> 
> This is, needless to say, something of a matter of opinion and historical
> interpretation. I wouldn't call LISP an FP language, though it is surely
> ancestral to many FP languages, and many FP concepts have their basis in
> LISP features.

Could you explain why Lisp isn't a FP language? I think among others
it is one. And the combination of features makes Lisp IMHO outstanding
even nowadays.

Regards
Friedrich

-- 
for e-mail reply remove all after .com 

Re: The importance and relevance of FP

[Craig Dickson]

Jacques Lemire wrote:

> On the contrary,  languages like C++ (and Java) and
> C#  are full of concepts and ideas coming from FP
> languages. For example, the catch/try/throw construct
> is coming directly from Common Lisp (Lisp is a
> (although impure) FP language).

This is, needless to say, something of a matter of opinion and historical
interpretation. I wouldn't call LISP an FP language, though it is surely
ancestral to many FP languages, and many FP concepts have their basis in
LISP features.

FP has had some influence on non-FP languages, surely, but usually the
effect of this influence has been not to add core FP capabilities or allow
FP thinking, but instead to add some isolated feature that is more or less
orthogonal to FP, even if it originated in an FP language. Exceptions are a
good example of this; they really have nothing to do with FP as such (in the
sense of "FP is sugared lambda calculus"). How many non-FP languages have
real higher-order functions? Certainly not C++, despite the STL's "function
objects".

> I would not be a bit suprise to see tuples, lists and
> cons(es) introduce in the next generation of languages.

Which "next generation"? If you mean the descendants of C++ and Java, I
would be quite surprised to see LISP-style lists built into them.

> If you what to see the limitations of OO and C++, take
> a look at the MFC, MFC architects had to introduce macros.

Well, I'm not sure that's a fair target. I don't think anyone knowledgeable
about OO would consider MFC (or C++ itself) a very good example of it.

Craig