Velocity Reviews > JavaScript. Array "extras" in detail.

# JavaScript. Array "extras" in detail.

Dmitry A. Soshnikov
Guest
Posts: n/a

 02-23-2011
A new article written specially for Opera software:

JavaScript. Array "extras" in detail.

http://dev.opera.com/articles/view/j...ras-in-detail/

Dmitry.

Dr J R Stockton
Guest
Posts: n/a

 02-24-2011
In comp.lang.javascript message <ik3a4c$sng$(E-Mail Removed)-
september.org>, Wed, 23 Feb 2011 18:46:05, Dmitry A. Soshnikov
<(E-Mail Removed)> posted:

>A new article written specially for Opera software:
>
>JavaScript. Array "extras" in detail.
>
>http://dev.opera.com/articles/view/j...ras-in-detail/

Interesting.

Reminds me of <http://en.wikipedia.org/wiki/Jensen%27s_Device>.

increase my chances of finding it again.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

Dmitry A. Soshnikov
Guest
Posts: n/a

 02-25-2011
On 24.02.2011 23:22, Dr J R Stockton wrote:
> In comp.lang.javascript message<ik3a4c$sng$(E-Mail Removed)-
> september.org>, Wed, 23 Feb 2011 18:46:05, Dmitry A. Soshnikov
> <(E-Mail Removed)> posted:
>
>> A new article written specially for Opera software:
>>
>> JavaScript. Array "extras" in detail.
>>
>> http://dev.opera.com/articles/view/j...ras-in-detail/

>
> Interesting.
>
> Reminds me of<http://en.wikipedia.org/wiki/Jensen%27s_Device>.
>

Yeah, actually roots of this idea (of the parametrized list handling)
went to also to math. There, mathematician are used to operate with the
concept of _a sum_ (regardless the sum of _what_ exactly). They have a
special higher-order function (HOF) of summation with the known sign --
∑ (∑).

My example with a generic sum is exactly a direct reflection of this
math concept. And as a consequence, higher-order functions can be
applied for any manipulation on the sequences/lists/arrays. That's the
reason they are available in all functional programming langauges
(including JS which supports this style of programming, since all
functions here are "first-class" and can be passed to HOFs).

> increase my chances of finding it again.
>

Yeah, thanks.

Dmitry.

Michael Haufe (\TNO\)
Guest
Posts: n/a

 02-25-2011
On Feb 25, 5:30*am, "Dmitry A. Soshnikov" <(E-Mail Removed)>
wrote:
[...]
> My example with a generic sum is exactly a direct reflection of this
> math concept. And as a consequence, higher-order functions can be
> applied for any manipulation on the sequences/lists/arrays. That's the
> reason they are available in all functional programming langauges
> (including JS which supports this style of programming, since all
> functions here are "first-class" and can be passed to HOFs).

[...]

It is unfortunate that JavaScript couldn't be a bit less clunky in the
functional style:

["1","2","3"].map(parseInt); //[1, NaN, NaN]

Lasse Reichstein Nielsen
Guest
Posts: n/a

 02-25-2011
"Michael Haufe (\"TNO\")" <(E-Mail Removed)> writes:

> It is unfortunate that JavaScript couldn't be a bit less clunky in the
> functional style:
>
> ["1","2","3"].map(parseInt); //[1, NaN, NaN]

Don't blame your tools. The map function passes three arguments to
the function, and parseInt expects two. What you want is probably:
["1","2","3"].map(function(x) { return parseInt(x, 10); });

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

Michael Haufe (\TNO\)
Guest
Posts: n/a

 02-25-2011
On Feb 25, 11:05*am, Lasse Reichstein Nielsen <(E-Mail Removed)>
wrote:
> "Michael Haufe (\"TNO\")" <(E-Mail Removed)> writes:
>
> > It is unfortunate that JavaScript couldn't be a bit less clunky in the
> > functional style:

>
> > ["1","2","3"].map(parseInt); //[1, NaN, NaN]

>
> Don't blame your tools. The map function passes three arguments to
> the function, and parseInt expects two. What you want is probably:
> *["1","2","3"].map(function(x) { return parseInt(x, 10); });

Alternatively for this example: ["1","2","3"].map(Number);

The point is that it is often the case that solutions like yours are
necessary in these types of methods which I find clunky.

Ry Nohryb
Guest
Posts: n/a

 02-26-2011
