Destructuring equivalent to nullish coalescing and optional chaining operators?

[liorean]

Hello!

Has any equivalent feature for the nullish coalescing ?? and optional
chaining ?. operators been proposed to paper over the deficiencies of
the destructuring syntax with regards to null values?

If not, I think one should be proposed. For the entire right side of
the binding, an equivalent to the default parameter = operator but
which also works on nulls would do very nicely. Reusing a token that
already exists, it could even be the nullish coalescing ?? operator,
though I feel like it would look neater with for example ?= even
though that would add an extra token to parse.

Likewise, I feel like an equivalent to the optional chaining ?.
operator that permit you to leave parameters undefined if the argument
is null or undefined could be useful. For undefined we can at least
receive an undefined argument and not having it error out using
default parameter {prop}={}, but we cannot do that for null.

I'd like to at least be able to in my function contracts guarantee
that the destructuring part, which is honestly neither the caller's
responsibility (because they cannot change what happens when I
destructure in my parameter list) nor is it the function's
responsibility (because destructuring is supposed to abstract away the
setup so we don't need to do it in the function body), happens without
causing errors. Right now null is a big hole in that - no matter what
we do, the only solution is to move setup into the function body
itself, which is exactly what we have destructuring to avoid.
-- 
David "liorean" Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: native XML object support.

[liorean]

You could already do something like this:

 let
  RawXML=xml`some
content`
 ,XMLApplication=rss`
  
RSS Title
This is an example of an RSS feed
http://www.example.com/main.html
Mon, 06 Sep 2010 00:01:00 + 
Sun, 06 Sep 2009 16:20:00 +
1800

  Example entry
  Here is some text containing an interesting
description.
  http://www.example.com/blog/post/1
  7bd204c6-1655-4c27-aeee-53f933c5395f
   Sun, 06 Sep 2009 16:20:00 +

  
 ` // rss example courtesy wikipedia


And all you'd need is an XML parser for EcmaScript tagged templates, or for
a specific XML application such as RSS, an application specific handler
which would probably be layered on top of such an XML parser. And XML is
actually not that hard to parse, in difference to HTML, thanks to its
draconic error handling. It's actually the XML application handlers that
might get more involved.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Break out of non-loops

[liorean]

The places where break and continue would be most interesting to me in
non-loops would be for dynamic flow control in nested functions or in
callbacks, for example to use in mapping or folding functions, not in
statement context with lexical blocks and labels. Look at Ruby's
next/break/redo/retry for what I mean.
-- 
David "liorean" Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feedback on Iterable Numbers Proposal?

[liorean]

> On Sun, Feb 26, 2017 at 7:40 PM, kdex <k...@kdex.de> wrote:
>> On that note, it might make more sense to add range literals.

On 26 February 2017 at 20:50, T.J. Crowder
<tj.crow...@farsightsoftware.com> wrote:
> That was my thought as well -- or at least, ranges if not range literals. (A
> simple `Range` is trivial to implement, but I'd rather see something
> ubiquitous.) I don't see any active, inactive, stage 0, or finished
> proposals for ranges (they have been discussed:
> https://esdiscuss.org/topic/ranges).
>
> John, to my mind it'd be great to see this same great level of
> attention-to-detail, research, etc., devoted to ranges. I think iterable
> numbers would be too limited to be all that useful (although a subset of
> your proposal would be really simple to add). But I'm just a random guy on
> the list, no idea if the people who actually matter would be interested in a
> range proposal. Ranges have been put to good use in other
> languages/environments (some mentioned in your proposal), so...

I'd like to bring us back a decade for a while:

Lars T Hansen 2007/07/16 13:33
>Multi-dimensional arrays
>
>Consider matrices of floating-point numbers, which we can type as [][double], 
>allocate using x = new [][double](5,8), and dereference as x[1][5]. We can 
>extract subarrays using x[2:4][1:3], maybe (creating a 2×2 matrix). This 
>should not be important for ES4 but it might be important to make sure we can 
>consider it for ES5, somehow.


And 
https://web.archive.org/web/20160425221208/http://wiki.ecmascript.org/doku.php?id=discussion:slice_syntax


The combining of these two features would be a match made in heaven,
and be able to provide Ranges.
-- 
David "liorean" Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "Temp" as a var type

[liorean]

On 24 March 2016 at 14:40, Brian Barnes  wrote:
> That's a good point, "temp" would be a bad keyword.

Actually I think "temp" could be used with very little in the code
break way. Why? Because it wouldn't be a single keyword construct.
There are only a very few cases that are legal in code today where the
token "temp" followed by an identifier token could appear, and those
cases are mostly ASI related and would result in a nop. Since |"temp"
ident|  will in the vast majority of cases be a syntax error, the one
in question would be |"temp" destructassign|. It does not necessarily
clash with identifiers that spell out "temp". I think the actual clash
that you would find there is when you try to use destructuring
assignment of the array type. Possibly some with the object form and
block statements, though I believe the only case where the "temp"
reference is not a nop if written today is the array destructuring
form.

 Not that this would make it a a good idea, just that this particular
argument isn't as strong as you'd maybe think.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[liorean]

> Am 12.03.2016 um 07:27 schrieb Brian Barnes:
>> Request 1: Add a System module, and one call I need System.gc();
>>
>> Why: My game works in two parts; one part creates all the content, and
>> then the second part plays it.  In the second part, I do as much as I
>> can to precreate/re-use any objects or arrays I need, to reduce GC.  On
>> the creation part, I don’t as much.  So being able to force a GC at a
>> point helps me, because it stops the creation part from forcing a pause
>> in the game part.

On 13 March 2016 at 01:05, Christian Mayer <m...@christianmayer.de> wrote:
> On my user-should-experience-no-pause kind of application I'd also love
> to have the possibility to tell the engine to do a GC *now* as it's a
> good time point to do it.

Problem with that is that you're making assumptions that are not
guaranteed about the engine already:
 - That it uses a garbage collector. (I believe it's not entirely
implausible to compile JS to a manually memory managing engine
internal code, and I know that there are engines that never return any
memory while still running, though they might reuse unreachables.)
 - That the eventual garbage collector has certain properties such as
pausing execution.
 - That eventual garbage collector isn't incremental and running very
small slices practically all the time, which might make precise user
code control over it a deoptimisation hazard.
 - That dead object detection, garbage collection, memory compaction
and resource handling is dealt with in the ways of a typical
conservative mark & sweep fashion.
 - That ECMAScript actually specifies any of this. Neither garbage
collection, nor memory handling strategies are a part of the spec. In
fact, the word "memory" is only mentioned three places in the entire
ECMAScript 2015 spec, and "garbage collection" only once.

-- 
David "liorean" Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Curried functions

[liorean]

Well, as I see it, there is nothing that currently could be done with
regards to this if what you desire is to make it automatic.
What we could add are various ways of manually doing this, either as
syntax or as library extensions. And then comes the question of which
way and what exactly.

Are you talking about pure currying, that is, taking a multiple
parameter function and turning if into a series of it's arity many
single argument functions, i.e:
(a,b,c)=>a+b+c
-->
 a=>b=>c=>a+b+c
?

Are you talking about partial application,i.e:
(a,b,c)=>a+b+c
-->
(a,b,c..._)=>a+b+c
OR
(a,b)=>(c,..._)=>a+b+c
OR
a=>(b,c,..._)=>a+b+c
OR
a=>b=>(c,..._)=>a+b+c
And where any zero argument applications return the same function?

Is it currying or partial application you want? How do you handle
functions that take rest parameters, optional parameters, true
variadric functions like e.g. sum that is theoretically zero to
infinity arity? or whose arity with regards to partial application
(and not the formal functionobject.length arity) is dependent on the
contents of those arguments? How do you handle this value? How do you
handle arguments object? How do you handle named autorecursion? Do you
want to be able to do this for constructors as well? How about getters
and setters? Generators? How do you handle extremely high argument
counts? How do you handle defaults? How do you handle argumentless
applications?

Automating this is in the language as it is would be a no-go for
backwards compatibility reasons I would say. Possibly you could have
manual currying, like what I wrote for rosettacode here:
<http://rosettacode.org/wiki/Currying#Generic_currying_for_ECMAScript_2015.28ES6.29>
Note the several caveats in that code. And sure, you could add syntax
for it instead of using a function like I do there, but it's still the
same explicit action, so would syntax really help in any way?
And for several cases you'd actually have to make a decision and stick
to it, or implement all the alternatives. Just see how I had to deal
with rest arguments there, because without two different versions, I
would have to choose either to handle rest arguments always with a
separate application, or never. If you want partial application,
that's slightly different in a few ways, but not notably harder.

-- 
David "liorean" Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Curried functions

[liorean]

On 17 Oct 2015 04:48, "Yongxu Ren"  wrote:
>
> How about we use a different approach?
>
> Instead of allowing ```a(b)(c)``` for ```let a = (b,c) => b+c;```,
>
> Maybe we can use ```a(b,c)``` for ```let a = b => c => b + c```?

Would that do any of the useful stuff you could reasonably want either
currying or partial application for, though? I mean the main use is that it
allows us to do
let d=a(b);
...
d(c);
And I don't really see how your desugaring a single multiple argument
application into several single parameter curried functions allows that
usefulness.

It's the multiple applications to fill single parameter list thing that is
the most useful part of it, mostly as it allows caching the closure at any
step for reuse, not single application to fill multiple sequential single
parameter lists. Also, consider rest parameters, defaults etc. and whether
doing what you want for the simple example case would have weird or
possibly ambiguous meaning. Also, what happens to this value if the
functions are old style and not new style?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Playing with variadric fix point combinators in ES6

[liorean]

I've been playing around with the new syntax for a while, and while
searching for a way to get the familiar applicative order Y combinator
to handle mutually recursive functions hadn't managed to find a
JavaScript example, just Python, Haskell, Scheme, OCaml and of course
pure lambda calculus. So I wrote one, though there is really no
original work involved except for direct transposition. If anyone
wants to program without variables ;) here's a helper for you-

http://lpaste.net/130856 or http://www.es6fiddle.com/i8laijui/
-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Nailing object property order

[liorean]

I'm very much opposed to locking this down for general objects because
it locks the implementation choices for generic objects down. What if
the engine backing implementation was, say, some variation of a trie
for instance? It cannot really be done today without adding extraneous
data into the structure, because lookup in that case happens on a
character by character basis, not on a whole string basis, so
properties that use common prefixes would always end up adjacent and
even if the keys weren't inserted in order by bit patterns into the
trie as most implementations do, they would still be grouped by common
prefix.
-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array comprehensions with Spread operator

[liorean]

On 15 April 2015 at 18:36, Jeremy Martin jmar...@gmail.com wrote:
 Thanks, I gathered so after your response. This is why 99% of the time I
 wait for at least one other person to reply first, and why I should wait the
 remaining 1%... :)

