>>>> Me, I dislike anything that says "Lisp" in it. :-S
>>>   Says the person who is infatuated with functional languages such as
>>> Haskell...
> 
>> Aren't you that guy who loves C++ but hates C? ;-)
> 
>   C isn't object-oriented.

True. But C and C++ are vastly more closely related than Haskell and Lisp.

[And if you wanted to split hairs, Haskell is a pure-functional 
language, while Lisp isn't.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> [And if you wanted to split hairs, Haskell is a pure-functional 
> language, while Lisp isn't.]

  A pure-functional language which has things like indexable arrays and
assignment? Hardly.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> [And if you wanted to split hairs, Haskell is a pure-functional 
>> language, while Lisp isn't.]
> 
>   A pure-functional language which has things like indexable arrays and
> assignment? Hardly.

Really? And indexable arrays are impure because...?

Similarly, all side-effecting operations are implemented using 
referentially-transparent monadic constructs. In Lisp, if you want a 
side-effect, you just do it. That's the difference.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> wrote:
> >> [And if you wanted to split hairs, Haskell is a pure-functional 
> >> language, while Lisp isn't.]
> > 
> >   A pure-functional language which has things like indexable arrays and
> > assignment? Hardly.

> Really? And indexable arrays are impure because...?

  Because it's not a feature of the functional programming paradigm,
but the imperative programming paradigm.

  Purely functional languages are mostly impractical.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>> Really? And indexable arrays are impure because...?
> 
>   Because it's not a feature of the functional programming paradigm,
> but the imperative programming paradigm.
> 
>   Purely functional languages are mostly impractical.

Tell me Warp, do you actually understand what "functional programming" 
means?

You seem to think it means "programming with lists", which isn't correct.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Tell me Warp, do you actually understand what "functional programming" 
> means?

  A purely functional programming language doesn't have side-effects.
If I'm not mistaken, for example assignment produces a side-effect.
Even I/O causes side-effects.

  Thus a purely functional language is mostly impractical. Quoting
wikipedia:

"Purely functional programs have no side effects. This makes it easier
to reason about their behavior. However, almost no programmers bother
to write purely functional programs, since, by definition, a program
with no side effects (one that accepts no input, produces no output,
and interfaces with no external devices ) is formally equivalent to a
program that does nothing; typically, purity is used to enforce a
separation of concerns where one clearly-delineated section of the
program does impure operations like I/O, and calls pure functions and
libraries as needed to compute answers."

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Thus a purely functional language is mostly impractical. Quoting
> wikipedia:
> 
> "Purely functional programs have no side effects. This makes it easier
> to reason about their behavior. However, almost no programmers bother
> to write purely functional programs, since, by definition, a program
> with no side effects (one that accepts no input, produces no output,
> and interfaces with no external devices ) is formally equivalent to a
> program that does nothing;

Quoting wikipedia is not always that useful:  that section is most 
likely vandalism by some angry COBOL programmer.

Surely separation of concerns is good as is reducing side-effects to a 
minimum.  To say a purely functional program is incapable of accepting 
input or generating output is not correct:  if anything, a purely 
functional program is able to, in shared memory, take a list as input 
and generate a list as output.  An outside program can write the input 
list in memory, call the pure program on it and read its output and 
write to file.  That's, AFAIK, is what was done in the old days of 
Haskell:  delayed list IO.

More practically, functional language compilers and runtimes carry out 
the ugly side-effect bits while the purely functional programs do their 
stuff and get written as if acting on purely side-effect free 
datastructures.  That's monadic IO today.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Tell me Warp, do you actually understand what "functional programming" 
>> means?
> 
>   A purely functional programming language doesn't have side-effects.

Indeed.

> If I'm not mistaken, for example assignment produces a side-effect.
> Even I/O causes side-effects.

Assignment and I/O are both side-effects. Accessing an indexed array 
does not. There is absolutely no reason why a pure functional language 
cannot have arrays.

>   Thus a purely functional language is mostly impractical.

Depends on your definition of "practical".

> Quoting wikipedia:
> 
> "Purely functional programs have no side effects. This makes it easier
> to reason about their behavior. However, almost no programmers bother
> to write purely functional programs, since, by definition, a program
> with no side effects is formally equivalent to a program that
> does nothing."

Indeed, a program with absolutely no side effects at all is rather 
pointless. (!) There are several approaches to this apparent problem.

One approach is to *allow* side-effects, but say "hey, don't use this 
unless you have to". This is the Lisp approach. (And Erlang. And a few 
others.)

The Haskell approach is different. A Haskell "program" just returns a 
list of instructions to the Haskell runtime, and the Haskell runtime 
actually "does" the instructions on the program's behalf.

Why is that different? Well, it means that the entire program remains 
referentially transparent. And *that* is the defining characteristic of 
functional programs.

In Haskell, *every* expression can be replaced by the value it returns 
without altering the result of the program. [Indeed, this is notionally 
how you execute a Haskell program.] The same statement does *not* apply 
to Lisp. Hence, Haskell is pure, and Lisp is not. QED.

Note that you *could* write referentially transparent code in just about 
any programming language, if you wanted to. It's just that in Haskell 
you can't write code that isn't. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> > If I'm not mistaken, for example assignment produces a side-effect.
> > Even I/O causes side-effects.

> Assignment and I/O are both side-effects. Accessing an indexed array 
> does not. There is absolutely no reason why a pure functional language 
> cannot have arrays.

  Are you telling me in Haskell you can't modify the contents of an array
in-place? (By "indexable array" I implied that it can be assigned to,
although I should have perhaps stated it more explicitly.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>>> If I'm not mistaken, for example assignment produces a side-effect.
>>> Even I/O causes side-effects.
> 
>> Assignment and I/O are both side-effects. Accessing an indexed array 
>> does not. There is absolutely no reason why a pure functional language 
>> cannot have arrays.
> 
>   Are you telling me in Haskell you can't modify the contents of an array
> in-place? (By "indexable array" I implied that it can be assigned to,
> although I should have perhaps stated it more explicitly.)

Haskell provides a kind of array that you cannot modify in-place. (It's 
useful e.g. for pre-computed lookup tables.)

Haskell also provides another kind of array which can be modified 
in-place in the same sense that files can be written to - i.e., your 
program returns a set of instructions to the runtime that says "hey, 
create this array and modify its contents like this". Which makes sense 
really. After all, what is a "file"? It's a named array of bytes that 
can be modified [and reised] in-place! :-D

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message