Pure functions in EcmaScript

David Bruant bruant.d at gmail.com
Wed Nov 28 06:30:57 PST 2012

Le 28/11/2012 14:47, Marius Gundersen a écrit :
> On Wed, Nov 28, 2012 at 1:21 PM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>     Hi Marius,
>     I won't say the idea is bad, but what would be the benefit of this
>     new type of function?
>     From experience on this list, if a new idea cannot prove to make a
>     major difference with what currently exists, it is not considered
>     to be added to the ES6 spec.
>     The major difference can be in performance, security, language
>     extensibility, programming idioms/conveniences, etc.
>     Do you have reasons to think pure functions as you propose them
>     make that big of an improvement as opposed to JS as it is?
> With many new functional programming possibilities (like map, reduce, 
> filter, lambdas) there are many scenarios where the implementer should 
> use pure (or as I renamed it in another reply, side-effect-free) 
> functions.
Why "should"? What is the problem if people don't?

> Library implementers are likely interested in making functions that 
> can take lambdas as parameters, and these lambdas (in many cases) 
> should not alter any outside state, they should only return a value. A 
> function with this restriction could run faster and take up less 
> memory since it only needs the values passed to it as arguments in its 
> own scope.
"could run faster and take up less memory". I agree it "could", but it's 
not given it will when implemented. In some cases, it's possible to 
prove that a function is side-effect free, but to the best of my 
knowledge, no implementations has gone to length to do such thing, 
probably, because the cost is too big in regard to the benefits.

> Mostly I feel this would introduce better coding practises with a 
> focus on functional programming rather than object oriented programming.
I'm only half sympathic to this argument. JS is a language with many 
users with different programming styles. I understand the benefits of 
FP, but don't see why it should be favored over any other style.

> Using functions with limited scope would reduce the number of 
> variables written to the global scope
I use both OOP and FP styles and I don't see how FP would help for 
global variables. Basically, declaring variables as function local (with 
the "var" keyword) prevent global leaks.

> and would reduce the amount of state in an application.
...and increase the use of temporary values and GC to compensate, 
because JS engines are not really written to optimize for FP? For 
instance, I think, none do tail call optimization yet? (others in the 
list know better on that point)

> Seeing as FP is a bit of a trend today (due, in part, to the 
> popularity of JavaScript), it seems to me like a good idea to 
> implementing features which help promote good FP patterns in a 
> language that allows for both FP and OOP.
You mentioned ReferenceError when the functions tries to reach a 
variable outside of its scope. I think it's possible to implement such a 
thing in current JavaScript. Take a look at the Caja code [1] for 
inspiration (sorry the barrier is a bit high as I put it. Ask me 
questions if you need help).
Also, to avoid being tempted to use a scope, just define your function 
as non-nested (global :-s or directly inside an IIFE (Immediately 
Invoked Function Expression))

Just a note:
     function@ f(x){
         x.a = 1;
I think this is a side-effect. Should an error be thrown here too?
If so, does it mean you can't use objects as arguments?

In any case, none of what you answered really convinces me (just to 
clarify, I just hang out on the list, I make no decisions with regard to 
the language) as being a major improvement for the language. It would be 
a good convenience for FP style, that's it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121128/764f04fa/attachment.html>

More information about the es-discuss mailing list