Heck no!  You asking that question clarified the problem statement and
highlit that the example wasn't the perfect example code. Always good
to get assumptions checked and explanations of why alternative
solutions to specific use cases aren't what the issue is about.

For the record, what I can see, the code in the example is broken in
another way as well, the «i» in the reality example is not the
variable name used in the for-of.

Really, for these cases, I'd probably do something like a chained
reduce, somewhat like this:
«
js let x=[0,1,2],y=[3,4,5],z=[6,7,8];
js let flatten=(p,c)=([...p,c]);
js let add=(p,c)=((+p)+(+c));
js let concat=(p,c)=(''+p+c);
js let multireduce=(f,r)=(a,...b)=(a===void
0)?r:multireduce(f,a.reduce(f,r))(...b);
js multireduce(flatten,[])(x,y,z);
[0, 1, 2, 3, 4, 5, 6, 7, 8]
js multireduce(add,0)(x,y,z);
36
js multireduce(concat,'')(x,y,z);
012345678
»

you could even edit that «multireduce» so that the no-initval variants
work, though I'm not bored enough to continue this exercise any
longer.
--
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Syntax sugar for partial application

[liorean]

On 12 April 2015 at 17:39, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
 No, «this» is lexically bound to be that of the enclosing lexical
 scope in arrow functions, so it would be whatever that is. But that
 doesn't really matter as the function call to «foo» doesn't use the
 «this» of the arrow function.

 Exactly why you get `null` as `this`.