On Feb 25, 7:03*pm, "Michael Haufe (\"TNO\")"
<(E-Mail Removed)> wrote:
> On Feb 25, 11:05*am, Lasse Reichstein Nielsen <(E-Mail Removed)>
> wrote:
>
> > "Michael Haufe (\"TNO\")" <(E-Mail Removed)> writes:

>
> > > It is unfortunate that JavaScript couldn't be a bit less clunky in the
> > > functional style:

>
> > > ["1","2","3"].map(parseInt); //[1, NaN, NaN]

>
> > Don't blame your tools. The map function passes three arguments to
> > the function, and parseInt expects two. What you want is probably:
> > *["1","2","3"].map(function(x) { return parseInt(x, 10); });

>
> Alternatively for this example: ["1","2","3"].map(Number);
>
> The point is that it is often the case that solutions like yours are
> necessary in these types of methods which I find clunky.

Not clunky, no, if you put garbage in you get garbage out.
--
Jorge.

Michael Haufe (\TNO\)
Guest
Posts: n/a

 02-26-2011
On Feb 26, 4:50*am, Ry Nohryb <(E-Mail Removed)> wrote:

> Not clunky, no, if you put garbage in you get garbage out.

If a construct is not intuitive and requires extra boilerplate to make
it work, it can be considered clunky. Having to use "function()
{ return ... }" or similar to massage parameters is not something to
smile at. \be's shorter function syntax will help a bit in this area
"#(x) { x * x }", but even this only dulls the pain of having to do it
in the first place. Compare code similar to the above with other
functional languages such as Miranda, Haskell, OCaml, SML, F#, popular
Lisp languages and others, and you'll see what I mean. These array
"extras" and "Array generics" go quite far to help enable a more
functional programming style in JS but with the choices made in their
signatures it has made it painful to perform one of the most important
important aspects of developing in the functional style : composition.
irt being non-intuitive, if you've used one or more of the above
languages little things like this are probably going to bite you more
than once. I'm not trying to rally against these new array methods,
but simply showing that there is another side of the coin.

Lasse Reichstein Nielsen
Guest
Posts: n/a

 02-27-2011
"Michael Haufe (\"TNO\")" <(E-Mail Removed)> writes:

> On Feb 26, 4:50*am, Ry Nohryb <(E-Mail Removed)> wrote:
>
>> Not clunky, no, if you put garbage in you get garbage out.

>
>
> If a construct is not intuitive and requires extra boilerplate to make
> it work, it can be considered clunky.

What part of the construct is it that is not intuitive here?

My guess is the fact that map actually passes three arguments, not
just one, which differs from, e.g., Lisp's map-car or Scheme's map.
But that's actually very much a Javascript-like feature.

> Having to use "function()
> { return ... }" or similar to massage parameters is not something to
> smile at. \be's shorter function syntax will help a bit in this area
> "#(x) { x * x }", but even this only dulls the pain of having to do it
> in the first place. Compare code similar to the above with other
> functional languages such as Miranda, Haskell, OCaml, SML, F#, popular
> Lisp languages and others, and you'll see what I mean.

Notice that neither of those languages allow you to call a function with
fewer or more arguments than what you expect. That means that you won't
even typecheck (for the statically typed langauges) if your map passed
three arguments and you function expected two.

The same function would fail in Lisp and Scheme, if map passed three
arguments.

If you had a map function passing three arguments in SML, you would
still have to write
map myList (fn (x,i,l) => myUnaryFunction(x))
to use it with an unary function.

Javascript is unique among the functional languages you mention in that
you can pass too few or too many arguments to a function. That's why they
allowed themselves to let map pass three arguments instead of just one.

If you have a function expecting just one argument, then it still works.

What you did here was to pass a function that expected two arguments
(but would work with only one) and you got predictably incorrect
results to a function calling it with three arguments, where the second
did not work as a second argument for the first function.

> These array "extras" and "Array generics" go quite far to help
> enable a more functional programming style in JS but with the
> choices made in their signatures it has made it painful to perform
> one of the most important important aspects of developing in the
> functional style : composition.

If your functions don't allow a variable number of arguments, then
there is no problem - it will ignore any surplus arguments.

The way Javascript is designed, that's sadly not something you can
rely on.

