Functional programming 
Author Message
 Functional programming

I saw a (nice) book in a bookshop with all kinds of compilers on a CD and
short explanations of the languages. It also had a LISP compiler (XLISP).
Now the author said that in reality LISP was a functional language.
Now
(1) Is the correct definition of functional programming that it does not use
assigment?
(2) Do you see LISP as a functional language? (I suppose that even a
functional langauge must become imperative to some extent, at least when it
does IO?

J.B.



Tue, 23 Apr 2002 03:00:00 GMT  
 Functional programming

Quote:
> I saw a (nice) book in a bookshop with all kinds of compilers on a CD and
> short explanations of the languages. It also had a LISP compiler (XLISP).
> Now the author said that in reality LISP was a functional language.

Lisp has strong roots in Functional Programming (-> lambda calculus)
and Functional Programming grow up with Lisp (witness the conferences
"Lisp and Functional Programming") for a long time.

Common Lisp **supports** Functional Programming. It does not
**enforce** you to use FP - it just supports it - but quite well.
Even the OOP-substrate in Common Lisp (-> CLOS) uses Generic
Functions rather than Message Passing.

Common Lisp is a multi-paradigm language. It directly supports
imperative, functional and object-oriented programming.
It does not enforce you to use these - you have to choose.

Other programming paradigms can be incorporated easily -
this is a part of the "Lisp culture".



Wed, 24 Apr 2002 03:00:00 GMT  
 Functional programming


Quote:
> I saw a (nice) book in a bookshop with all kinds of compilers on a CD and
> short explanations of the languages. It also had a LISP compiler (XLISP).

XLisp is an interpreter.

Quote:
> Now the author said that in reality LISP was a functional language.
> Now
> (1) Is the correct definition of functional programming that it does not
use
> assigment?

Generally, functional programming language should avoid side-effects at all
and allow use of high-order functions.

Quote:
> (2) Do you see LISP as a functional language? (I suppose that even a
> functional langauge must become imperative to some extent, at least when
it
> does IO?

If you will not use side-effect constructions Lisp would be *almost*
functional language, but then you'd better use Scheme for that matter. As I
understand, in pure functional languages special mechanisms (monads ?) are
used to deal with side-effecting but neccessary things like I/O and
hash-tables.

--
  Eugene



Wed, 24 Apr 2002 03:00:00 GMT  
 Functional programming

Quote:
> If you will not use side-effect constructions Lisp would be *almost*
> functional language, but then you'd better use Scheme for that matter.

There is no reason to do that. Scheme is no less or more "functional"
than Common Lisp (other than Scheme having full continuations
and tail call elimination in the standard).


Wed, 24 Apr 2002 03:00:00 GMT  
 Functional programming


Quote:


> > If you will not use side-effect constructions Lisp would be *almost*
> > functional language, but then you'd better use Scheme for that matter.

> There is no reason to do that. Scheme is no less or more "functional"
> than Common Lisp (other than Scheme having full continuations
> and tail call elimination in the standard).

You're right, but Scheme is a bit more elegant at function composition.
((foo a b) c d) looks more natural than (funcall (foo a b) c d), though
essentially it's the same.
Other issue is that if you drop out all side-effecting features from CL, it
wouldn't be any better than Scheme without them :)

--
  Eugene



Wed, 24 Apr 2002 03:00:00 GMT  
 Functional programming
* Eugene Zaikonnikov
| You're right, but Scheme is a bit more elegant at function composition.
| ((foo a b) c d) looks more natural than (funcall (foo a b) c d), though
| essentially it's the same.

  that's no more than syntactic artificial sweetener at best.  while it may
  look cute to the uninitiate, the decision not to have FUNCALL means you
  can't actually make indirect functions calls, as in the following very
  useful idiom to process a list of functions.

(mapcar #'funcall <list-of-functions> ...)

  of course, any real Lisper knows how to teach Scheme to be smart about
  this, too, but Scheme has to be taught just about _everything_:

(define funcall (lambda (function . args) (apply function args)))

  Scheme should adopt a new syntax for APPLY: (function . args).  I've
  suggested it before, and it's weird tha they haven't adopted it: it would
  be so much more _elegant_ when compared to the syntax of the lambda lists.

#:Erik
--
  Attention Microsoft Shoppers!  MS Monopoly Money 6.0 are now worthless.



Wed, 24 Apr 2002 03:00:00 GMT  
 Functional programming

Quote:

> I saw a (nice) book in a bookshop with all kinds of compilers on a CD and
> short explanations of the languages. It also had a LISP compiler (XLISP).
> Now the author said that in reality LISP was a functional language.
> Now
> (1) Is the correct definition of functional programming that it does not use
> assigment?

That's called "referential transparency".  It's associated with
functional languages, but depending on who you listen to, it is or
isn't neccessary.

To some, passing functions around as first-class objects makes a
language functional.  Eg, with mapcar and its buddies in Lisp.

Quote:
> (2) Do you see LISP as a functional language?

No, not really.

Quote:
> (I suppose that even a
> functional langauge must become imperative to some extent, at least when it
> does IO?

Off topic, but no, the pure functional languages like Haskell use
monads for IO.  Monads are a whole topic, but basically they describe
world-modifying actions instead of commanding them.  I expect some
criticism from those who'd prefer to define monads in terms of unit,
join, etc, but after asking around and reading Wadler's papers et al,
I think that is the best short summary of monads.

--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html



Wed, 24 Apr 2002 03:00:00 GMT  
 Functional programming

Quote:
> You're right, but Scheme is a bit more elegant at function composition.
> ((foo a b) c d) looks more natural than (funcall (foo a b) c d), though
> essentially it's the same.

Actually it is the other way around, IMHO.

Common Lisp's notation is far better:

FUNCALL makes function calls explicit. Ever wanted to understand
Scheme code that looks like:

(bar ((foo 1 2) 534)
     (bar (((((baz)))))
          ((foo 3 4) 333)))

It's a pain. It's far better to use funcall to invoke
functions that have been returned by some random code.
You then can see in your source code what happens.
Nested parentheses just don't give enough visual clue.

Again, Common Lisp scales.

Rainer Joswig, ISION Internet AG, Harburger Schlossstra?e 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226



Wed, 24 Apr 2002 03:00:00 GMT  
 Functional programming

Quote:

> Common Lisp is a multi-paradigm language. It directly supports
> imperative, functional and object-oriented programming.
> It does not enforce you to use these - you have to choose.

These comments aren't too specific to Eugene's or Rainer's messages, I
just insert them here.

There are a few 'factoids' that sometimes bothered me, but I may be
wrong.

- When asked about paradigms in Lisp, the answer is often a menu of
paradigms (functional, imperative and object-oriented), and they
_appear_ to suggest that you would have to choose any one of them.
Functional and imperative styles are mutually exclusive, but you may
_also_ use OOP with either of them.  In this sense, OO-nes and
transparency are orthogonal.

- Suggestions also appear to list the available paradigms as if they
were somehow equivalent, or of the same value.  Even though imperative
style is well supported in Lisp (it even has the equivalent of GOTO),
hopefully people consider it inferior to the functional style.  (Of
course, local deviations like ones in elaborate macros are a different
story.)  Even though Lisp gives support for imperative style, I would
say that Lisp is fundamentally a functional (albeit impure) language.

- Re Eugene's messages:

Quote:
> If you will not use side-effect constructions Lisp would be *almost*
> functional language, but then you'd better use Scheme for that
> if you drop out all side-effecting features from CL, it wouldn't be
> any better than Scheme without them :)

First, it suggests that Scheme is a pure functional language, which it
isn't.  Second, it assumes that functional programming in CL means
little more than what Lisp 1.5 in the fifties could do.  Even though
class definitions have to be stored somewhere, it is perfectly possible
to use CLOS and retain functional programming with all of its benefits.
As for object persistence or I/O, even pure FL's have their constructs
(monads), which are stylistically close to techniques of impure
languages.

I am yet to see a CL application programmed in imperative style, or a
functional language with the power of CL (YMMV)- heck, you can even use
lazy evaluation techniques described in CLtL2!

Robert



Wed, 24 Apr 2002 03:00:00 GMT  
 Functional programming
Tom Breton wrote to Janos:

Quote:
> > (2) Do you see LISP as a functional language?

> No, not really.

It is not really true.

Robert



Wed, 24 Apr 2002 03:00:00 GMT  
 Functional programming

Quote:

> - When asked about paradigms in Lisp, the answer is often a menu of
> paradigms (functional, imperative and object-oriented), and they
> _appear_ to suggest that you would have to choose any one of them.
> Functional and imperative styles are mutually exclusive, but you may
> _also_ use OOP with either of them.  In this sense, OO-nes and
> transparency are orthogonal.

I personally think that these paradigms are somehow very
nice integrated in Common Lisp.

Quote:
> - Suggestions also appear to list the available paradigms as if they
> were somehow equivalent, or of the same value.

This would need a closer look.

Quote:
> Even though imperative
> style is well supported in Lisp (it even has the equivalent of GOTO),
> hopefully people consider it inferior to the functional style.  (Of
> course, local deviations like ones in elaborate macros are a different
> story.)  Even though Lisp gives support for imperative style, I would
> say that Lisp is fundamentally a functional (albeit impure) language.

One of the problems:
Common Lisp does not enforce tail call elimination. This
means that recursion often is of a limited *practical* value
due to stack size problems. You must use one of the
several loop constructs - loop via recursion is often
running into practical problems.

To illustrate this in Macintosh Common Lisp:

(defun foo (n)
  (if (zerop n)
    'done
    (foo (1- n))))

(foo 100000)

Quote:
> Error: Stack overflow on value stack.
>        To globally increase stack space,
>        increase *MINIMUM-STACK-OVERFLOW-SIZE*
> While executing: ZEROP
> Type Command-/ to continue, Command-. to abort.
> If continued: Continue with a larger stack

See the Restarts? menu item for further choices.
1 >

; a lower debug value means also: use tail call elimination
(proclaim '(optimize (debug 2)))

(defun foo (n)
  (if (zerop n)
    'done
    (foo (1- n))))

(foo 100000)

->
DONE

Quote:
> class definitions have to be stored somewhere, it is perfectly possible
> to use CLOS and retain functional programming with all of its benefits.

It is even used in real-world programs.
For example CLIM often uses immutable objects (-> no side effects).

Quote:
> I am yet to see a CL application programmed in imperative style,

There are lots - really lots. Quite a few coming from older
Lisp dialects or as translations from other languages.

 or a

Quote:
> functional language with the power of CL (YMMV)- heck, you can even use
> lazy evaluation techniques described in CLtL2!

Which are macros that make use of imperative features.

In general I also think that providing a kind of Functional Programming
is an essential property of Common Lisp - very powerful!

--
Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226



Thu, 25 Apr 2002 03:00:00 GMT  
 Functional programming

[snip]
Quote:
> FUNCALL makes function calls explicit. Ever wanted to understand
> Scheme code that looks like:

> (bar ((foo 1 2) 534)
>      (bar (((((baz)))))
>           ((foo 3 4) 333)))

Hmm... Along with Erik's example on mapping a list of functions that makes a
point. I admit that I never done any serious Scheme programming, let alone
purely functional, and my opinion was based mostly on impression.
But after all, who will want to do pure FP in Lisp? IMHO it is more of a
hypothetical situation.

--
  Eugene



Thu, 25 Apr 2002 03:00:00 GMT  
 Functional programming

[...]

Quote:
> There are a few 'factoids' that sometimes bothered me, but I may be
> wrong.
[...]
> - Suggestions also appear to list the available paradigms as if they
> were somehow equivalent, or of the same value.  Even though imperative
> style is well supported in Lisp (it even has the equivalent of GOTO),
> hopefully people consider it inferior to the functional style.  (Of
> course, local deviations like ones in elaborate macros are a different
> story.)  Even though Lisp gives support for imperative style, I would
> say that Lisp is fundamentally a functional (albeit impure) language.

Isn't one of the attractions of Lisp that it can do whatever the
programmer wants?  If you firmly believe the imperative style to
always be inferior, fine - you can write pure functional programs.
Personally, I find that sometimes the best way to solve a problem is
with functional code, sometimes, with imperative, and usually with a
mix.

I am sure that this will change as I learn more, but even if at some
point I write purely functional code I hope I won't ever assume I know
all the answers, and make such sweeping statements...  In fact, if I
really was convinced functional programming was the One True Way I think
I would prefer moving to a stricly functional language just to keep
myself away from temptation ;-)  (OCaml and O'Haskell both look
interesting).

So, answering the original post - no, I don't see Lisp as a functional
programming language.  I see it as a the best language I've found yet
(and I can imagine better) for programming as *I* want to program,
without being pushed into a particular style.  If I had to call it
something I'd say it was a catholic programming language (in the
non-religious sense of the word - in the religious sense, would
assembler be the puritan language?)

Andrew
http://www.andrewcooke.free-online.co.uk/index.html

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



Thu, 25 Apr 2002 03:00:00 GMT  
 Functional programming

Quote:
> Hmm... Along with Erik's example on mapping a list of functions that makes a
> point. I admit that I never done any serious Scheme programming, let alone
> purely functional, and my opinion was based mostly on impression.
> But after all, who will want to do pure FP in Lisp? IMHO it is more of a
> hypothetical situation.

We were writing around 15 kloc dense Scheme code for a web site
(http://www.milka.de -> http://cowsim.milka.de).
It makes heavy use of higher-order functions, functions
returning functions, etc. It's big fun to write code this way and
it makes code very modular.
Seems like we will do a lot more Scheme programming for this
application next year. :-)

--
Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226



Thu, 25 Apr 2002 03:00:00 GMT  
 Functional programming

[snip]

Quote:
> > if you drop out all side-effecting features from CL, it wouldn't be
> > any better than Scheme without them :)

> First, it suggests that Scheme is a pure functional language, which it
> isn't.  Second, it assumes that functional programming in CL means
> little more than what Lisp 1.5 in the fifties could do.  Even though

Perhaps I wasn't clear there. "Scheme without them" was supposed to mean
"Scheme with side-effecting features thrown off", therefore I wasn't
implying that Scheme is a pure FP language.
Although I agree with your remark about object system.

--
  Eugene



Thu, 25 Apr 2002 03:00:00 GMT  
 
 [ 95 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7]

 Relevant Pages 

1. functional.py 0.6 - Functional Programming in Python

2. functional.py 0.7 - Functional programming in Python

3. functional.py - functional programming in Python

4. functional.py 0.7 - Functional programming in Python

5. functional.py 0.6 - Functional Programming in Python

6. functional.py - functional programming in Python

7. US PhD programs strong on functional programming?

8. ICFP Functional Programming Contest

9. ICFP functional programming contest -- deadline correction

10. Reminder -- ICFP functional programming contest starts Thursday!

11. Tacit/functional programming

12. Is C a functional programming language?

 

 
Powered by phpBB® Forum Software