Which makes the behaviour identical to that of the code as you wrote it.

 Now, if we were to say your «foo» were actually «foo.bar», and you did
 the same replacement in the arrow function, the «this» value of the
 «bar» call would be «foo», so that's pretty much what is wanted as
 well. The case where this breaks is if you were to replace only the
 «bar» method with the arrow function, in which case it would use the
 lexical «this» instead of «foo», but that's obviously not the right
 transformation to use.

  This might not seem like such a big deal until you consider it in
  combination with the proposed bind syntax [1].
 
  Also in your examples, redefining `foo` will lead to different results.
  The
  placeholder syntax has a lot more room for optimization in the JIT
  compiler
  (the partially applied result is guaranteed to have no side effects for
  example, so the compiler can create a version of the original function
  where
  it can inline the specified arguments; less moving parts, easier to
  optimize).

 Yeah, it's susceptible to that problem, yes. Do you want me to fix
 that for you if you really want it?

 Your «foo(1, ?, 2);» is equivalent to «((f,a)=f(1,a,2))(foo)».

 Your «foo(?, 1, ???);» is equivalent to «((f,a,...b)=f(a,1,...b))(foo)».
 Your «foo(1, ???, 2);» is equivalent to
 «((f,...a)=f(...[1,...a,2]))(foo)».


 Your new examples directly execute the function instead of creating a new
 function. :) Which goes to show how it would be nice to have specific syntax
 for this to make it more obvious what's happening.

Oops. I needed to actually add that extra argument as a separate fat arrow,
   «(f=(...a)=f(...[1,...a,2]))(foo)» etc.

 I write my code pretty much the same way. However, it's hard for the
 compiler to trust that you're not changing things, regardless of style.

Guess it'd be hard for it unless it has the knowledge of whether
functions are pure or not, yes.

I'd love for a compiler that can tell that I don't modify my arguments
and thus optimises code like
«
let map= // Usage: map(function)(...array)
(f,...acc)=(head,...tail)=(
undefined===head
?acc
:map(f,...acc,f(head))(...tail));
»

