> Hi,
>
> I am really new to functional programming. I am just wondering if it
> is theoretically allowed to for the function to change the value of
> the parameters?

> Haskell's list seems to be immutable so it is not a problem. What if I
> use python:
>
> def f(list):
> list.append("a")

> will change the list passed in. Is this generally acceptable practice
> in functional programming?

> beginner a écrit :

>> Hi,
>>
>> I am really new to functional programming. I am just wondering if it
>> is theoretically allowed to for the function to change the value of
>> the parameters?

>
> This would be a side effect. The point of FP is to avoid side effects.

>>>>> "JD" == Joachim Durchholz durchholz.org> writes:

JD> These things don't go well with side effects - if you construct
JD> a function and pass it around, you lose a great deal of control
JD> when it will be evaluated, and that means you can't easily
JD> control the order in which the side effects will happen. So many
JD> FPLs indeed try to restrict or control side effects (Haskell,
JD> Clean), others rely on "common sense" and simply make
JD> side-effect-free programming easy (OCaml, SML, some
JD> styles/schools of Lisp programming).

>>>>>> "JD" == Joachim Durchholz durchholz.org> writes:

>

>> These things don't go well with side effects - if you construct
>> a function and pass it around, you lose a great deal of control
>> when it will be evaluated, and that means you can't easily
>> control the order in which the side effects will happen. So many
>> FPLs indeed try to restrict or control side effects (Haskell,
>> Clean), others rely on "common sense" and simply make
>> side-effect-free programming easy (OCaml, SML, some
>> styles/schools of Lisp programming).

>
> There are places where higher order functions and side effects
> go well together (these fall into the latter category, where the
> programmer must exercise caution.

> As a general rule, this type of programming is evil and
> should be used as sparingly as possible.

> The point of FPLs is higher-order functions (functions that take
> functions as arguments), and constructing functions at run-time and
> passing them around as values ("functions as first-class citizens",
> "functions are values").

> Of course, some people define FP as "free from side effects". But I
> think this definition is less useful than the other one.

> On Fri, 27 Jul 2007 13:36:15 +0200, Joachim Durchholz
> durchholz.org> wrote:
>
> [...]
>

>> The point of FPLs is higher-order functions (functions that take
>> functions as arguments), and constructing functions at run-time and
>> passing them around as values ("functions as first-class citizens",
>> "functions are values").

>
> By that reasoning Perl is a FPL.

>> Of course, some people define FP as "free from side effects". But I
>> think this definition is less useful than the other one.

>
> And all FP have to have some support for side effects else how are
> they going to do I/O?

> Bruno Desthuilliers schrieb:
>

>> beginner a écrit :
>>

>>> Hi,
>>>
>>> I am really new to functional programming. I am just wondering if it
>>> is theoretically allowed to for the function to change the value of
>>> the parameters?

>>
>>
>> This would be a side effect. The point of FP is to avoid side effects.

>
>
> No, no, no. Then Lisp, SML, OCaml and Clean wouldn't be FPLs.

> Joachim Durchholz a écrit :

>> Bruno Desthuilliers schrieb:
>>

>>> beginner a écrit :
>>>

>>>> Hi,
>>>>
>>>> I am really new to functional programming. I am just wondering if it
>>>> is theoretically allowed to for the function to change the value of
>>>> the parameters?

>>>
>>>
>>> This would be a side effect. The point of FP is to avoid side effects.

>> No, no, no. Then Lisp, SML, OCaml and Clean wouldn't be FPLs.

>
> Are they ?-)
>
> (FWIW, I've been almost flamed the last time I labelled Lisp as a
> functional language on c.l.lisp)

>> Joachim Durchholz a