> irt being non-intuitive, if you've used one or more of the above
> languages little things like this are probably going to bite you more
> than once. I'm not trying to rally against these new array methods,
> but simply showing that there is another side of the coin.

The Javascript array functions differ from similar list-functions in
other languages. That's both good and bad - they actually fit
Javascript well, since the language allows optional arguments so
easily, but they bite you when you combine two different ways of being
optional (passing potentially unnecessary extra arguments to a
function expecting optional arguments, where the user thinks just of
the one-argument case).

/L 'Never call parseInt with only one argument'.
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

Michael Haufe (\TNO\)
Guest
Posts: n/a

 02-27-2011
On Feb 27, 6:16*am, Lasse Reichstein Nielsen <(E-Mail Removed)>
wrote:
> "Michael Haufe (\"TNO\")" <(E-Mail Removed)> writes:
>
> > On Feb 26, 4:50 am, Ry Nohryb <(E-Mail Removed)> wrote:

>
> >> Not clunky, no, if you put garbage in you get garbage out.

>
> > If a construct is not intuitive and requires extra boilerplate to make
> > it work, it can be considered clunky.

>
> What part of the construct is it that is not intuitive here?
>
> My guess is the fact that map actually passes three arguments, not
> just one, which differs from, e.g., Lisp's map-car or Scheme's map.

Yes

> But that's actually very much a Javascript-like feature.
>
> > Having to use "function()
> > { return ... }" or similar to massage parameters is not something to
> > smile at. \be's shorter function syntax will help a bit in this area
> > "#(x) { x * x }", but even this only dulls the pain of having to do it
> > in the first place. Compare code similar to the above with other
> > functional languages such as Miranda, Haskell, OCaml, SML, F#, popular
> > Lisp languages and others, and you'll see what I mean.

>
> Notice that neither of those languages allow you to call a function with
> fewer or more arguments than what you expect.

Fewer is allowed, but not more. (currying) Unless you are referring to
Lisp/Scheme only by saying "neither"?

> That means that you won't
> even typecheck (for the statically typed langauges) if your map passed
> three arguments and you function expected two.
>
> The same function would fail in Lisp and Scheme, if map passed three
> arguments.
>
> If you had a map function passing three arguments in SML, you would
> still have to write
> * *map myList (fn (x,i,l) => myUnaryFunction(x))
> to use it with an unary function.

Of course since mutability is avoided, the third argument would have
little reason to exist. For the second it's a little meaningless since
the use case are hard to find. In fact I don't think there is even an
(indexof foo) style function in the standard lib.

> Javascript is unique among the functional languages you mention in that
> you can pass too few or too many arguments to a function.

Not quite... <http://mlton.org/Fold>

Unless you want to compare arbitrary size tuples to JS arguments.

> That's why they
> allowed themselves to let map pass three arguments instead of just one.
>
> If you have a function expecting just one argument, then it still works.
>
> What you did here was to pass a function that expected two arguments
> (but would work with only one) and you got predictably incorrect
> results to a function calling it with three arguments, where the second
> did not work as a second argument for the first function.

Yes. It looks like a similar discussion as this one is going on here:
<http://www.wirfs-brock.com/allen/posts/166>.
Also here <http://whereswalden.com/2011/02/26/t...r-way-to-call-

> > These array "extras" and "Array generics" go quite far to help
> > enable a more functional programming style in JS but with the
> > choices made in their signatures it has made it painful to perform
> > one of the most important important aspects of developing in the
> > functional style : composition.

>
> If your functions don't allow a variable number of arguments, then
> there is no problem - it will ignore any surplus arguments.
>
> The way Javascript is designed, that's sadly not something you can
> rely on.

The identity crises strikes again.

> > irt being non-intuitive, if you've used one or more of the above
> > languages little things like this are probably going to bite you more
> > than once. I'm not trying to rally against these new array methods,
> > but simply showing that there is another side of the coin.

>
> The Javascript array functions differ from similar list-functions in
> other languages. That's both good and bad - they actually fit
> Javascript well, since the language allows optional arguments so
> easily, but they bite you when you combine two different ways of being
> optional (passing potentially unnecessary extra arguments to a
> function expecting optional arguments, where the user thinks just of
> the one-argument case).

In one of the links above there was a suggestion of adding
Function.prototype.only(...) as a solution. Though I find that just as
bad since in the case of parseInt you still have to know there was a
problem in the first place requiring this type of solution.