So that it doesn't actually create the «tail» array every recursion,
just a narrower and narrower subarray of the same actual array, and
likewise that the only thing that is done with «acc» is the production
of an array that is identical to it with an addition of one element at
its end, so doesn't break it down and rebuild it every recursion. And
of course tail call optimisation on it, because that code is horrid
without those optimisations.
-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Syntax sugar for partial application

[liorean]

On 9 April 2015 at 16:11, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote:
 On Thu, Apr 9, 2015 at 4:04 PM, liorean lior...@gmail.com wrote:

 Do we really need it?
 Your «foo(1, ?, 2);» is equivalent to «a=foo(1,a,2)».
 Your «foo(?, 1, ???);» is equivalent to «(a,...b)=foo(a,1,...b)».
 Your «foo(1, ???, 2);» is equivalent to «(...a)=foo(...[1,...a,2])».


 Not exactly. Using the placeholder syntax, `this` remains context dependent,
 whereas with your examples you get `null` as `this`.

No, «this» is lexically bound to be that of the enclosing lexical
scope in arrow functions, so it would be whatever that is. But that
doesn't really matter as the function call to «foo» doesn't use the
«this» of the arrow function.

Now, if we were to say your «foo» were actually «foo.bar», and you did
the same replacement in the arrow function, the «this» value of the
«bar» call would be «foo», so that's pretty much what is wanted as
well. The case where this breaks is if you were to replace only the
«bar» method with the arrow function, in which case it would use the
lexical «this» instead of «foo», but that's obviously not the right
transformation to use.

 This might not seem like such a big deal until you consider it in
 combination with the proposed bind syntax [1].

 Also in your examples, redefining `foo` will lead to different results. The
 placeholder syntax has a lot more room for optimization in the JIT compiler
 (the partially applied result is guaranteed to have no side effects for
 example, so the compiler can create a version of the original function where
 it can inline the specified arguments; less moving parts, easier to
 optimize).

Yeah, it's susceptible to that problem, yes. Do you want me to fix
that for you if you really want it?

Your «foo(1, ?, 2);» is equivalent to «((f,a)=f(1,a,2))(foo)».
Your «foo(?, 1, ???);» is equivalent to «((f,a,...b)=f(a,1,...b))(foo)».
Your «foo(1, ???, 2);» is equivalent to «((f,...a)=f(...[1,...a,2]))(foo)».





I guess I didn't think of these cases though, because I only use
explicit arguments to my functions these days, I never use the «this»
keyword. If I want a function to operate on an object, I pass that
object into the function.
I also try to not reuse my variables unless they are part of an
iteration, in which case they are always local variables that are only
handled in the iteration process itself. But that's a side issue, as
it's about my code rather than precepts of the language.
-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Syntax sugar for partial application

[liorean]

Do we really need it?
Your «foo(1, ?, 2);» is equivalent to «a=foo(1,a,2)».
Your «foo(?, 1, ???);» is equivalent to «(a,...b)=foo(a,1,...b)».
Your «foo(1, ???, 2);» is equivalent to «(...a)=foo(...[1,...a,2])».

Also, the ? token is already taken by the ternary conditional
operator. Do we really want to overload it here for a nullary
operator/special form, when we have as low overhead syntax as we
already do in fat arrows for doing the exact same thing?
-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[liorean]

As I see it, what might be more desireable than a straight shallow feature
test or feature support reporting feature would be an official versioned
test library, possibly including tests of pure internals, and a new
standard api for asking the engine for the results it gets for running a
certain test or set of tests. The engine could then either have its results
collected at build time and cashed results for that particular build built
into the api, or allow the user to require the result of getting the test
and executing it live, with the issues that comes with that. One possible
result, except the obvious success and fail, is of course that a certain
test didn't exist at the time of the build and thus not tested.

Of course, the earliest something like that could be in the language would
be ECMAScript 7...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The global object as the global scope instance object

[liorean]

 Andreas Rossberg mailto:rossb...@google.com
 January 24, 2012 12:22 PM
 Of course, I sincerely hope that the module system will provide a more
 pleasant replacement for this pattern. :)

On 24 January 2012 21:59, Brendan Eich bren...@mozilla.org wrote:
 But what? If it's let-based I'd like to know how it could work.

Since let is new syntax anyway, why not add a syntactical way of doing
the definition conditionally?

let varname if absent = value;

-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[liorean]

2012/1/10 Herby Vojčík he...@mailbox.sk:
 P.S.: I would bet 99% of developers thinks the model is in fact fallback
 delegation. :-/ It is simpler model that works most of the time. Always
 write locally, always read locally and then look up the prototype chain.

