languages that use imperative iterators, like Python and PHP.
And JS -- JS has mutation and objects. It's not going to swerve
toward Haskell (sorry, Claus).
I never understood your automated dislike of Haskell.
You misread me pretty badly here. Why?
Your dislike of Haskell as a reference/model for JS evolution is
explicit in your quoted message. It has been obvious from earlier
exchanges.
My message didn't even mention Haskell - it said that I would prefer
functional APIs to complement JS imperative APIs where possible,
and functional APIs if it is not possible to have both (because
imperative APIs can be implemented in terms of functional APIs
more easily than the other way round).
I never wrote anything showing "dislike" of Haskell. Rather, I said JS's
future standards-based evolution is not going to *swerve* toward
Haskell.
There is no technical argument in there, so it is an opinion, or a
preference/like/dislike.
We are not going to make extra allocations for unwanted next
funargs.
Ok, that touches on a technical argument. I remain to be convinced
that the cost would be high, for the reasons I gave.
I like functional programming. I'm multi-paradigm. JS is too, but not to
this FP-till-it-hurts extent. Objects and functions, not functions first.
"FP-till-it-hurts"? Why the hyperbole? I want objects and functions,
not imperative first.
But if you are
speaking for tc39 when claiming that JS has no aspirations towards
supporting functional APIs when possible, that would be a serious
disappointment. Personally, I believe you're selling JS short here.
Besides misreading me, your recent points have misread "deep" as a
modifier to "continuation", and pushed internal iteration exclusively
(which does not work in all cases as Andy said).
Do you now have a problem with interpreting "deep" continuations?
https://mail.mozilla.org/pipermail/es-discuss/2011-September/016484.html
https://mail.mozilla.org/pipermail/es-discuss/2011-October/017596.html
I did not push internal iteration. I am concerned about composition,
abstraction, and refactoring. In the other thread, I started from the
observation that .forEach does not play with yield, then I tried to
re-implement the built-in for-of as a user-level function and showed
some examples of abstraction being hampered.
These errors really get in the way of your making grander claims or
plans about JS!
Is that necessary?
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