I think that's a question of making a fallacy of equivocation. The
localisation when reading from or writing to a property is a matter of
the value contained in that slot. The access or write permission of
that property is a matter of the actual slot.

-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.concat result length (ES5.1)

[liorean]

 On 07/14/2011 10:04 AM, Allen Wirfs-Brock wrote:
 It is probably a bug, because array index based operations generally warp
 around to 0 at 2^32.

On 18 July 2011 19:51, Jeff Walden jwalden...@mit.edu wrote:
 Removing all the RangeError stuff, and making array indexes just
 non-negative integers,  would be nice for ES6 or similar.  I suspect
 changing that won't break anyone worth caring about, although I do know some
 people have taken the time to care about this in the past (mostly in a
 spec-nut way :-) ):

 http://hexmen.com/blog/2006/12/push-and-pop/

Hmm. That link has the following to say:
-
Steps 3 – 6 of push are a little ambiguous, and the specification
probably should have stated that repeated increments to n must be done
using 32-bit unsigned integer arithmetic – it’s kind-of implicit as n
is assigned the result of the internal ToUint32 operator. Using 32-bit
arithmetic leads to some strange edge-cases: when n overflows from
232-1 to 0, push will have set a property called 4294967295. This is
strange, as 429496795 is not an array index (as discussed above), but
at least it means the property-value will still be available after the
inevitable array-truncation (when length is set to some small value in
step 8.)


That is actually contrary to my reading of ECMA-262 3ed. intentions. I
assume 5 ed. has the same intentions, but I have not checked it. The
way I read those intentions is as you can see in the error I reported
in my comment to:

http://blogs.msdn.com/b/jscript/archive/2008/03/25/performance-optimization-of-arrays-part-i.aspx
(Opera fixed a different but related bug in the same algorithms in
Futhark to follow the correct handling (as I read the spec). Carakan
today I don't know about.)

For those not wanting to go searching for my comment and sifting
through that text: The algorithm in question uses ToUInt32 to convert
the value, but the storage is not as uint32 but as pretty much
everywhere in ECMAScript, Number, thus follows normal double
arithmetics. This is particularly of note as it means that it should
not wrap around - the purpose of the following parts of 15.4.5.1
[[Put]] (P, V):

12. Compute ToUint32(V).

13. If Result(12) is not equal to ToNumber(V), throw a RangeError exception.

14. For every integer k that is less than the value of the length
property of A but not less than Result(12), if A itself has a property
(not an inherited property) named ToString(k), then delete that
property.

15. Set the value of property P of A to Result(12).

is to, at step 13, catch the specific event of trying to exceed uint32
size with the length property and throw an error *instead of* wrapping
around and as a result of step 14 of above algorithm destroy
properties on the array. Wrapping around is an error, because ToUInt32
gives not a uint32 but a Number which can fit into a unit32 as result.
IIRC the 3ed. spec never uses any other number format than Number, it
only performs the operations to fit an input Number type into the
limitations of those other number types, into an output of Number
type.
-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array generation

[liorean]

On 10 July 2011 22:23, David Herman dher...@mozilla.com wrote:
 Another common and useful fusion of two traversals that's in many Schemes is 
 map-filter or filter-map:

    a.filterMap(f) ~~~ [res for [i,x] of items(a) let (res = f(x, i)) if (res 
 !== void 0)]

 I rather arbitrarily chose to accept both null and undefined here as way to 
 say no element -- a reasonable alternative would be to accept *only* 
 undefined as no element.

The way I think of it is that in analogy to NaN being the Numbers that
represent no number, null is the Object that represents no object, in
other words a reasonable value to store to tell just that. The
undefined value is by analogy the value that represents no value, so
is the only value that should be a no element.

But that might be just my way of thinking about and distinguishing the
not-a-something special cases.
-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bringing setTimeout to ECMAScript

[liorean]

On 18 March 2011 17:25, Wes Garland w...@page.ca wrote:
 Right: the barrier to setTimeout functionality is that ECMAscript does not
 define a concurrency model.

 If we can define a concurrency model, then we can build setTimeout.

 Two things off the top of my head to consider:
  - timer granularity
  - forbidding eval-like syntax

 OTOH, if we have an event-loop system with conditionals, we might not need
 setTimeout because it would be trivial to build from primitives. But it
 might be a handy interface if ES starts to go toward the batteries
 included model.


As I understand it, this type of thing was kept out of the language
proper intentionally, because of its strong dependency on host
environment. Some host environments may require tight and overriding
control of any event handling system, and exactly which types of
events (such as timeouts) are suitable to an environment may vary. A
server side host might not want to have to deal with asynchronous
activity at all, for instance.

-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property Iteration in JSON serialization

[liorean]

If I recall correct, Opera has a weird behaviour where it follows a
certain predictable ordering - unless you're deleting/removing a
property (or use prototype functions that do that in their operation)
on an object, which radically changes the sorting order in a way that
is only predictable with knowledge of how the object looked at the
time of the deleting/removing of a property. IIRC the properties
present on the object before the delete got shuffled to the end of the
enumeration order.
-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Operators ||= and =

[liorean]

 On Tue, May 5, 2009 at 11:37 AM, Peter Michaux petermich...@gmail.com wrote:
  function(a=1, b=defaultVal);

 And in this syntax will default values be used if the parameter is
 falsey or only if it is undefined?

2009/5/5 Mark S. Miller erig...@google.com:
 Or only if it is absent?

I've been out of the ECMAScript world for many months now, but IIRC in
ES3 all formal parameters that are absent gets initiated to the value
undefined. Not sure which side of the function call border that
initiation takes place on, though. Wouldn't special casing absence
from undefined value effectively introduce another state for a
variable to be in, though, since the behaviour is indistinguishable in
user code in ES3?
-- 
David liorean Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: In what ways does the following eval regularity break?

[liorean]

Why not introdouce one localEval that evaluates in local scope but
does not allow modifying the local scope, a globalEval that evaluates
in the global scope, and maybe an expressionEval which allows
anonymous function literals and parses { as the beginning of an object
literal instead of a block statement?

That should cover current usage of eval except for the case of wanting
to inject variables into the scope. Which would mean dropping eval in
strict mode isn't that awful an idea.
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Indirect eval experiment

[liorean]

2008/10/30 Mark S. Miller [EMAIL PROTECTED]:
 function foo(a, b, c) { return b(c); }
 foo(3, eval, 'a'); // yields 3

Doesn't work in Opera, and IIRC ES3 has it that the engine does not
need to allow this kind of use of eval at all.
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: return when desugaring to closures

[liorean]

 Please specify what you are proposing.  The one proposal I've seen is:

 Expression ::= ... | lambda Formals Statement

 Dave Herman wrote:
 Yes, that's what I meant, or at least what I thought Yuh-Ruey meant.

 This is not particularly useful because then even assign a lambda to a
 variable would be a syntax error,

 Why is that?

2008/10/15 Waldemar Horwat [EMAIL PROTECTED]:
 Because there exists no sequence of grammar production expansions that would 
 expand to a = lambda() x;.

Only if you disallow newlines in the lambda syntax. This is certainly
allowed in ES3:

a=lambda()
x;

Same goes for

a=lambda
{...}

or

a=lambda(...)
{...}
(...)

or any number of similar plays with the semicolon insertion rules.
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Revenge of the double-curly [Was: return when desugaring to closures]

[liorean]

 On 2008-10-10, at 02:29EDT, Brendan Eich wrote:
 An agreement from TC39 this past sprint was that function definitions
 directly nested in blocks, not specified by ES3, defined block-local
 (let) bindings.

2008/10/10 P T Withington [EMAIL PROTECTED]:
 Holy smokes.  Does that mean we are all going to be writing

   function ... () {{
 ...
   }}

 to get 'normal' scoping of function body declarations???  Will `var`
 mean `let` in those double-curly bodies?  Might as well let `let` not
 be a keyword...

Haven't we been through this before? ES3 doesn't allow this, but all
browsers do allow it. And all browsers have slightly or entirely
different behaviour. The behaviour of Opera and IE on one hand and
Mozilla and Safari on the other hand is entirely incompatible.

The Harmony decision is incompatible with all browsers, because the
function wouldn't be usable before the block (breaks IE and Opera
behaviour) and would fall out of scope when the block exits (breaks
Mozilla and Safari behaviour).


For example, this works in Mozilla:
if(true){
function fn(){return 'then-path';}
}else{
function fn(){return 'else-path';}
}
fn(); // = 'then-path'

This would be broken by the Harmony design. On the other hand, the
other browsers will result in 'else-path' in the current situation.
(Is this a change in Safari? Unless I'm misremembering the results
last time bundled Safari with Mozilla on this one.)
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Encodings

[liorean]

Hello!

Just wondering if anybody has any real world data lying around
covering what character encodings are necessary to support real world
script content. UTF-8, UTF-16 and ISO-8859-1 are a given guess. What
else?
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Arguments and formal parameters aliasing

[liorean]

Hello!

I just noticed an inconsistency between the ES3 spec and browsers that
I've not seen discussed before. At the moment I'm on my iBook, so
these are not the most recent browsers, but they include ie5.2m, ff2,
saf1.3 and op9.5.


function fn(a, b, c, d, a, b, c, e){
arguments[7]='e';
b='g';
return [
'a: '+a+'  arg0: '+arguments[0],
'b: '+b+'  arg1: '+arguments[1],
'c: '+c+'  arg2: '+arguments[2],
'd: '+d+'  arg3: '+arguments[3],
'a: '+a+'  arg4: '+arguments[4],
'b: '+b+'  arg5: '+arguments[5],
'c: '+c+'  arg6: '+arguments[6],
'e: '+e+'  arg7: '+arguments[7]]
.join('\r\n');
}

fn('a','b','c','d','e','f');

Results from ff2, op5 and ie5.2m are:
a: e  arg0: a
b: g  arg1: b
c: undefined  arg2: c
d: d  arg3: d
a: e  arg4: e
b: g  arg5: g
c: undefined  arg6: undefined
e: undefined  arg7: e

Results from saf1.3 are:
a: e  arg0: a
b: g  arg1: b
c: undefined  arg2: c
d: d  arg3: d
a: e  arg4: e
b: g  arg5: f
c: undefined  arg6: undefined
e: undefined  arg7: e

I haven't been able to test this since I'm not on a windows machine,
but IIRC Chrome will alias e and arg7 but otherwise behave like
moz/op/ie. I also suspect that later saf versions than 1.3 will
correctly alias b with arg5.



The ES3 spec has the following to say about this:
10.1.3 Variable Instantiation
...
 •  For function code: for each formal parameter, as defined in the
FormalParameterList, create a property of the  variable object whose
name is the Identifier and whose attributes are determined by the type
of code. The values  of the parameters are supplied by the caller as
arguments to [[Call]]. If the caller supplies fewer parameter values
than there are formal parameters, the extra formal parameters have
value undefined. If two or more formal  parameters share the same
name, hence the same property, the corresponding property is given the
value that  was supplied for the last parameter with this name. If the
value of this last parameter was not supplied by the  caller, the
value of the corresponding property is undefined.
...
/
In other words saying that two formal parameters with the same
identifier are the same variable, and that the last one in the
parameter list will be the one giving the variable a value.
10.1.8 Arguments Object
...
 •  For each non-negative integer, arg, less than the value of the
length property, a property is created with name  ToString(arg) and
property attributes { DontEnum }. The initial value of this property
is the value of the  corresponding actual parameter supplied by the
caller. The first actual parameter value corresponds to arg = 0,  the
second to arg = 1, and so on. In the case when arg is less than the
number of formal parameters for the  Function object, this property
shares its value with the corresponding property of the activation
object. This  means that changing this property changes the
corresponding property of the activation object and vice versa.
/
And this says that each argument sent is aliased to the corresponding
formal parameter's variable. Given the behaviour of several parameters
with identical identifier earlier, and no exception being given for
this case, I can only read this as meaning that the browser
implementations go contrary to the ES3 spec regarding arg0, arg1 ,
arg2 and the a, b and c variables not being being aliased. It seems
the browser scripting engines only alias the last argument
corresponding to any given formal parameter identifier with the
corresponding variable, even though these are supposed to be the same
variable.


Something to address in ES3.1, given at least three, probably four
implementors disagree with the ES3 spec?
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strengthening Function.prototype.toString

[liorean]

 2008/9/26 Erik Arvidsson [EMAIL PROTECTED]:
 I know that Opera on mobile phones used to return a string
 representation that did not reflect the original.

 On Fri, 26 Sep 2008 19:58:27 +0200, liorean [EMAIL PROTECTED] wrote:
 Yeah. Opera Mobile returned [ECMAScript code] or [ecmascript
 code]. This was contrary to the ES3 spec (must be parsable as a
 function definition, IIRC) and also breaks the eval roundtripping by
 throwing a parse error.
 Anybody know if those issues have been fixed in more modern versions?

2008/9/26 Hallvord R. M. Steen [EMAIL PROTECTED]:
 No, not consistently across modern versions. It's not likely to be
 properly fixed for a while yet. The reason is that on many platforms where
 memory is scarce, not enabling JS decompilation helps reduce memory
 requirements.

You can fix the ES3 spec compliancy by simply returning
function(){/*decompilation disabled*/} or something like that
instead of [ecmascript code]. You could also fix the eval
roundtripping using for example
function(){opera.getFunction('UniqueFunctionID').apply(this,arguments);}
as a way to without decompiling allow roundtripping.
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

[liorean]

 On Sep 15, 2008, at 3:23 PM, Brendan Eich wrote:
 I agree with Mark about callee. Just say no, if we can wean folks off
 of it.

2008/9/16 William Edney [EMAIL PROTECTED]:
 Easier said than done. Not impossible (well, nothing's impossible),
 but its very problematic.

 There's a number of use cases given earlier on this thread. Here's
 another one:

 myElem.addEventListener('click', function () { doSomething();
 this.removeEventListener('click', arguments.callee, false)}, false);

 Could I do an assignment of the handler? Sure, but syntactically
 suboptimal, IMHO.

Once JScript has fixed the function name scope bug, you could use

myElem.addEventListener(
'click',
function f(){
doSomething();
this.removeEventListener(
'click',
f,
false);},
false);

 Stack backtracing deserves a separate thread.
 Agreed - although I would like to term this 'stack access', denoting
 more than just 'backtracing' capability :-). Also, this information
 should be available in any context, not just in an exception handler.
 Of course, I realize that I'm on the other end of the spectrum from
 the minimalists here :-).

There's security concerns here. You don't want to make locals
accessible from scopes that are not lexically enclosed, not even if
those locals are arguments to the function. You don't want to make
inner functions visible or ToString-able just because they are on the
call stack. You don't want to break the scope privacy, in other words.

I'm inclined to believe that the best you can do with regard to the
call stack would be to give each function a unique one-way
identification system and function calls a unique identifier as well
(so recursive calls would have the same function IDs but different
call IDs). Allow an API for the entire call stack to be exposed in
terms of a list of pairs of these two IDs. Then you can compare the
function ID to the ID of any lexically known function (or provide an
API for looking up a function object in *only* the current scope chain
by function ID), The call ID shouldn't provide any lookup facility
since we don't want to make activation frames first class objects. But
I can see that an API for traversing the call stack based on these two
IDs together should be useful. The reason for the function ID instead
function object should be clear - some of those functions may not be
lexically visible in the current scope, so shouldn't be exposed.
Calling functions from outside your own closest enclosing scope should
not be an escape mechanism for inner function objects.

That's not a strongly held opinion, however - reflection is bloody
useful in some situations, particularly for debugging.
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is the following a bug that needs to be fixed for ES 3.1?

[liorean]

2008/9/4 Michael Daumling [EMAIL PROTECTED]:
 The following code produces a first is not a function error:



 Array.prototype.first = function()

   { return this.length == 0 ? null : this[0]; }

 // no semicolon here

 (function() { if ([1,2].first() == 1) alert (OK); }())

That's a quite well defined part of automatic semicolon insertion. I
don't think it's possible to do anything about it for general script.
In a stricter syntax mode or with an external opt-in, one could
possibly turn off automatic semicolon insertion except for when
semicolons are redundant (such as before closing curlies).

 IMHO, there should be a rule that if a function-expression is followed by
 anything with brackets (), it would require the function-expression to be
 bracketed as well, otherwise, the bracketed statement does not become part
 of the assignment.

Not only is that a radical complexification of the automatic semicolon
insertion mechanism, it's also an incompatible one.

 Can/should this be fixed for 3.1?

Doesn't sound like something for 3.1, and I wouldn't want to see it in Harmony.
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decimal operator behaviors

[liorean]

2008/8/27 Sam Ruby [EMAIL PROTECTED]:
 I've updated my SpiderMonkey branch based on my understanding of the
 outcome of the past few days of discussion, and would appreciate any
 input that people may have on any other operators.  To facilitate this
 discussion, I've produced the following sets of tables:

  http://intertwingly.net/stories/2008/08/27/estest.html

I would be interested in seeing some tests covering the behaviour of
negative infinity and negative zero as well (for comparison with the
binary double equivalents's behaviour).
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Es-discuss - several decimal discussions

[liorean]

 2008/8/24 Brendan Eich [EMAIL PROTECTED]:
 Premature generalization without implementation and user experience is
 unwarranted. What would Object.eq(NaN, NaN) do, return true? Never!

2008/8/24 Mark S. Miller [EMAIL PROTECTED]:
 Object.eq(NaN, NaN) should indeed return true.

/ snip /

 With decimal postponed, we don't need to settle this now. But
 JavaScript has no well behaved *equality* operator. As
 http://en.wikipedia.org/wiki/Equivalence_relation explains, for a
 predicate P to be an equivalence relationship (and thereby to define
 equivalence classes), it should be
 * reflexive: forall x: P(x,x)
 * symmetric: forall x,y: P(x,y) implies P(y,x)
 * transitive: forall x,y,z: P(x,y)  P(y,z) implies P(x,z)

 However,
 * == is not reflexive or transitive. In the Caja project, when we have
 occasionally violated our own style and used ==, we've always
 regretted it.
 * === is not reflexive. Fortunately, there's only one value on which
 it isn't, NaN, so code picking off this special case can guard uses of
 === which is otherwise well behaved.

And I'd argue that you're wrong there. NaN isn't a single value. If
you did === on the object that turned into NaN when converted into a
number you'd get true, because that's one specific value you're
comparing to itself. But NaN represents *any arbitrary value* in the
infinite set of values that cannot be converted into numbers, not a
*specific value* in that set. Which means that the likelyhood of two
NaNs representing the same value approaches zero and is statistically
insignificant.

In other words, NaN should never equal NaN using any equality
operator, unless you build your number system so that NaNs remember
what specific value they were converted from and do an object
comparison instead of number comparison for those. Which is not the
case for ECMAScript.
-- 
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss