Re: Are ES6 modules in browsers going to get loaded level-by-level?

[J Decker]

On Thu, Oct 22, 2020 at 2:23 PM #!/JoePea  wrote:

> >  It's caused me some headaches especially when dealing with
> inheritance/extends and in workers.
>
> Like, extending from a `Module` object?
>
> > Maybe someday we'll have a `modules` collection we can interrogate.
>
> That may be nice, to query which modules have already been imported, etc.
>
> It would also be great if we could unload modules.
>
> ---
>
> Skypack is making news rounds as an ESM server: http://skypack.dev/
>
> It says it supports HTTP/2 and HTTP/3. But it isn't open source.
>
> Seems that there isn't any open source solution (otherwise I'm sure
> people would be using that over bundling if it works out better, at
> least alternatives to skypack would exist, f.e. well-know projects
> like React, Angular, Vue, Svelte, etc, could all have their own ES
> Module servers if it was viable).
>
> Seems that there hasn't been any free/open project to prove viability
> yet, and the existing ones are closed source.
>
> Seems that even http://jspm.dev is closed source.
>
> Looks like at this point in time people are aiming to make money from
> ESM servers, and there's no viable open source ESM server solution.
>
> Seems like it wouldn't be a LOT of work to take Acorn (
https://www.npmjs.com/package/acorn ) and http server (
https://www.npmjs.com/package/http ) and parse the pages loaded if
(*.[cm]+js) (something)

Though my observation is that when the browser gets the first page, async
requests go out for more content even before it's actually interpreted/run
the script; and the requests are streamed over one or more http(s)
connections.  this screenshot https://pasteboard.co/JwUnbAD.png  of this
demo http://d3x0r.github.io/Voxelarium.js/  shows the network load time;
recently updated to imports and non-built scripts...though I do see a
gap where the html script loading ends and the imports in the scripts
actually go... but that could also be the pause setting up the opengl
surface... it's about 50ms.

since 'import' is itself async I sort of expected a lot of overlap in the
requests; there's only a single network wire, so there's not a LOT to be
gained parallelizing things.

If there was even some sort of manifest could make a background service
worker (which itself doesn't support import
https://bugs.chromium.org/p/chromium/issues/detail?id=680046 ) which can
behave like a offline storage/cache so the server can dump requests to the
client before it knows to ask for them... and then it doesn't have to ask
the server for anything  at all later even; which sort of de-emphasizes all
the work put into the server in the first place :)

J

#!/JoePea
>
> On Sun, Oct 18, 2020 at 8:50 AM Randy Buchholz 
> wrote:
> >
> > Right, it's basically just doing what an import aware server might do
> and the type-tree is a hierarchal version of the scope imports. The rest is
> just extra stuff. Probably the biggest difference though is that it lets me
> isolate prototypes. From what I gather it seems that import stores a live
> "ghosted" version of the prototype that it checks before making additional
> requests for the item. The scope basically gets a reference to this
> prototype. If you do things like add a property with reflect in one scope
> that property shows up everywhere. And since it modified the "ghost" it
> persists after the scope goes away. It's caused me some headaches
> especially when dealing with inheritance/extends and in workers.
> >
> > Yeah, inspecting is in issue. I haven't found a way to inspect modules
> to see what they have in them. They're a strange beast. You can see their
> scope in the debugger and they look like an ES Object or IDL interface, but
> I don't know how to get a reference to them in code. But, they're new, so
> we'll see where they go. Maybe someday we'll have a `modules` collection we
> can interrogate.
> >
> > -Original Message-
> > From: #!/JoePea 
> > Sent: Saturday, October 17, 2020 10:35 PM
> > To: Randy Buchholz 
> > Cc: es-discuss@mozilla.org
> > Subject: Re: Are ES6 modules in browsers going to get loaded
> level-by-level?
> >
> > That's neat, but it seems like the same work that a server would have to
> do with actual ES Module imports, right? And the "type tree"
> > equivalent is the modules that the JS engine stores as a map from import
> identifier to module scope instance. It seems that in the end, the `PUSH`
> approach should work with the same efficiency, right?
> >
> > Seems the only thing that makes it difficult is checking the map. In
> your special case, with `inject`, you can physically check the global
> namespaces to see if the module is available. But with ES Modules, we can't
> check if some module has already been lodade by its identifier, can we? So
> we have to make the request, because that's the only way to check.
> >
> > #!/JoePea
> >
> > On Sat, Oct 17, 2020 at 1:28 PM Randy Buchholz 
> wrote:
> > >
> > > I think some form of bundling will always be necessary. I use classes

Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

[J Decker]

On Sat, Oct 10, 2020 at 5:19 PM #!/JoePea  wrote:

> It's 5 years later, but still no (obvious) sign of HTTP/2 servers
> specialized in ES Module push.
>
What does it mean to specialize in module push?  How can modules be pushed
without the browser requesting them?  Is it a server that reads the scripts
and pre-feeds the scripts?


>
> Do any exist? Anyone have a list? I'm especially interested in the
> self-hostable servers, but also curious about solutions where we may
> publish modules to.
>
> The non-self-hosted solutions may be attractive to those people who
> normally publish static sites and need to publish ES Modules as static
> resources somewhere without the fuss if managing a server.
>
> Oh - it's to update into the server?

J

>

> #!/JoePea
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: RAII in javascript

[J Decker]

Chrome just put out a intent to ship Weak References

https://www.chromestatus.com/feature/5892186633666560
https://bugzilla.mozilla.org/show_bug.cgi?id=1367476#c6

Yes; for some things knowing when the related JS object goes away is really
needed; but it's recommended to be used sparingly (although I can see one
could instrument like everything that gets made to be able to track it)


On Fri, Apr 17, 2020 at 12:45 PM Ben Manashirov  wrote:

> Hello,
>
> It's easy to leak data in javascript because you need to call free(), or
> destroy() for various objects, for example when interfacing with OpenGL,
> emscripten, or some other object that needs to do cleanup beyond what a
> garbage collector can handle. I really want guaranteed destructors in
> javascript, it will make my life so much easier. I don't want anything
> similar to try-release that is introduced to Java because that doesn't
> solve the problem, it just moves the problem of having to call free/destroy
> to having to remember to list it in a try-release statement. Perhaps add a
> destructor() or destroy() as many libraries use destroy(). and if one
> exists treat the object with care to have it destroyed as soon as it's no
> longer referenced. Doing it for destroy() may break existing code so a
> another name would probably be better that people can migrate to, perhaps a
> special keyword in class{} interface 'destructor', and if one exists then
> special care will be given and a autogenerated 'destroy()' function is
> automatically created that a person can call to do destruction if they
> desire to do so earlier than when no more references are pointing to it.
>
> I hope this discussion will lead to some solution.
>
> Thank you.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Curly Braces in JavaScript

[J Decker]

On Sun, Nov 3, 2019 at 1:11 PM Ed Saleh  wrote:

> Yes, I know JavaScript is influenced by the C syntax family, which is my
> favorite style. However, what I pushed for here is kind of merging of 2
> programming languages families. We here are talking good attributes from
> Python and adding it to JavaScript.
>
Significant whitespace was the worst idea Python implemented.  Forced
formatting is HORRIBLE.
And a lack of braces also makes re-nesting code and evolution more
difficult.
Neither of these are good things for or from Python.

> --
> *From:* Ed Saleh 
> *Sent:* Sunday, November 3, 2019 4:08:37 PM
> *To:* Bergi ; es-discuss@mozilla.org <
> es-discuss@mozilla.org>
> *Subject:* Re: Optional Curly Braces in JavaScript
>
> Ok, no problem. I know the committee doesn't add features easily, but
> starting a discussion is a good first step.
> --
> *From:* es-discuss  on behalf of Bergi <
> a.d.be...@web.de>
> *Sent:* Sunday, November 3, 2019 4:05:36 PM
> *To:* es-discuss@mozilla.org 
> *Subject:* Re: Optional Curly Braces in JavaScript
>
> Hi!
>
> > If it's possible in JavaScript to have `:`, and enable significant
> spacing, that would be great.
> >
> > Why you don't *want* to?
>
> Your argument for significant whitespace seems to be that the simplicity
> of Python is great. However, adding an alternative block syntax to
> JavaScript would fail to achieve this goal, in contrast, it would only
> make the language more complex.
>
> So no, my educated guess is that it's not possible for you to persuade
> the wider community and especially the technical committee to accept
> your proposal. They are very reluctant to add features that don't show a
> clear benefit.
>
> Since you asked for my personal feedback: JS syntax was influenced by C
> and Java, and it will consistently keep its curly braces. A different
> block style would only be a viable choice for a new language or dialect,
> which should not allow curly braces at all, and would not provide
> backwards compatibility.
>
> kind regards,
>  Bergi
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Use hashes as keys instead of toString() for values like object, function to index objects

[J Decker]

On Sun, Sep 8, 2019 at 1:24 PM Michael Luder-Rosefield <
rosyatran...@gmail.com> wrote:

> I'd suggest that the best way of doing this, without breaking existing
> code, is to put some sugar around Maps so that they can be used in a more
> Object-y way. For starters, Map literal declarations and assignment could
> benefit from this.
>
> or Just use a WeakMap


> Suggestions for syntax welcome!
>
> On Sun, 8 Sep 2019, 12:36 Tadas Lapė,  wrote:
>
>> The problem
>>
>> Javascript allows to index objects not only with strings, numbers, but
>> also with objects. It uses toString() object method to calculate the object
>> index. If method is not overwritten, the generated index is "[object
>> Object]". Many users do not know this or forget this and cause different
>> objects going into same index when using more of them.
>>
>> The solution
>>
>> Instead of using the default value "[object Object]" for objects, use
>> their hash codes. You can also prepend them with "function:" or "object:"
>> to let the user know index origin when iterating over object keys. And if
>> person has overwritten the behavior of toString() object method, use it's
>> returned value as index (to consider). This should be less error-prone.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Add new 'Matrix' object

[J Decker]

On Sun, May 12, 2019 at 2:51 AM Ed Saleh  wrote:

> Hello,
>
> Matrices are widely used today in in Computer Science, Engineering, and
> AI. I am proposing a new object type of `Matrix([ []... ])` which would
> make working with matrices easier, easily doing operations such matrices
> `multiplication` and `addition`.
>
> There is a pretty good library for that...
https://js.tensorflow.org/api/latest/#Operations-Arithmetic
:)
they call them 'tensors' though.


> Thank you,
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring for Array-like objects

[J Decker]

On Fri, Mar 22, 2019 at 10:32 AM guest271314  wrote:

>
> If gather the expected result correctly object destructuring can be used
>
> const {0: a, 1: b} = {0: a, 1: b, length: 2}
>

var a = "testa", b="testb"; const {0: c, 1: d} = {0: a, 1: b, length: 2}
results in a const 'c' and const 'd' created with the vlaues of a and b.

shouldn't it have created a variable '0' and '1' ?

>
> On Wed, Mar 20, 2019 at 12:59 AM Sultan  wrote:
>
>> Afford array destructuring to Array-like objects.
>>
>> const [a, b] = {0: a, 1: b, length: 2}
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)

[J Decker]

The original code posted is not debugged.

input: 100.00015,
array: [ 1, 0, 0, 0.0001, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 9, 7, 9, 5
],
araytoNum   100.0501000497,

So given that you can't convert to and from a number, I'm sure everyone is
having a problem knowing how this conversion would work for useful work.
{ tests:
   [ 0,
 200,
 100.00015,
 -123,
 4.4,
 44.44,
 -0.01,
 123,
 2.718281828459,
 321.71,
 809.56,
 1.61803398874989,
 1.999,
 100.01,
 545454.45,
 -7,
 -83.782,
 12,
 1.5,
 100.0001 ],
  arrays:
   [ [ 0 ],
 [ 2, 0, 0 ],
 [ 1, 0, 0, 0.0001, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 9, 7, 9, 5 ],
 [ -1, -2, -3 ],
 [ 4, 0.4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4 ],
 [ 4, 4, 0.4, 3, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 7, 6 ],
 [ -0.01 ],
 [ 1, 2, 3 ],
 [ 2, 0.7001, 1, 8, 2, 8, 1, 8, 2, 8, 4, 5, 8, 9, 9, 9, 8 ],
 [ 3, 2, 1, 0.7001, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9, 9, 9, 7,
6, 1 ],
 [ 8, 0, 9, 0.5, 5, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 4, 5, 4 ],
 [ 1, 0.6001, 1, 8, 0, 3, 3, 9, 8, 8, 7, 4, 9, 8, 9, 0, 1 ],
 [ 1, 0.9, 9, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2 ],
 [ 1, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 1, 1, 2 ],
 [ 5, 4, 5, 4, 5, 4, 0.4, 4, 9, 9, 9, 9, 9, 9, 9, 9, 5, 3, 4, 3, 3, 9 ],
 [ -7 ],
 [ -8,
   -3,
   -6.999e-16,
   -8,
   -1,
   -9,
   -9,
   -9,
   -9,
   -9,
   -9,
   -9,
   -9,
   -9,
   -9,
   -9,
   -6,
   -2 ],
 [ 1, 2 ],
 [ 1, 0.5 ],
 [ 1, 0, 0, 0.0001, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 3, 1, 9, 6, 4 ] ],
  numbers:
   [ 0,
 200,
 100.0501000497,
 -123,
 4.4,
 44.44,
 -0.01,
 123,
 2.718281828459,
 321.71,
 809.56,
 1.6180339887498902,
 1.999,
 100.010005,
 545454.45,
 -7,
 -83.082,
 12,
 1.5,
 100.0001000331 ] }


On Mon, Mar 11, 2019 at 11:13 PM guest271314  wrote:

> With respect, it's still not clear how you want to interact with the array
>> of values once you've destructured a Float into your array format.
>
> If all you have is an array of single-digit numbers that represent the
>> values in the tenths/hundredths/etc. positions of the source number, how
>> does this actually circumvent the challenges of representing Decimal values
>> that aren't exactly representable as a Float?
>
>
> It is not clear how your examples of adding specific values in JavaScript
> are relevant to the proposal.
>
> All of the test cases used at the code which fixed the bugs in the proof
> of concept at the original post output the expected result.
>
> If you have more test cases, number or decimal, to suggest for input
> relevant to the code at the original proposal, number to array, array to
> number, kindly post those tests cases listing input and expected output.
>
> The proposal does not seek to solve all JavaScript number issues.
>
> The proposal seeks to standardize the naming conventions of number to
> array and array to number, including decimals. An array is the simplest
> form of structured output. An object of key, value pairs (similar to
> Intl.NumberFormat, with JavaScript numbers instead of strings) can also be
> utilized for each of the digits of integer and decimal (fraction), if any.
>
>
>
> On Mon, Mar 11, 2019 at 4:33 PM Jeremy Martin  wrote:
>
>> With respect, it's still not clear how you want to interact with the
>> array of values once you've destructured a Float into your array format.
>>
>> If all you have is an array of single-digit numbers that represent the
>> values in the tenths/hundredths/etc. positions of the source number, how
>> does this actually circumvent the challenges of representing Decimal values
>> that aren't exactly representable as a Float?
>>
>> To illustrate this challenge, let's use the classic example we've all
>> seen hundreds of times:
>>
>> > .1 + .2
>> 0.30004
>>
>> For a long time, all the reading I would do about *why* this produced a
>> weird result would *sort* of make sense and *sort* of confuse me. That
>> is, I could understand *why* 3/10ths isn't representable as a Float, but
>> then I would get confused by the fact that I could type `.3` into a REPL,
>> and it would *actually work *(??!):
>>
>> > .3
>> 0.3
>>
>> I mean, who's lying? How come `.3` works fine when I just type it
>> straight in, and `.1 + .3` works just fine, but there's just these
>> specific cases like `.1 + .2` where all of a sudden `.3` decides not to
>> be representable again?
>>
>> I admit this is conjecture, but maybe that's part of the confusion
>> motivating this proposal? And maybe the idea is that if we can break `.1`
>> and `.2` into some sort of an array structure (e.g., [0, 1] and [0, 2]), then
>> we can add the individual parts as integers (giving us something 

Re: Proposal: switch statement multiple

[J Decker]

On Fri, Feb 15, 2019 at 8:02 PM Juan Pablo Garcia 
wrote:

> I think it would be great if the switch statement allows multiple argument
>
> Example
> Switch(a,b)
> Case: 1,true
> Case: 1,false
> Case: 2,true
> 
>
>
> Switch (true, true)
> Case: isPremium,  true
> Case: isBasic, hasCredit
> Case: isBasic, !hasCredit
>
>
>
Can't you just 'do that' ?

var isPremium = false;
var isBasic = !isPremium;
var hasCredit = true;

switch( true  ) {
   case isPremium:
  console.log( "one" );
  break;
   case isBasic && hasCredit:
  console.log( "two" );
  break;
   case  isBasic && !hasCredit  :
  console.log( "three" );
  break;
   default:
  console.log( "default" );
  break;
}



var o = {a:true, b:true}

switch( true  ) {
   case o.a == true && o.b == true :
  console.log( "one" );
  break;
   case o.a == false &&  o.b == true :
  console.log( "two" );
  break;
   case o.a == true &&  o.b == false :
  console.log( "three" );
  break;
   default:
  console.log( "default" );
  break;
}



> Maybe case: default, true
>
> Look forward to read yours views.
>
>
>
> I used to code in cobol and was very useful the sintax
> COBOL example:
> Evaluate a also b
> When 1 also true
> When any also false
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: add stage4 constraint - ease-of-minification

[J Decker]

On Tue, Feb 12, 2019 at 7:07 PM kai zhu  wrote:

> npm google-closure-compiler handles transpilation and minifiction.
> and it's just 2 deps, itself, and Java.
> https://www.npmjs.com/package/google-closure-compiler
>
>
> hmm, google-closure-compiler actually has 29 dependencies (57mb total)
>

I see.
I just have a copy of  npm\node_modules\google-closure-compiler/compiler.jar
didn't realize it had other deps   "dependencies": {"chalk": "^1.0.0",
   "vinyl": "^2.0.1", "vinyl-sourcemaps-apply": "^0.2.0"  },

Which are used for grunt and gulp plugins, which I don't use.



>
>
> $ shNpmPackageDependencyTreeCreate google-closure-compiler
>
> + google-closure-compiler@20190121.0.0
> added 29 packages from 72 contributors and audited 34 packages in 2.04s
> found 0 vulnerabilities
>
> [MODE_BUILD=npmPackageDependencyTree] - 2019-02-13T02:53:32.614Z - (shRun
> npm ls 2>&1)
>
> /private/tmp/npmPackageDependencyTreeCreate
> └─┬ google-closure-compiler@20190121.0.0
>   ├─┬ chalk@1.1.3
>   │ ├── ansi-styles@2.2.1
>   │ ├── escape-string-regexp@1.0.5
>   │ ├─┬ has-ansi@2.0.0
>   │ │ └── ansi-regex@2.1.1
>   │ ├─┬ strip-ansi@3.0.1
>   │ │ └── ansi-regex@2.1.1 deduped
>   │ └── supports-color@2.0.0
>   ├── google-closure-compiler-java@20190121.0.0
>   ├── google-closure-compiler-js@20190121.0.0
>   ├── UNMET OPTIONAL DEPENDENCY google-closure-compiler-linux@20190121.0.0
>   ├── google-closure-compiler-osx@20190121.0.0
>   ├── minimist@1.2.0
>   ├─┬ vinyl@2.2.0
>   │ ├── clone@2.1.2
>   │ ├── clone-buffer@1.0.0
>   │ ├── clone-stats@1.0.0
>   │ ├─┬ cloneable-readable@1.1.2
>   │ │ ├── inherits@2.0.3
>   │ │ ├── process-nextick-args@2.0.0
>   │ │ └─┬ readable-stream@2.3.6
>   │ │   ├── core-util-is@1.0.2
>   │ │   ├── inherits@2.0.3 deduped
>   │ │   ├── isarray@1.0.0
>   │ │   ├── process-nextick-args@2.0.0 deduped
>   │ │   ├── safe-buffer@5.1.2
>   │ │   ├─┬ string_decoder@1.1.1
>   │ │   │ └── safe-buffer@5.1.2 deduped
>   │ │   └── util-deprecate@1.0.2
>   │ ├── remove-trailing-separator@1.1.0
>   │ └── replace-ext@1.0.0
>   └─┬ vinyl-sourcemaps-apply@0.2.1
> └── source-map@0.5.7
>
> $ du -ms .
> 57 .
>
>
>
>
> terser is relatively smaller with 5 dependencies (6mb total).  i might
> look into forking it and merge its dependencies into a standalone-package
>
>
> $ shNpmPackageDependencyTreeCreate terser
>
> + terser@3.16.1
> added 5 packages from 38 contributors and audited 6 packages in 1.742s
> found 0 vulnerabilities
>
> [MODE_BUILD=npmPackageDependencyTree] - 2019-02-13T02:54:10.589Z - (shRun
> npm ls 2>&1)
>
> /private/tmp/npmPackageDependencyTreeCreate
> └─┬ terser@3.16.1
>   ├── commander@2.17.1
>   ├── source-map@0.6.1
>   └─┬ source-map-support@0.5.10
> ├── buffer-from@1.1.1
> └── source-map@0.6.1 deduped
>
> $ du -ms .
> 6 .
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: add stage4 constraint - ease-of-minification

[J Decker]

I suppose your argument isn't about 'not want to rely on babel' but 'not
want to rely on anything'?

I don't really understand where you're coming from it's like I missed the
first half of the thread...

I mean, I abhor babel; it has such huge dependancies.
npm google-closure-compiler handles transpilation and minifiction.
and it's just 2 deps, itself, and Java.
https://www.npmjs.com/package/google-closure-compiler

It also does source amalgamation without transpiling; and seems to be kept
up to date

On Tue, Feb 12, 2019 at 5:09 PM kai zhu  wrote:

> sorry that came out wrong, but i'm generally uncomfortable with the dearth
> of reliable/correct es6+ compliant minifiers.  and i feel its an
> industry-concern which slows product-development.
>
> On Tue, Feb 12, 2019 at 6:35 PM kai zhu  wrote:
>
>> Yes, exactly. minification-tooling is a real-concern for any
>> consumer-facing javascript-product, and not all of them want to rely on
>> babel.
>>
>> Are you arguing all new javascript-products should be coerced to
>> integrate with babel, because it has a monopoly on such critical-tooling?
>>
>> On Tue, Feb 12, 2019 at 6:28 PM Jordan Harband  wrote:
>>
>>> So effectively, you're arguing that stagnant tools should hold back
>>> evolution of the language, even when non-stagnant alternatives exist?
>>>
>>> On Tue, Feb 12, 2019 at 3:26 PM kai zhu  wrote:
>>>
 > Can you expand on what you mean by this, or provide an example of a
 > feature that can't be "easily minified”?

 fat-arrow/destructuring/es6-classes comes to mind.  if you have legacy
 build-chain that doesn't use babel or terser, is it worth the effort to
 retool the minifier to support these syntaxes so you can use it?  also any
 feature which introduce new symbol/symbol-combo which requires re-auditing
 minifier's regexp-detection (private-fields, optional-chaining, etc.).

 there’s also the argument using babel in minification-toolchain defeats
 the purpose of reducing code-size.

 > On 12 Feb 2019, at 4:02 PM, Tab Atkins Jr. 
 wrote:
 >
 > On Tue, Feb 12, 2019 at 7:44 AM kai zhu  wrote:
 >> i think there’s an industry-painpoint (at least from my experience),
 of resistance adopting es6+ features because legacy-toolchains cannot be
 easily retooled to minify them.
 >>
 >> i’m not sure the best way to address this problem? i favor requiring
 2 independent minifiers to be able to handle a stage3-proposal before
 advancement (indicating retooling is feasible), but that may be
 overly-restrictive to some folks.
 >
 > Can you expand on what you mean by this, or provide an example of a
 > feature that can't be "easily minified"?
 >
 > ~TJ

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

>>> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Default object method

[J Decker]

On Sun, Jan 27, 2019 at 10:46 PM Ranando King  wrote:

> Jordan's right. This one is best handled by a function. But if there is
> some reason you need to create callable objects, it's still doable, even
> with ES as-is. Just extend your classes from something like this:
>
> ```js
> class Callable {
>constructor(defaultFn) {
>   return (...args) => { return defaultFn.call(this, ...args); };
>}
> }
> ```
> Any class extending this will have instances that are functions. So using
> your UserCreator class...
>
> ```js
> class UserCreator extends Callable {
>   constructor(repository) {
> super(this.create);
> this.repository = repository;
>   }
>
>   create(name) {
>  return this.repository.createUser(name);
>   }
> }
> ```
>

Can't you just use a function object?

function UserCreator(repository) {
 if( !(this instanceof UserCreator ) ) return new
UserCreator(repostiory);
var creator = function xyz(name) {
 return { repo: repository, user: name }
}:
creator.repository = repository;
creator.create = creator
return   creator;
}


>
> Now `new UserCreator(someRepo)(someName)` is the same as `new
> UserCreator(someRepo).create(someName)`.
>

both of the above also work that way.


>
> On Sun, Jan 27, 2019 at 11:35 PM Jordan Harband  wrote:
>
>> Something that can be invoked has a `[[Call]]` slot, and is `typeof`
>> "function".
>>
>> Adding a Symbol that makes something callable would have a number of
>> effects - it would make `typeof` (one of the most robust operations in the
>> language) unsafe, because it would have to access the Symbol method, which
>> could be a throwing getter (or even one that just logs how many typeofs are
>> called on it). Additionally, it would mean any object could become
>> callable, and any function could be made *un* callable.
>>
>> This seems like a pretty large change, solely to avoid "classes with a
>> single method", which arguably should just be a function in the first place.
>>
>> On Sun, Jan 27, 2019 at 4:05 PM Brasten Sager  wrote:
>>
>>> Apologies if this has been raised before. I was unable to locate
>>> anything similar.
>>>
>>> Any thoughts or ideas on this proposal would be appreciated!
>>>
>>> Original:
>>> https://gist.github.com/brasten/f87b9bb470973dd5ee9de0760f1c81c7
>>>
>>> -Brasten
>>>
>>> —
>>>
>>> # Proposal: Default object method #
>>>
>>> Objects w/ default method can be invoked like a function.
>>>
>>> ## Problem ##
>>>
>>> Objects that are well constrained (single responsibility)
>>> can tend to end up with a single method, or at least a single method
>>> that is important to most consumers. These methods tend to be named
>>> by either verbing the class name (eg. `UserCreator.create()`) or with
>>> some generic `handle` / `perform` / `doTheObviousThing`.
>>>
>>> Whatever the name, downstream consumers of the object end up coupled to
>>> two implementation details:
>>>
>>>1) this thing-doer is an object and not a function
>>>2) this thing-doer's doing method is called `X`
>>>
>>> ### Example ###
>>>
>>> Here we are going to create an object that can be used to
>>> create a user later. Note that downstream consumers will only
>>> care that this object does one thing: create a user. While it
>>> make have other methods eventually for use in some limited
>>> contexts, creating a user is its primary (and often sole-)
>>> responsibility.
>>>
>>> ```js
>>> class UserCreator {
>>>   constructor(repository) {
>>> this.repository = repository;
>>>   }
>>>
>>>   create(name) {
>>>  return this.repository.createUser(name);
>>>   }
>>> }
>>>
>>> const userCreator = new UserCreator(userRepository);
>>> ```
>>>
>>> At this point, the `userCreator` is just a single-method object.
>>> It is useful for injecting into other objects that may need to
>>> create a user. But the fact that the `userCreator` is an object
>>> with a single useful method is an implementation detail to which
>>> consumers become coupled.
>>>
>>> ```js
>>>
>>> // Consumer of `userCreator`. Although this could itself be a
>>> // good example of a "UserCreator"-like object (due to `.handle()`).
>>> //
>>> class UserSignupHandler {
>>>   constructor(userCreator) {
>>> this.userCreator = userCreator;
>>>   }
>>>
>>>   handle(userName) {
>>> // UserSignupHandler is aware of ".create" when it really doesn't
>>> have to be.
>>> //
>>> return this.userCreator.create(userName);
>>>   }
>>> }
>>>
>>> const handler = new UserSignupHandler(userCreator);
>>> ```
>>>
>>> Notably, if we were to change the implementation of UserCreator later to
>>> be
>>> a pure function, we would have to change all consumers of UserCreator
>>> when
>>> conceptually it shouldn't be needed. There is still a thing-doer that has
>>> the same input/output.
>>>
>>>
>>> ## Proposed Solution ##
>>>
>>> An object instance can have a default method. This would allow an
>>> object to be "invoked" exactly like a function, hiding the implementation
>>> 

Re: Proposal: Symbol Linked to `typeof`

[J Decker]

On Sat, Jan 12, 2019 at 8:19 AM Randy Buchholz 
wrote:

> (Hi all, new to group)
>
>
>
> Some of the Well Known Symbols are linked to standard functions –
>  Symbol.toStringTag - A string value used for the default description of an
> object. Used by Object.prototype.toString().
>
>
>
> When I have a Class instance (say, `const flow = new Flow()`, the
> debugger shows `flow = Flow {`.
>
> But when I do `console.log( typeof flow)` the output is `object`.
>
>
>
> I assume changing basic behavior `typeof` would be breaking, but extending
> it through a symbol would be useful.
>
>
>
> `Symbol.typeofTag` of just `Symbol.typeof`
>
>
>
> Invoking `typeof` on an object with this symbol would return “user-typed”
> information.
>
>
>

can't you just use the constructor name when needing more detail?

var a = new Date();
a.constructor.name
"Date"



> (Posting Question)
>
> What is the preferred format/approach for highlighting code in posts?
>
> 
>
> Possible Approaches
>
> ```
>
> class Flow {
>
> get [Symbol.typeof]() { return Flow; }  or { return “Flow” }
>
> }
>
> ```
>
> would work much like Symbol.species.  Implicitly casting to string would
> be more intuitive I think.
>
>
>
> Other approaches, (special handling of well-knowns) could be:
>
>
>
> Decorator-ish
>
> ```
>
> [Symbol.typeof] = “Flow”
>
> Class Flow {…
>
> ```
>
> or inferred
>
>
>
> ```
>
> [Symbol.typeof]
>
> class Flow {…
>
> ```
>
>
>
> Internal – In class, but not in a function.
>
>
>
> ```
>
> Class Flow {
>
> [Symbol.typeof]
>
> or
>
> [Symbol.typeof] = “Flow”
>
> or
>
> [Symbol.typeof] = Flow
>
> or
>
> [Symbol.typeof] = this
>
>
>
> ```
>
>
>
> Constructor
>
> ```
>
> Class Flow {
>
>Constructor() {
>
>   this[Symbol.typeof] = …
>
>   …
>
> ```
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Arrow methods

[J Decker]

On Fri, Nov 16, 2018 at 11:23 AM Sultan  wrote:

> As the name suggests; An update to the grammar related to methods on
> objects/classes to support arrow methods:
>
> today: {render() { return 'Hello' }}
> proposed addition: {render() => 'Hello'}
>
> proposed addition: {render:() => 'Hello'}


> This could be some-what linked to class fields in the class variant; That
> is what does "this" refer to when used in a class.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Expectations around line ending behavior for U+2028 and U+2029

[J Decker]

On Mon, Oct 29, 2018 at 1:50 PM Carsten Bormann  wrote:

> On Oct 26, 2018, at 10:48, Claude Pache  wrote:
> >
> > I have just tried to open a file containing U+2028 and U+2029 in four
> different text editors / integrated environments on my Mac. All of them
> recognise both characters as newlines (and increment the line number for
> those that display it).
>
> Hi Claude,
>
> can you identify those apps?  I’d like to meet them in person.
>

https://esdiscuss.org/topic/expectations-around-line-ending-behavior-for-u-2028-and-u-2029#content-10
The screen shot didn't save in that archive though...

It looks to me like 2028 isn't a real line break; just a visual line
break... since it kept the same line number.  Not sure what to do about a
'column' count in this case though... character index on line != column in
this case...

2029 does look like '\r\n' (if \r is return and \n is linefeed as in
classic TTY)


>
> Grüße, Carsten
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Dates with Timezones and ISO8601 Date Constants.

[J Decker]

That's a little like using a sledge hammer to cut cake.

Adding Dates as a type of data in JSOX, the additional rule to handle dates
in the parser is pretty simple.
https://raw.githubusercontent.com/d3x0r/JSOX/master/NumberRule.GIF

I'm also not sure it's really needed to know if it was ' MST or PDT ' at
that time. With whatever the current offset was at that time, that's the
time it was for them (or the time they claim is for them), and the time it
was relative to everyone else.

On Mon, Sep 24, 2018 at 6:10 PM Jordan Harband  wrote:

> Are you familiar with the Temporal proposal?
> https://github.com/tc39/proposal-temporal
>
> On Mon, Sep 24, 2018 at 8:32 PM, J Decker  wrote:
>
>> I did look back to see other conversations about Dates
>>
>> Operating with arbitrary timezones
>> https://mail.mozilla.org/pipermail/es-discuss/2016-August/046478.html
>>
>> Add timezone data to Date
>> https://mail.mozilla.org/pipermail/es-discuss/2017-June/048259.html
>>
>> Even until this moment, Edge/IE cannot parse new Date(
>> "2018-09-25T00:17:55.385-07:00").  which makes 50% of the world already
>> require a date/time library.
>> https://github.com/Microsoft/ChakraCore/issues/5502
>> (actually Aug 16 that was closed)
>>
>> Date.toISOString() only emits 'Z', even though the type itself has the
>> offset
>>
>> as a Date.prototype.toISOLocalString()
>> cb : function () {
>> var tzo = -this.getTimezoneOffset(),
>> dif = tzo >= 0 ? '+' : '-',
>> pad = function(num) {
>> var norm = Math.floor(Math.abs(num));
>> return (norm < 10 ? '0' : '') + norm;
>> };
>> return this.getFullYear() +
>> '-' + pad(this.getMonth() + 1) +
>> '-' + pad(this.getDate()) +
>> 'T' + pad(this.getHours()) +
>> ':' + pad(this.getMinutes()) +
>> ':' + pad(this.getSeconds()) +
>> dif + pad(tzo / 60) +
>> ':' + pad(tzo % 60);
>> }
>> --
>> But; that's only semi-accurate, because if I say -07:00 as the offset, I
>> don't know if it's MST or PDT (which is knowable I suppose).
>>
>> There's not a LOT of usage of times in code; but it could be that the
>> constant number 2018-09-25T00:26:00.741Z could just BE a Date, similar to
>> 123n just being a BigInt.
>>
>> It would also be handy if there were a builtin ISO w/ Timezone emitter.
>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Dates with Timezones and ISO8601 Date Constants.

[J Decker]

I did look back to see other conversations about Dates

Operating with arbitrary timezones
https://mail.mozilla.org/pipermail/es-discuss/2016-August/046478.html

Add timezone data to Date
https://mail.mozilla.org/pipermail/es-discuss/2017-June/048259.html

Even until this moment, Edge/IE cannot parse new Date(
"2018-09-25T00:17:55.385-07:00").  which makes 50% of the world already
require a date/time library.
https://github.com/Microsoft/ChakraCore/issues/5502
(actually Aug 16 that was closed)

Date.toISOString() only emits 'Z', even though the type itself has the
offset

as a Date.prototype.toISOLocalString()
cb : function () {
var tzo = -this.getTimezoneOffset(),
dif = tzo >= 0 ? '+' : '-',
pad = function(num) {
var norm = Math.floor(Math.abs(num));
return (norm < 10 ? '0' : '') + norm;
};
return this.getFullYear() +
'-' + pad(this.getMonth() + 1) +
'-' + pad(this.getDate()) +
'T' + pad(this.getHours()) +
':' + pad(this.getMinutes()) +
':' + pad(this.getSeconds()) +
dif + pad(tzo / 60) +
':' + pad(tzo % 60);
}
--
But; that's only semi-accurate, because if I say -07:00 as the offset, I
don't know if it's MST or PDT (which is knowable I suppose).

There's not a LOT of usage of times in code; but it could be that the
constant number 2018-09-25T00:26:00.741Z could just BE a Date, similar to
123n just being a BigInt.

It would also be handy if there were a builtin ISO w/ Timezone emitter.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ESM exporting getters and setters.

[J Decker]

On Fri, Sep 21, 2018 at 1:13 PM J Decker  wrote:

>
>
> On Thu, Sep 20, 2018 at 6:00 PM Jordan Harband  wrote:
>
>> The getter part is already how it works - you can `export let foo =
>> false;` and then later `foo = true`; and then `export function setFoo(v) {
>> foo = v; }`. Why is the getter/setter syntax a significant improvement over
>> this?
>>
>> On Thu, Sep 20, 2018 at 4:21 PM, Michael J. Ryan 
>> wrote:
>>
>
> If you removed just the export; it wouldn't be valid code
>
>
>> // myFoo.mjs
>>> _hiddenFoo = false;
>>> /*export*/ get foo() {
>>>   return _hiddenFoo;
>>> }
>>>
>>> /*export*/ set foo(value) {
>>>   _hiddenFoo = !!value;
>>> }
>>>
>>>
> /*export*/ get foo() {
>^^^
>
> SyntaxError: Unexpected identifier
>
> var hiddenFoo;
> var foo = {
>get foo() {
>   return _hiddenFoo;
> },
>
> set foo(value) {
>   _hiddenFoo = !!value;
> }
> }
> export {foo};
>
I missed the point a little... would be something like

const foofoo = foo.foo; // which doesn't result as a setter/getter
reference, but the value...
export {foofoo}




>
> // --- main
>  import {foo} from './zz.mjs';
>
> console.log( "what is foo?", foo );
>
> // -- output
>
> what is foo? { foo: [Getter/Setter] }
>
>
>
>
>> Not sure if this has been discussed, but would be a nice feature to have
>>> in some cases... I know, total side effects and mutations, all the same,
>>> would be a nice to have in a few cases.
>>>
>>> --
>>> Michael J. Ryan
>>> 480-270-4509
>>> https://www.tracker1.info/
>>> m...@tracker1.info
>>> track...@gmail.com
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ESM exporting getters and setters.

[J Decker]

On Thu, Sep 20, 2018 at 6:00 PM Jordan Harband  wrote:

> The getter part is already how it works - you can `export let foo =
> false;` and then later `foo = true`; and then `export function setFoo(v) {
> foo = v; }`. Why is the getter/setter syntax a significant improvement over
> this?
>
> On Thu, Sep 20, 2018 at 4:21 PM, Michael J. Ryan 
> wrote:
>

If you removed just the export; it wouldn't be valid code


> // myFoo.mjs
>> _hiddenFoo = false;
>> /*export*/ get foo() {
>>   return _hiddenFoo;
>> }
>>
>> /*export*/ set foo(value) {
>>   _hiddenFoo = !!value;
>> }
>>
>>
/*export*/ get foo() {
   ^^^

SyntaxError: Unexpected identifier

var hiddenFoo;
var foo = {
   get foo() {
  return _hiddenFoo;
},

set foo(value) {
  _hiddenFoo = !!value;
}
}
export {foo};

// --- main
 import {foo} from './zz.mjs';

console.log( "what is foo?", foo );

// -- output

what is foo? { foo: [Getter/Setter] }




> Not sure if this has been discussed, but would be a nice feature to have
>> in some cases... I know, total side effects and mutations, all the same,
>> would be a nice to have in a few cases.
>>
>> --
>> Michael J. Ryan
>> 480-270-4509
>> https://www.tracker1.info/
>> m...@tracker1.info
>> track...@gmail.com
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Submitted for your approval, JSOX

[J Decker]

On Wed, Sep 19, 2018 at 1:46 PM Mike Samuel  wrote:

>
>
> On Wed, Sep 19, 2018, 4:41 PM Mike Samuel  wrote:
>
>>
>>
>> On Wed, Sep 19, 2018, 4:07 PM J Decker  wrote:
>>
>>> (trimmed)
>>>
>>> On Wed, Sep 19, 2018 at 12:08 PM Mike Samuel 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Sep 19, 2018 at 12:01 PM J Decker  wrote:
>>>>
>>>>>
>>>>> I know of no exploits; all resulting strings should be shorter than
>>>>> the input (because of escapes \\ ).  The C version allocates a output
>>>>> buffer that is the same size as the input, and moves decoded strings into
>>>>> it.  Structure characters [ { } ] , " ' `  don't transfer either.
>>>>>
>>>>
>>>> Not a vulnerability in your JSOX implementation per se, but have you
>>>> looked into whether there's exploitable ambiguity between JSOX and runs of
>>>> ES BlockStatements and ExpressionStatements?
>>>>
>>>> JSON used to be vulnerable
>>>> <https://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/>
>>>> to cross-site snooping.
>>>>
>>>> // In attacker page
>>>> Array = function () { alert('Got ' + arguments[0]) };
>>>> 
>>>> http://other-origin/some-web-service-that-responds-with-a-json-array</a>
>>>> ">
>>>>
>>>
>>> Interesting; that applies to JSOX for Number, BigInt, Date, 
>>>
>>> Parenthesis (in the C version) fault while collecting an identifier as
>>> being a non-identifier character as defined by Unicode Standards  (as
>>> per rules of an identifier in ES6)
>>> That lookup was omitted in the JS implementation.  (per character search
>>> through several thousand values.)
>>>
>>> Parenthesis is reserved for code, expressions, parameter specifications,
>>> and is (should be) forbidden except in strings.
>>>
>>
>> My apologies.  I thought there were parentheses in the docs on npmjs but
>> seeing what I pasted from there on my phone it's obvious that it's all
>> curly brackets.
>>
>> As long as your syntax doesn't include parentheses, dots, or backticks
>> you're probably fine.
>>
>
> Though I could probably make hay with an output that includes thee token
> pair  ] [
>

That could occur in a stream.  (Although if it's a stream I would expect it
to come in on a websocket rather than any sort of request) But

   someText{a,b,c}[1,2,3][1,2,3]

[1][2]

Those are valid streams of objects... How would  '][' be used?

I converted the non-identifier character test to a bit lookup and applied
it in the JS parser. ( fixed like =,+,-,!,~,(,),<,>,... in unquoted
contexts) but speaking of quotes a variant allowed is back-tick quoting...
` ` ; without the template/code aspects that implies with ES6.  what about
content that's like

{ asdf : "hello
world" }
(\n literal is allowed to be collected, and/or \r) but JS would fault on
multiline non-escaped-continuation...

But I've been reflecting on something you said 'custom types'.
I'm thinking of implementing basically typed-strings.   " ...
"  (or like "abc""reconstructiondata" ); and registering fromJSOX handlers
on the parser.  Which would be like parser.registerFromJSOX( "someType",
function (string) { /* use string to create a thing */ } ).
Types like 'color' might want to just emit as '#RRGGBBAA' with a toJSOX...
but really be separate color channels internally.


>
>
>>
>>>
>>>>
>>>> This allowed piggybacking on HTTP credentials if an attacker could get
>>>> a victim to visit their page.
>>>>
>>>> The problem was that the meaning of [...] and {...} were specified in
>>>> terms of global.Array and global.Object
>>>> which could be replaced
>>>>
>>>> That's been fixed, but JSOX should probably be careful about any
>>>> ambiguity with BlockStatement.
>>>> IIUC,
>>>>   { keyword: [] }
>>>> is valid as a statement so there is some ambiguity there.
>>>>
>>>> Then I see examples like
>>>>
>>>> //-- the following...
>>>> a { firstField, secondField }
>>>> [ a { 1, 2 }, a{5,6}, a{"val1","val2"} ]
>>>>
>>>> Ya, it's tempting to type parenthesis after an identifer (fixed above)
>>>
>>> [ {firstField:1, secondField:2 }, {firstField:5,secondFie

Re: Submitted for your approval, JSOX

[J Decker]

(trimmed)

On Wed, Sep 19, 2018 at 12:08 PM Mike Samuel  wrote:

>
>
> On Wed, Sep 19, 2018 at 12:01 PM J Decker  wrote:
>
>>
>> I know of no exploits; all resulting strings should be shorter than the
>> input (because of escapes \\ ).  The C version allocates a output buffer
>> that is the same size as the input, and moves decoded strings into it.
>> Structure characters [ { } ] , " ' `  don't transfer either.
>>
>
> Not a vulnerability in your JSOX implementation per se, but have you
> looked into whether there's exploitable ambiguity between JSOX and runs of
> ES BlockStatements and ExpressionStatements?
>
> JSON used to be vulnerable
> <https://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/>
> to cross-site snooping.
>
> // In attacker page
> Array = function () { alert('Got ' + arguments[0]) };
> 
> http://other-origin/some-web-service-that-responds-with-a-json-array</a>
> ">
>

Interesting; that applies to JSOX for Number, BigInt, Date, 

Parenthesis (in the C version) fault while collecting an identifier as
being a non-identifier character as defined by Unicode Standards  (as
per rules of an identifier in ES6)
That lookup was omitted in the JS implementation.  (per character search
through several thousand values.)

Parenthesis is reserved for code, expressions, parameter specifications,
and is (should be) forbidden except in strings.


>
> This allowed piggybacking on HTTP credentials if an attacker could get a
> victim to visit their page.
>
> The problem was that the meaning of [...] and {...} were specified in
> terms of global.Array and global.Object
> which could be replaced
>
> That's been fixed, but JSOX should probably be careful about any ambiguity
> with BlockStatement.
> IIUC,
>   { keyword: [] }
> is valid as a statement so there is some ambiguity there.
>
> Then I see examples like
>
> //-- the following...
> a { firstField, secondField }
> [ a { 1, 2 }, a{5,6}, a{"val1","val2"} ]
>
> Ya, it's tempting to type parenthesis after an identifer (fixed above)

[ {firstField:1, secondField:2 }, {firstField:5,secondField:6},
{firstField:"val1",secondField:"val2"} ]

But that doesn't really generate any more data; (similar strings get
collapsed?)... and  on parsing, there's only one reference to 'firstField'
and 'secondField'... I was trying to ponder scenarios where the data grows
unbounded... but even in a case where there's a reference like

[ {a:1, b:2 }, [ref[0],ref[0]], [ref[1],ref[1]], [ref[2],ref[2]] ]

[ {a:1,b:2}, [ {a:1, b:2}, {a:1,b:2} ], [ [{a:1, b:2},
{a:1,b:2}],[{a:1, b:2}, {a:1,b:2}] ], [ [ [{a:1, b:2},
{a:1,b:2}],[{a:1, b:2}, {a:1,b:2}] ], [ [{a:1, b:2}, {a:1,b:2}],[{a:1,
b:2}, {a:1,b:2}] ] ] ]

But it's not really replicated data, in the meta data between parsing and
object assembly, it's an array of strings/numbers; and resolves to pointers
to existing data.


I haven't worked through your grammar, but I wonder whether a naive JSOX
> encoder might produce output like
> { looksLikeAStatementLabel: a{"val1", "val2"} }
>

(yes, but not parentheses.  Because parens are not control characters, the
end up being gatherable into identifiers)

or
> a
> { onlyField }
>

The current parsing will drop 'onlyField' and result with {}.
It only 'pushes' the value into the container if there is a value.

It was previously is a parsing error, no value for field... 'expected ':'
and a value' sort of thing; But I ran into '{}' which is a similar parsing
state...



> [ a(5), a("val1") ]
> allowing an attacker to do
> 
> let onlyField = null;
> function a(...data) {
>   alert(`Got ${ data }`);
> }
> 
> http://other-origin/jsox-web-service&quot</a>;>
>
> There's a lot of "ifs" in this scenario,
> AND CORS solves a lot of these problems for origins that use it
> AND browsers are less trusting of script srcs with
> Content-types:text/x-jsox than they were in 2008
> BUT
> // attacker setup
> let onlyField = null;
> function a(...data) {
>   alert(`Got ${ data }`);
> }
> // victim responds
> a
> { onlyField }
> [ a(5), a("val1") ]
> does alert twice in Chrome and JSON hijacking was exploited in the wild,
> serializers have been known to
> line wrap in attacker-controllable ways, and there may still be many JSON
> webservices that respect ambient
> credentials on cross-origin requests.
>

In the first case a(5) turns out to be a valid identifier, which is also
sort of a string, and the second one would fault finding a " in the middle
of a identifier... string-string is never allowed... "

Re: Submitted for your approval, JSOX

[J Decker]

Again I think it's a matter of introduction; I am just fishing for
knowledge from the more knowledgable; maybe what other JS types are
important.
I did include a discussion link https://gitter.im/sack-vfs/jsox .

On Wed, Sep 19, 2018 at 8:14 AM Mike Samuel  wrote:

> TC39 is not really a place to spec out new transport formats.
>
> You proposed builtin support for JSON5 <https://esdiscuss.org/topic/json5>
> last year.
> JSON5 was speced and had some adoption but that was controversial because
> JSON5 was not nearly as widely used as JSON.
> This seems to offer more obvious benefits over JSON than JSON5, but it
> doesn't yet approach the adoption threshold.
>

Yes, but JSON5 also won't handle bigint (other than as a string). (pure
speculation).
I'm not really proposing JSOX into the standard, but it is highly dependent
on the standard (and yes, the subject doesn't say that at all)


>
> -
>
> IIUC, type tags can only reference builtin types with well-understood
> semantics like Date and typed arrays or structs with default values defined
> in the same JSON input.
> No type referenced by JSON can be or extend a type defined by application
> code.
>

(I am assuming you mean JSOX?) Yes types specified, (without the
application registering information about that type) are not really 'types'
they work more like macros.
And there are lots of ways to instantiate types; for which, just sharing
the same prototype isn't enough; a use case for that would be a 3D model
which has lots of 'vector' and some 'matrix'es (and have bone structures
which may be cyclic).
that interface probably needs work;

>
> If that's not the case, please keep in mind though that deserialization
> schemes that allow an external input to specify which types to construct
> makes it easy for an attacker to forge objects that code might treat as
> privileged because it assumes all instances are created internally.
> https://www.owasp.org/index.php/Deserialization_of_untrusted_data
> "Malformed data or unexpected data could be used to abuse application
> logic, deny service, or execute arbitrary code, when deserialized."
> See also "History of Java deserialization vulnerabilities" at
> https://www.slideshare.net/codewhitesec/java-deserialization-vulnerabilitesruhrseceditionv10
>

Prototype binding is entirely controlled by the application; if registers
objects of a certain type should use a certain prototype(or other
construction method?), they will be that type alone, and not some arbitrary
type... if some new macro was used the object will just get a blank
prototype; which would be shared by others of that 'type'.

And yes, the security note from JSON re eval() does still apply for a
subset of valid input (since all JSON is valid),

I know of no exploits; all resulting strings should be shorter than the
input (because of escapes \\ ).  The C version allocates a output buffer
that is the same size as the input, and moves decoded strings into it.
Structure characters [ { } ] , " ' `  don't transfer either.

This does stick to JSON's spirit of only transporting data.  The parser is
very similar to a JSON parser, except many places that would previously
throw are accepted
And references can only link to other objects/arrays within the current
outermost object/array.


> This already happens with plain JSON
> <https://medium.com/@mikesamuel/protecting-against-object-forgery-2d0fd930a7a9>,
> so anything that allows external inputs to specify which internal types to
> construct would have to include a "Security Considerations" section that
> explains how this could be safely used by code that assumes that `if (x
> instanceof InternalType)` then x came from internal code that made a
> good-faith effort to only pass appropriate inputs to `new
> InternalType(...)`.
>
> On Tue, Sep 18, 2018 at 5:22 PM J Decker  wrote:
>
>> (Thank you Rod Sterling)
>>
>> But seriously, I'd like to submit, for serious consideration, JSOX -
>> JavaScript Object eXchange format.  It inherits all JSON syntax such that
>> it is able to process any existing JSON.
>>
>> I'm, at this point, open to changing anything (or even omitting things),
>> including the name.
>>
>> JSON is great.  JSON has some limits, and criticisms... JS/ES Grew , but
>> JSON has to stay the same, similarly with whatever comes next I'd imagine.
>>
>> So a primary goal is to encode and decode ES6 objects for transport with
>> a simple API such as JSOX.parse( object ), and JSOX.stringify( jsoxString
>> ).  But also keep with the simplicity of JSON,
>> so it can be used in human readable circumstances.
>>
>> Types that are now (or soon) native to ES such as TypedArrays (binary
>> data), BigInt types, and even the exis

Submitted for your approval, JSOX

[J Decker]

(Thank you Rod Sterling)

But seriously, I'd like to submit, for serious consideration, JSOX -
JavaScript Object eXchange format.  It inherits all JSON syntax such that
it is able to process any existing JSON.

I'm, at this point, open to changing anything (or even omitting things),
including the name.

JSON is great.  JSON has some limits, and criticisms... JS/ES Grew , but
JSON has to stay the same, similarly with whatever comes next I'd imagine.

So a primary goal is to encode and decode ES6 objects for transport with a
simple API such as JSOX.parse( object ), and JSOX.stringify( jsoxString ).
But also keep with the simplicity of JSON,
so it can be used in human readable circumstances.

Types that are now (or soon) native to ES such as TypedArrays (binary
data), BigInt types, and even the existing Date type, do not transport with
JSON very well.  They become a non-identifable string, that requires extra
code involving knowledge of the structure of the data being transferred to
be able to restore the values to Date(), BigInt(), et al.

So a few weeks ago I started considering what else, beyond these simple
modifications might also be useful, or address criticisms of JSON.
Handling the above types is really a trivial modification to most JSON
parsers.  Each of the following modifications is really only a very slight
change to behavior; although implementing typed-objects does initially
involve changing error handling into identifer-fallback handling.

I initially argued, that defining a object prototype
'card(name,address,zipcode,created)' which removes the redundant data for
every following reference, (and is good, just for data reduction, which was
argued 'gzip').  A JSON representation might be
`{"name":"bob","address":"123
street","zipcode":"5","created":1537304820} where if have a large
number of the same record the same 'name':,'address':, etc is repeated in
every record.  Where a typed-object's value in JSOX could be
`card{:"bob","123 street","5",2018-09-18T21:07:00Z}`.  All objects that
are revived as typed-objects share the same prototype, and before parsing,
the prototypes to be used may be specified.  The amount of data to process
is reduced, perhaps to a significant degree.

So  '{' is about typed-objects.  This construct is not allowed
in JSON.  But that then leads to  '['  - typed arrays, arrays
don't really have redundant data potential like objects, but there are
TypedArrays in ES.  There is no way to define a type of an array, but
hardcoded types like 'ab', 'u8', 'ref' are used to revive binary data.  The
bytes of the backing ArrayBuffer are encoded to base64, and included within
'[' and ']' without quotes; using the brackets as quotes.

A JSOX typed array is the 'ref' type.  A reference to another location in
the current object can be specified, which allows encoding cyclic
structures.



https://github.com/d3x0r/jsox
https://npmjs.com/package/jsox

(Initial public reaction was not very helpful, but probably that's the
fault of how it was introduced?)
https://www.reddit.com/r/javascript/comments/9f8wml/jsox_javascript_object_exchange_format_preview/

There was plenty of 'why not [YAML/BSON/protobufs/(I don't think anyone
said XML)/...]'  and the answer is simply, because none of those read JSON,
or have as simple of an API. (amongst other reasons that JSON is already a
solution for compared to those mentioned)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: __line_number__ and __filename__

[J Decker]

On Thu, Aug 23, 2018 at 5:26 PM Aaron Gray 
wrote:

> I am debugging existing code that I have modularized, and am class'izing
> that has unittests and it just would have been very useful to have this
> facility.
>
In a  browser, console.log is usually associated with the file and line
number anyway; which includes using devtools with node but it would be
handy for logging.  with V8 there is console.trace; which spits out the
stack trace too... before I discovered that I did a logging function
like...

(from
https://stackoverflow.com/questions/591857/how-can-i-get-a-javascript-stack-trace-when-i-throw-an-exception
)
function stackTrace() { var err = new Error(); return err.stack; }  //
parse stack to get frame-1 online

// or maybe just frame-1...
function stackTrace() { var err = new Error(); return err.stack.split( "\n"
)[1]; }

---
function stacktrace() {
  function st2(f) {
return !f ? [] :
st2(f.caller).concat([f.toString().split('(')[0].substring(9) + '('
+ f.arguments.join(',') + ')']);
  }
  return st2(arguments.callee.caller);
}

 EDIT 2 (2017) :

In all modern browsers you can simply call: console.trace(); (MDN Reference)
---

Although I do still miss just being able to get __FILE__ and __LINE__


> On Fri, 24 Aug 2018 at 00:27, Gus Caplan  wrote:
>
>> What is the reasoning behind wanting this data? For example, in
>> exceptional cases you should be creating errors which already have stacks
>> containing this information.
>>
>> -Gus
>>
>>  On Thu, 23 Aug 2018 17:56:43 -0500 *Aaron Gray
>> >* wrote 
>>
>> I wondering what people think about the idea of proposing being able to
>> get the line number and filename of executing code in the code ? Maybe with
>> something simular to C preprocessors __line_number__ and __filename__. Or
>> as subobjects of global ?
>>
>> --
>> Aaron Gray
>>
>> Independent Open Source Software Engineer, Computer Language Researcher,
>> Information Theorist, and amateur computer scientist.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>>
>
> --
> Aaron Gray
>
> Independent Open Source Software Engineer, Computer Language Researcher,
> Information Theorist, and amateur computer scientist.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON support for BigInt in ES6.

[J Decker]

my primary usage of json is
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications#Using_JSON_to_transmit_objects

in which case JSON.parse( JSON.strinigfy( msg ) ) really needs to result in
the same sort of thing as the input; although I guess dates do get lost in
translation anyway, but they could be handled as numbers with a few more
character exceptions ':','-'(in a number),'Z',' ' the last one (the space)
complicating the whole thing immensely; there is no meaning of multiple
numbers without a ',' between them in JSON, so maybe not so impossible.

and given the requirement that seems to be lost, that bigints ONLY interop
with bigints, they MUST decode the same as their encoding; the JSONnumber
type almost works; but requires custom code every time bigints are used.
(much like dates)

what writing a JSON parser taught me, is the type of a variable is the type
of the data it has; and JSON does a really good job of representing 99% of
generally communicated types. which makes generic code quite easy...
without having to respecify/recast the data, the data is already the type
it is.

but there's certainly fewer of me, than of those that thing everything is
perfectly fine, and shouldn't evolve as the langugage has.
but then there's 'don't break the net' and 'this could certainy break the
net'; but since bigints didn't exist before, I guess they shouldn't be
added now, because sending them to old code would break  the old code
but actually since being added; should also update JSON to support that
number type (although I guess base JSON doesn't suppose ES6 number
encodings like 0x, 0b, etc...)

and again, since bigints ONLY interop with other bigints, there should be
no chance they will get lost in interpretation.

can see JSONnumber can aid application handling; but if you send bigints to
an application that doesn't support bigints it's not going to work anyway;
so why not just let existing json.parse throw when it doens't have bigint
support?
On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> For good or for worse I have written a proposal for
> https://github.com/tc39/proposal-bigint/issues/162
> available at
> https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6
>
> Since the proposal doesn't introduce a default serialization mode, I guess
> nobody will be happy :-(
> OTOH, a fairly decent rationale for not specifying a default is also
> provided :-)
> This comment is also worth reading:
> https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859
>
>


> Cheers,
> Anders
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error caused by other error

[J Decker]

don't knwo where yuo're having problems... in node
https://stackoverflow.com/questions/7697038/more-than-10-lines-in-a-node-js-stack-error
which is

Error.stackTraceLimit = Infinity;


which maywork in chrome too

On Mon, Aug 6, 2018 at 5:48 AM Michał Wadas  wrote:

> Was there any proposal to introduce longer stack traces to language?
>
> Eg.
> ```
> try {
> catch Error('foo');
> } catch (err) {
> throw Error('bar'); // stack trace from caught error is lost
> }
> ```
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON support for BigInt in Chrome/V8

[J Decker]

On Sat, Jul 28, 2018 at 6:57 AM Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> In a language with arbitrary integer precision, Python 3 for example, the
> way to parse a "BigInt" would just be a plain, human readable number
> without quotes. The way to serialize it is the same. Any other kind of
> representation is out of spec, a workaround, and belongs in userland.


The problem with this, 'guessing' whether is't a Number() or a BigInt() is
that numbers and bigint's don't interop.

{a:123, b:123n}
" { "a":123, "b":123 }"  any expressions that expect B to be a BigInt()
will fail, becasue it will be in an expression of other bigints.

bigInts aren't just a better Number type, but, rather require other bigints
for their expressions.



>
> I think BigInt should serialize the same, not as strings or anything that
> is not a number. JSON.parse being unable to parse back into BigInt is a
> separate issue. It is solvable by using better parsing methods, not the
> convenient built-in one which has other issues. E.g. a streaming JSON
> parser that lets you inspect the key name and string being parsed can
> handle this. Case solved and you can also redesign your code so you are not
> creating a temporary object every single parse that you most likely copy
> into actual objects later.
>
> Not serializing BigInt is questionable to me but even that can be solved
> in userland.
>
> On Saturday, July 14, 2018, Anders Rundgren 
> wrote:
>
>> var small = BigInt("5");
>> var big = BigInt("553");
>> JSON.stringify([big,small]);
>> VM330:1 Uncaught TypeError: Do not know how to serialize a BigInt
>> at JSON.stringify ()
>> at :1:6
>>
>> JSON Number serialization has apparently reached a new level (of
>> confusion).
>>
>> Personally I don't see the problem.  XML did just fine without hard-coded
>> data types.
>>
>> The JSON type system is basically a relic from JavaScript.  As such it
>> has proved to be quite useful.
>> However, when you are outside of that scope, the point with the JSON type
>> system gets pretty much zero since you anyway need to map extended types.
>>
>> Oracle's JSON-B solution which serializes small values as Number and
>> large values as String rather than having a unified serialization based on
>> the underlying data type seems like a pretty broken concept although indeed
>> fully conforming to the JSON specification. "Like the Devil reads the
>> Bible" as we say in Scandinavia :-)
>>
>> Adding a couple of double quotes is a major problem?  If so, it seems
>> like a way more useful project making quotes optional for keys (named in a
>> specific way), like they already are in JavaScript.
>>
>> Yeah, and of course adding support for comments.
>>
>> Anders
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON support for BigInt in Chrome/V8

[J Decker]

On Tue, Jul 17, 2018 at 9:16 PM Isiah Meadows 
wrote:

> The way this conversation is going, we might as well just create a
> schema-based JSON serialization DSL for both parsing and stringifying.
> But I don't really see that as helpful in the *language itself* at
> least as a mandatory part of the spec (maybe an optional built-in
> module).
>
> I've in the past few months seen similar things come up a few times
> already. I like the idea of a built-in schema-based JSON validator +
> parser (it'd be faster than what we currently have), but most things
> out there suck in some way, mostly just being boilerplatey, and
> there's a lot of design work to get out of the way first before you
> can come up with something that doesn't.
>
> But as it stands, the only things I'd support for the `JSON` global itself
> are:
>
> 1. Adding separate prototypes for `JSON.stringify(source, options)`
> and `JSON.parse(source, options)`, so it's easier to extend and
> comprehend the arguments.
> 2. Adding an option to parse anything consisting of purely digits (no
> exponent or decimal) as a BigInt, regardless of size.
>
This won't work

``` desired object
{ a : 123, b : 123n }
```

``` json
{ "a":123 ,
  "b":123 }
```

 function test( json ) {
   var c = json.a * 5;
   var BIc = json.b * 5n;
}

if long numbers only translate to bigint (and small as Number); the calc
for 'BIc' fails.
if everything is translated to bigint  the calc for 'c' fails.

3. Adding an option to stringify BigInts into integer-only numbers and
> normal numbers into unconditional floats.
>
>


> These could be either separate methods or part of a 4th options argument.
>
>
Well; Since JSON (JavaScript Object Notation) there's now available to JS a
feature that an 'n' suffix can be applied to a number.  Seems JSON should
just inherit that.

Although I would like to see a better method than eval() to translate the
input string from JSON for say { d : 123n }; right now within JS I'd have
to use EVAL; in V8 I could just create a BigInt::new()

(and RE: eval, not saying it's a GOOD solution; it's just apparently the
only solution ATM; other than splicing the string.)


> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Tue, Jul 17, 2018 at 6:52 PM, Michael J. Ryan 
> wrote:
> > Out of bounds as you'd still have to parse it, but for encoding, could
> add
> > BigInt.prototype.toJSON ...
> >
> > On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi <
> andrea.giammar...@gmail.com>
> > wrote:
> >>
> >> I guess a better example would've been `Boolean('false')` returns true,
> >> but yeah, I've moved slightly forward already with everything, if you
> read
> >> other messages.
> >>
> >> Regards.
> >>
> >> On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat 
> >> wrote:
> >>>
> >>> On 07/17/2018 04:27 AM, Andrea Giammarchi wrote:
> >>> > actually, never mind ... but I find it hilarious that
> >>> > BigInt('55501') works but
> >>> > BigInt('55501n') doesn't ^_^;;
> >>>
> >>> That's no different from how other built-in types work.
> String('"foo"')
> >>> doesn't give you the same string as the string literal "foo".
> >>>
> >>>  Waldemar
> >>
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON support for BigInt in Chrome/V8

[J Decker]

On Tue, Jul 17, 2018 at 1:48 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> We miss a fundamental feature in JS, the ability to understand if a native
> constructor can be used with `new` or not.
>
> BigInt("553");
> 553n
>
> new BigInt("553");
> VM51:1 Uncaught TypeError: BigInt is not a constructor
>
>
```
typeof(5n)
"bigint"
 ```

Uint8Array([])
> VM54:1 Uncaught TypeError: Constructor Uint8Array requires 'new'
>
> new Uint8Array([])
> Uint8Array []
>
> Without that knowledge, any attempt to even think about a solution that
> would scale not only with BigInt but with everything else, is kinda futile.
>
> Best Regards.
>
>
>
>
>
>
> On Sun, Jul 15, 2018 at 8:27 AM Anders Rundgren <
> anders.rundgren@gmail.com> wrote:
>
>> On 2018-07-15 08:17, J Decker wrote:
>> 
>> > If you want to use BigInt with JSON you have to serialize it
>> yourself:
>> >
>> > Yes; and I did forget to mentions erilaization side but the serlizer
>> could do an additional type  check and emit and appropriate thing.
>>
>> It is the "appropriate thing" that is problem; the rest is trivial.
>>
>> Anders
>>
>> > I thought the replacer could be used- but the output of replacer would
>> have to type check to see if it's a bigint too
>> > https://github.com/v8/v8/blob/master/src/json-stringifier.cc#L305 case
>> BIGINT_TYPE:  hmm and digging some more there's lots of eexcpetions
>> thrown...
>> >
>> > does Number( "5n" ) ? result in a bigint? No
>> > ```
>> > Number( "5n" )
>> > NaN
>> > var a = 5n
>> > a
>> > 5n
>> > ```
>> >
>> >
>> > var small = BigInt(5n);
>> > var big = BigInt(553n);
>> > JSON.stringify([big.toString(),small.toString()]);
>> >
>> > which generates ["553","5"]
>> >
>> > Anders
>> >
>> >  > var small = 5n;
>> >  > var big = 553n;
>> >  >
>> >  > n suffix as from
>> >  > https://github.com/tc39/proposal-bigint
>> >  >
>> >  > JSON Number serialization has apparently reached a new level
>> (of confusion).
>> >  >
>> >  > Personally I don't see the problem.  XML did just fine
>> without hard-coded data types.
>> >  >
>> >  > The JSON type system is basically a relic from JavaScript.
>> As such it has proved to be quite useful.
>> >  > However, when you are outside of that scope, the point with
>> the JSON type system gets pretty much zero since you anyway need to map
>> extended types.
>> >  >
>> >  > Oracle's JSON-B solution which serializes small values as
>> Number and large values as String rather than having a unified
>> serialization based on the underlying data type seems like a pretty broken
>> concept although indeed fully conforming to the JSON specification. "Like
>> the Devil reads the Bible" as we say in Scandinavia :-)
>> >  >
>> >  > Adding a couple of double quotes is a major problem?  If so,
>> it seems like a way more useful project making quotes optional for keys
>> (named in a specific way), like they already are in JavaScript.
>> >  >
>> >  > Yeah, and of course adding support for comments.
>> >  >
>> >  >
>> >  > I'd rather not see numbers converted to strings; that would be
>> required to allow application handling of values; at a layer higher than
>> JSON core itself.  It is nice that JSON keeps numbers as numbers and
>> strings as strings without needing intimite knowledge about the actual
>> 'types' they end up in.
>> >  >
>> >  > Comparing numeric length would be a half/useless solution since
>> bigints are required to interop with other bigints only; so small numbers
>> couldn't be 'guessed' and the application would have to provide a reviver.
>> >  >
>> >  >
>> >  >
>> >  > Anders
>> >  >
>> >  > ___
>> >  > es-discuss mailing list
>> >  > es-dis

Re: JSON support for BigInt in Chrome/V8

[J Decker]

On Sat, Jul 14, 2018 at 9:23 PM Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-07-15 04:27, J Decker wrote:
> >
> >
> > On Sat, Jul 14, 2018 at 1:36 AM Anders Rundgren <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
> wrote:
> >
> > var small = BigInt("5");
> > var big = BigInt("553");
> > JSON.stringify([big,small]);
> > VM330:1 Uncaught TypeError: Do not know how to serialize a BigInt
> >   at JSON.stringify ()
> >   at :1:6
> >
> >
> > is BigInt the only way to create a BigInt ?  Or did they also implement
> the 'n' suffix, which I noted  here
> https://github.com/tc39/proposal-bigint/issues/24#issuecomment-392307848
> would easily distinguish bigint from other numbers; and be easy to add on
> the parsing side; and call BigInt(xxx) instead of Number(xxx).
>
> This problem is related to the BigInt object itself.  If you create such
> using the 'n' notation you get the same result.
>
> If you want to use BigInt with JSON you have to serialize it yourself:
>
Yes; and I did forget to mentions erilaization side but the serlizer could
do an additional type  check and emit and appropriate thing.
I thought the replacer could be used- but the output of replacer would have
to type check to see if it's a bigint too
https://github.com/v8/v8/blob/master/src/json-stringifier.cc#L305 case
BIGINT_TYPE:  hmm and digging some more there's lots of eexcpetions
thrown...

does Number( "5n" ) ? result in a bigint? No
```
Number( "5n" )
NaN
var a = 5n
a
5n
```


> var small = BigInt(5n);
> var big = BigInt(553n);
> JSON.stringify([big.toString(),small.toString()]);
>
> which generates ["553","5"]
>
Anders
>
> > var small = 5n;
> > var big = 553n;
> >
> > n suffix as from
> > https://github.com/tc39/proposal-bigint
> >
> > JSON Number serialization has apparently reached a new level (of
> confusion).
> >
> > Personally I don't see the problem.  XML did just fine without
> hard-coded data types.
> >
> > The JSON type system is basically a relic from JavaScript.  As such
> it has proved to be quite useful.
> > However, when you are outside of that scope, the point with the JSON
> type system gets pretty much zero since you anyway need to map extended
> types.
> >
> > Oracle's JSON-B solution which serializes small values as Number and
> large values as String rather than having a unified serialization based on
> the underlying data type seems like a pretty broken concept although indeed
> fully conforming to the JSON specification. "Like the Devil reads the
> Bible" as we say in Scandinavia :-)
> >
> > Adding a couple of double quotes is a major problem?  If so, it
> seems like a way more useful project making quotes optional for keys (named
> in a specific way), like they already are in JavaScript.
> >
> > Yeah, and of course adding support for comments.
> >
> >
> > I'd rather not see numbers converted to strings; that would be required
> to allow application handling of values; at a layer higher than JSON core
> itself.  It is nice that JSON keeps numbers as numbers and strings as
> strings without needing intimite knowledge about the actual 'types' they
> end up in.
> >
> > Comparing numeric length would be a half/useless solution since bigints
> are required to interop with other bigints only; so small numbers couldn't
> be 'guessed' and the application would have to provide a reviver.
> >
> >
> >
> > Anders
> >
> > _______
> > es-discuss mailing list
> > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
On Sat, Jul 14, 2018 at 9:23 PM Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-07-15 04:27, J Decker wrote:
> >
> >
> > On Sat, Jul 14, 2018 at 1:36 AM Anders Rundgren <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
> wrote:
> >
> > var small = BigInt("5");
> > var big = BigInt("553");
> > JSON.stringify([big,small]);
> &g

Re: JSON support for BigInt in Chrome/V8

[J Decker]

On Sat, Jul 14, 2018 at 1:36 AM Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> var small = BigInt("5");
> var big = BigInt("553");
> JSON.stringify([big,small]);
> VM330:1 Uncaught TypeError: Do not know how to serialize a BigInt
>  at JSON.stringify ()
>  at :1:6
>
>
is BigInt the only way to create a BigInt ?  Or did they also implement the
'n' suffix, which I noted  here
https://github.com/tc39/proposal-bigint/issues/24#issuecomment-392307848
would easily distinguish bigint from other numbers; and be easy to add on
the parsing side; and call BigInt(xxx) instead of Number(xxx).

var small = 5n;
var big = 553n;

n suffix as from
https://github.com/tc39/proposal-bigint


> JSON Number serialization has apparently reached a new level (of
> confusion).
>
> Personally I don't see the problem.  XML did just fine without hard-coded
> data types.
>
> The JSON type system is basically a relic from JavaScript.  As such it has
> proved to be quite useful.
> However, when you are outside of that scope, the point with the JSON type
> system gets pretty much zero since you anyway need to map extended types.
>
> Oracle's JSON-B solution which serializes small values as Number and large
> values as String rather than having a unified serialization based on the
> underlying data type seems like a pretty broken concept although indeed
> fully conforming to the JSON specification. "Like the Devil reads the
> Bible" as we say in Scandinavia :-)
>
> Adding a couple of double quotes is a major problem?  If so, it seems like
> a way more useful project making quotes optional for keys (named in a
> specific way), like they already are in JavaScript.
>
> Yeah, and of course adding support for comments.
>

I'd rather not see numbers converted to strings; that would be required to
allow application handling of values; at a layer higher than JSON core
itself.  It is nice that JSON keeps numbers as numbers and strings as
strings without needing intimite knowledge about the actual 'types' they
end up in.

Comparing numeric length would be a half/useless solution since bigints are
required to interop with other bigints only; so small numbers couldn't be
'guessed' and the application would have to provide a reviver.




>
> Anders
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "Stupid" JSON Number Serialization Question

[J Decker]

On Sat, May 19, 2018 at 8:48 PM, Hikaru Nakashima 
wrote:

> Sorry for lack of words.
> What I am talking about is a new proposal to modify `JSON.parse()`.
>

There is json5 (json5.org; github.com/json5/json5; npmjs.com/package/json5)

or I would entertain such things for json6...
There is json5 (github.com/d3x0r/json6; npmjs.com/package/json-6)

I would propose an addtional parameter passed to the reviver callback that
is the original string value read from the JSON.




> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Array.prototype.shuffle (Fisher-Yates)

[J Decker]

>
>
> >
> > While a good shuffle should be able to start from the initial state and
> > generate a good shuffled result, it is slightly better to progressively
> > shuffle the previous result array into new positions than to start from
> an
> > initial state and compute a 1-off.
>
> Evidence? (BTW, the Fisher-Yates shuffle is theoretically as biased as
> the RNG that powers it.)
>
>
Specifically re-1-off vs progressive shuffling?  Not on-hand; it was an
evaluation I did 10 years ago; and while the difference wasn't that much,
it was notable.  the rate for any single ball to be in a specific position
took longer (by iteration count) when resetting the array to shuffle to
initial conditions (1-N)


Fisher-Yates. is biased by the usage of the number generator; not just the
generator.
I've been considering how to graphically/visually demonstrate it; but I'v
failed so far.

for a list of 10 numbers; and a 'perfect' RNG.
For the last number, it's 90% guaranteed to evaluate it's shuffle twice.
(10% it won't move) It has a 10% chance to be in the last position, but
only a 1.1% chance to be in the second to last position.  (1/10 * 1/9 =
1/90 = 0.011...) so it will NOT be the last position 90% but it will NOT be
the second to last 98.9% of the time.  For an ideal shuffle, every original
position will end up in every other position 10% of the time.



> >
> > On Sun, Apr 29, 2018 at 3:27 PM, Isiah Meadows 
> > wrote:
> >>
> >> BTW, I added this to my list of various proposed array additions (as a
> >> weak one) [1].
> >>
> >> I did do a little reading up and found that in general, there's a
> >> major glitch that makes shuffling very hard to get right (issues even
> >> Underscore's `_.shuffle` doesn't address), specifically that of the
> >> size of the random number generator vs how many permutations it can
> >> hit. Specifically, if you want any properly unbiased shuffles covering
> >> all permutations of arrays larger than 34 entries (and that's not a
> >> lot), you can't use any major engines' `Math.random` (which typically
> >> have a max seed+period of 128 bits). You have to roll your own
> >> implementation, and you need at least something like xorshift1024* [2]
> >> (1024-bit max seed/period size) for up to 170 entries, MT19937
> >> [3]/WELL19937 [4] (seed/period up to 2^19937-1) for up to 2080
> >> entries, or MT44497/WELL44497 for up to 4199 entries. Keep in mind the
> >> minimum seed/period size in bits grows roughly `ceil(log2(fact(N)))`
> >> where `N` is the length of the array [5], and the only way you can
> >> guarantee you can even generate all possible permutations of all
> >> arrays (ignoring potential bias) is through a true hardware generator
> >> (with its potentially infinite number of possibilities). Also, another
> >> concern is that the loop's bottleneck is specifically the random
> >> number generation, so you can't get too slow without resulting in a
> >> *very* slow shuffle.
> >>
> >> If you want anything minimally biased and much larger than that,
> >> you'll need a cryptographically secure pseudorandom number generator
> >> just to cover the possible states. (This is about where the
> >> intersection meets between basic statistics and cryptography, since
> >> cipher blocks are frequently that long.) But I'm leaving that as out
> >> of scope of that proposal.
> >>
> >> [1]:
> >> https://github.com/isiahmeadows/array-additions-
> proposal#arrayprototypeshuffle
> >> [2]: https://en.wikipedia.org/wiki/Xorshift#xorshift*
> >> [3]: https://en.wikipedia.org/wiki/Mersenne_Twister
> >> [4]: https://en.wikipedia.org/wiki/Well_equidistributed_long-
> period_linear
> >> [5]:
> >> http://www.wolframalpha.com/input/?i=plot+ceiling(log2(x!)
> )+where+0+%3C+x+%3C+1
> >>
> >> -
> >>
> >> Isiah Meadows
> >> m...@isiahmeadows.com
> >>
> >> Looking for web consulting? Or a new website?
> >> Send me an email and we can get started.
> >> www.isiahmeadows.com
> >>
> >>
> >> On Sun, Apr 29, 2018 at 4:01 PM, Alexander Lichter 
> wrote:
> >> > On 29.04.2018 18:34, Naveen Chawla wrote:
> >> >>
> >> >> I don't think there's such a thing as "real random" in digital algos,
> >> >> just
> >> >> "pseudo random".
> >> >
> >> > You are right. I meant 'unbiased' pseudo randomness here.
> >> >
> >> >> Apart from card games, what's the use case?
> >> >
> >> > There are a lot of potential use cases. The best that comes into my
> mind
> >> > is
> >> > sampling test data.
> >> >
> >> >
> >> > On 29.04.2018 19:01, Isiah Meadows wrote:
> >> >>
> >> >> I think this would be better suited for a library function rather
> than
> >> >> a
> >> >> language feature. I could see this also being useful also for
> >> >> randomized displays, but that's about it. And I'm not sure what an
> >> >> engine could provide here that a library couldn't - you can't really
> >> >> get much faster than what's in the language (minus bounds checking,
> >> >> but the likely frequent cache misses will 

Re: Re: Proposal: Array.prototype.shuffle (Fisher-Yates)

[J Decker]

I can see that's certainly something that can be gotten wrong; the in-place
sort is kind-of nice; but you end up hitting most numbers twice, and with a
longer array (say a set of 75 bingo balls) you can move the same number
multiple times.

which gives numbers at the end a higher chance of being at the start when
all is done; and almost guaranteed to not be at the end.  I use sha2 as a
stream of bits; and when it runs out of bits, invokes a callback to get
more salt ( that is optional, although adding Date.now() is sufficient to
increase the overall entropy slightly  ).   This can also be used as a
generator procedural content generation, since you can specify the initial
salt and subsequent salts,  or even copy the state, and fork two streams
using slightly different progressive entropy.
https://github.com/d3x0r/-/blob/master/org.d3x0r.common/
salty_random_generator.js

And then to shuffle, for each number in the array, assign a random number;
hang in a binary tree from least to most; then gather the tree back out.
requires additional memory approximately the 4xsize of the original array
tough temporarily.  (don't seem to have a JS version, but the C version
ports pretty easily)
https://github.com/d3x0r/SACK/blob/master/src/utils/cardodds/shuffle.c

This allows any number to result in any position equally.
The SHA2 hash generates very good random number characteristics; evaluating
with diehard tests; chi-square etc.
Allowing more salt to be introduced periodically destroys any overall
period (even if it is in the realm of 256 bits).

if you were shuffling a deck of cards (52) you only need random values that
are 6-7 bits at a time...

It is slower than say http://www.pcg-random.org/using-pcg.html or mersenne,
both of which I found to be very poor.  pcg generates zeros like 70% of the
time.

While a good shuffle should be able to start from the initial state and
generate a good shuffled result, it is slightly better to progressively
shuffle the previous result array into new positions than to start from an
initial state and compute a 1-off.

On Sun, Apr 29, 2018 at 3:27 PM, Isiah Meadows 
wrote:

> BTW, I added this to my list of various proposed array additions (as a
> weak one) [1].
>
> I did do a little reading up and found that in general, there's a
> major glitch that makes shuffling very hard to get right (issues even
> Underscore's `_.shuffle` doesn't address), specifically that of the
> size of the random number generator vs how many permutations it can
> hit. Specifically, if you want any properly unbiased shuffles covering
> all permutations of arrays larger than 34 entries (and that's not a
> lot), you can't use any major engines' `Math.random` (which typically
> have a max seed+period of 128 bits). You have to roll your own
> implementation, and you need at least something like xorshift1024* [2]
> (1024-bit max seed/period size) for up to 170 entries, MT19937
> [3]/WELL19937 [4] (seed/period up to 2^19937-1) for up to 2080
> entries, or MT44497/WELL44497 for up to 4199 entries. Keep in mind the
> minimum seed/period size in bits grows roughly `ceil(log2(fact(N)))`
> where `N` is the length of the array [5], and the only way you can
> guarantee you can even generate all possible permutations of all
> arrays (ignoring potential bias) is through a true hardware generator
> (with its potentially infinite number of possibilities). Also, another
> concern is that the loop's bottleneck is specifically the random
> number generation, so you can't get too slow without resulting in a
> *very* slow shuffle.
>
> If you want anything minimally biased and much larger than that,
> you'll need a cryptographically secure pseudorandom number generator
> just to cover the possible states. (This is about where the
> intersection meets between basic statistics and cryptography, since
> cipher blocks are frequently that long.) But I'm leaving that as out
> of scope of that proposal.
>
> [1]: https://github.com/isiahmeadows/array-additions-
> proposal#arrayprototypeshuffle
> [2]: https://en.wikipedia.org/wiki/Xorshift#xorshift*
> [3]: https://en.wikipedia.org/wiki/Mersenne_Twister
> [4]: https://en.wikipedia.org/wiki/Well_equidistributed_long-period_linear
> [5]: http://www.wolframalpha.com/input/?i=plot+ceiling(log2(x!)
> )+where+0+%3C+x+%3C+1
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Sun, Apr 29, 2018 at 4:01 PM, Alexander Lichter  wrote:
> > On 29.04.2018 18:34, Naveen Chawla wrote:
> >>
> >> I don't think there's such a thing as "real random" in digital algos,
> just
> >> "pseudo random".
> >
> > You are right. I meant 'unbiased' pseudo randomness here.
> >
> >> Apart from card games, what's the use case?
> >
> > There are a lot of potential use cases. The best that comes into my mind
> is
> > sampling test data.
> >
> >
> > On 

Re: How many ES5 environments are still in use today?

[J Decker]

On Mon, Apr 2, 2018 at 12:46 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> I guess when it comes to other projects Wikipedia Wikipedia should be
> enough:
> https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
>
>
They're missing at least one...
https://www.gnu.org/software/librejs/ which looks like it is missing es6
features (as of aug last year anyway... still?)


> FWIW I think only Chakra, SpiderMonkey, JavaScriptCore, Nashorn, QtScript
> (although, not standard at all), Duktape, Moddable (R.I.P. Kinoma),
> Espruino, MuJS (new to me!), and JerryScript are the actively
> used/developed/maintained, and the list misses GJS, but I guess that's
> because it's based on SpiderMonkey.
>
> Purely ES5 start with IE9 on browser land, but includes IE11 too which is
> still quite popular.
>
> Not fully ES2015 is Chrome 49 which is the latest Chrome version supported
> in both Windows XP and Vista and there are still users that won't let that
> old/cracked OS go, regardless all security issues they have.
>
> Opera 36 is at the same state of Chrome 49, and things are pretty
> different on mobile too.
>
> All phones from 2015 are stuck behind older Android versions or, even
> worst, Samsung Internet, like it is for the Galaxy A3 case which is still a
> pretty good looking phone.
>
> However, Samsung Browser 4.0 is not too bad compared to IE11, as you can
> see in this gist:
> https://gist.github.com/WebReflection/1411b420574c1cc4b4f08fcf9cd960
> c8#gistcomment-2399378
>
> Have I answered your question ?
>
>
>
>
>
> On Mon, Apr 2, 2018 at 9:18 PM, /#!/JoePea  wrote:
>
>> I'm curious to know how many pure ES% environments (with or without
>> non-standard features like __proto__, and without any ES6 features) are
>> still being used in the wild.
>>
>> Would this come down to a browser statistics lookup? I believe there are
>> other projects that use ES, like Rhino, Espruino, etc. Do you know of some
>> place to get such statistics besides for browsers?
>>
>> */#!/*JoePea
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.repeat

[J Decker]

On Sun, Mar 25, 2018 at 1:40 PM, Claude Pache 
wrote:

>
>
> Le 25 mars 2018 à 20:27, Cyril Auburtin  a
> écrit :
>
> String and Array share a few methods.
>
> I think `repeat` could exist for Array as well
>
> At the moment are other more verbose ways to do so:
>
> - `Array.from({length: n}, () => 'foo')`
> - `Array(n).fill('foo')`
> - `[].concat(...Array.from({length: 3}, () => ['x', 'y']))`
> - `[].concat(...Array(3).fill(['x', 'y']))`
>
> so with repeat it would just be;
>
> - `['foo'].repeat(n)`
> - `['x', 'y'].repeat(3)`
>
>
> For filling a new array with one value, `Array(n).fill('foo')` seems
> reasonable to me.
>
> Are there use cases for filling with alternating values, as in `['x',
> 'y'].repeat(3)`?
>

maybe fill with incrementing number?


>
> —Claude
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pointers

[J Decker]

On Mon, Mar 19, 2018 at 6:17 PM, J Decker <d3c...@gmail.com> wrote:

>
>
> On Mon, Mar 19, 2018 at 6:01 PM, Isiah Meadows <isiahmead...@gmail.com>
> wrote:
>
>> C# isn't the only OO language to have references. PHP has them too,
>> although the awkwardness isn't the references themselves as much as
>> how the language integrates with them. OCaml also has reified
>> references as separate from their mutable record properties.
>>
>> Note that C#'s "out" parameters aren't the same as what's being
>> proposed here. Ron's proposal shares more in common with Rust's `foo:
>>  Foo` parameters and C/C++'s `` (address-of) operator than
>> C#'s `out` parameters, since the proposal doesn't restrict their use
>> to just parameters, and it doesn't just treat them as alternate return
>> targets. C# has those just for C interop and little else, while Rust
>> and OCaml have them for general use. If we're going to have
>> general-use references, let's not mimic C#'s very awkward mess when we
>> do it.
>>
>> (JS is a much lower level language than it looks. It abstracts less
>> than most other common dynamic languages.)
>>
>>
> I didn't mean to stress 'out'.  'ref' was really the only thing I meant
> for a take-away.
>
> other than in parameters, I don't see a use...
> I went back to the top and re-read with these new colored glasses...
>
> var:prt is terrible; that would be a printer...or maybe part  :)  var:ptr;
> and since it's not a pointer, maybe ref instead?
>
>
> what if the property is a  setter/getter reference when getting a set/get
> property.
>
> var x = {
>   name : 'foo',
>   get Name() { return name }
>   set Name() { this.name = name };
> }
>
> var:ref getterRef = x.Name  // retain both set and get?
>
> var:ref xName = x.name;
>
> (then changing either xName or x.name (or x.Name) to a new value
>
>
and I meant to say you could keep references

var xNameRef = { obj : x, field : 'name' }

xNameRef.obj[xNameRef.field]


as a generic way of referencing anything. ...


>
>
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>>
>> Looking for web consulting? Or a new website?
>> Send me an email and we can get started.
>> www.isiahmeadows.com
>>
>>
>> On Mon, Mar 19, 2018 at 8:37 PM, J Decker <d3c...@gmail.com> wrote:
>> > Ahh parameters by reference yes have wished for that...
>> >
>> > ref is C#-ism to me... which also maybe 'out' which really isn't
>> different
>> > in JS in C# it enforces that the value is set in the function
>> receiving
>> > an out 'must give value to parameter'.
>> >
>> >
>> > On Mon, Mar 19, 2018 at 5:28 PM, Isiah Meadows <isiahmead...@gmail.com>
>> > wrote:
>> >>
>> >> This is basically what I was proposing, ironically enough. There's a
>> >> few small differences, but the only one that substantially varied from
>> >> mine I filed an issue in your repo against. (I almost went for
>> >> `value`.)
>> >>
>> >> BTW, yours looks a *lot* like OCaml's `ref 'a` type, which is just
>> >> sugar for `{mutable contents : 'a}`. The only difference is that OCaml
>> >> doesn't allow you to take a reference to a mutable property, while
>> >> yours does.
>> >> -
>> >>
>> >> Isiah Meadows
>> >> m...@isiahmeadows.com
>> >>
>> >> Looking for web consulting? Or a new website?
>> >> Send me an email and we can get started.
>> >> www.isiahmeadows.com
>> >>
>> >>
>> >> On Mon, Mar 19, 2018 at 7:57 PM, Ron Buckton <
>> ron.buck...@microsoft.com>
>> >> wrote:
>> >> >> -Original Message-
>> >> >> From: es-discuss <es-discuss-boun...@mozilla.org> On Behalf Of
>> Isiah
>> >> >> Meadows
>> >> >> Sent: Monday, March 19, 2018 3:21 PM
>> >> >> To: Michael J. Ryan <track...@gmail.com>
>> >> >> Cc: es-discuss <es-discuss@mozilla.org>
>> >> >> Subject: Re: Pointers
>> >> >>
>> >> >> And even if we *could* get pointers into JS, I'd *strongly* not
>> want it
>> >> >> to be
>> >> >> like what's proposed here. Instead, I'd prefer an object
>> encapsulating
>> >> >> a
>> >> >> reference to a variable, something like this (although engines could
>> >> >> avoid the
>> >> >> ceremony of closures here):
>> >> >>
>> >> >> ```js
>> >> >> let foo = 1;
>> >> >>
>> >> >> func(ref foo, bar)
>> >> >> // Equivalent to:
>> >> >> func({deref: () => foo, set: v => foo = v}, bar)
>> >> >>
>> >> >> function func(ref foo, bar) {
>> >> >> foo += 2
>> >> >> }
>> >> >>
>> >> >> // Equivalent to:
>> >> >> function func(foo) {
>> >> >> foo.set(foo.deref() + 2)
>> >> >> }
>> >> >> ```
>> >> >
>> >> > I put together a strawman for this last year at
>> >> > https://github.com/rbuckton/proposal-refs, but I haven't had much
>> time to
>> >> > work on it.
>> >> >
>> >> > Ron
>> >> ___
>> >> es-discuss mailing list
>> >> es-discuss@mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pointers

[J Decker]

On Mon, Mar 19, 2018 at 6:01 PM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

> C# isn't the only OO language to have references. PHP has them too,
> although the awkwardness isn't the references themselves as much as
> how the language integrates with them. OCaml also has reified
> references as separate from their mutable record properties.
>
> Note that C#'s "out" parameters aren't the same as what's being
> proposed here. Ron's proposal shares more in common with Rust's `foo:
>  Foo` parameters and C/C++'s `` (address-of) operator than
> C#'s `out` parameters, since the proposal doesn't restrict their use
> to just parameters, and it doesn't just treat them as alternate return
> targets. C# has those just for C interop and little else, while Rust
> and OCaml have them for general use. If we're going to have
> general-use references, let's not mimic C#'s very awkward mess when we
> do it.
>
> (JS is a much lower level language than it looks. It abstracts less
> than most other common dynamic languages.)
>
>
I didn't mean to stress 'out'.  'ref' was really the only thing I meant for
a take-away.

other than in parameters, I don't see a use...
I went back to the top and re-read with these new colored glasses...

var:prt is terrible; that would be a printer...or maybe part  :)  var:ptr;
and since it's not a pointer, maybe ref instead?


what if the property is a  setter/getter reference when getting a set/get
property.

var x = {
  name : 'foo',
  get Name() { return name }
  set Name() { this.name = name };
}

var:ref getterRef = x.Name  // retain both set and get?

var:ref xName = x.name;

(then changing either xName or x.name (or x.Name) to a new value



> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Mon, Mar 19, 2018 at 8:37 PM, J Decker <d3c...@gmail.com> wrote:
> > Ahh parameters by reference yes have wished for that...
> >
> > ref is C#-ism to me... which also maybe 'out' which really isn't
> different
> > in JS in C# it enforces that the value is set in the function
> receiving
> > an out 'must give value to parameter'.
> >
> >
> > On Mon, Mar 19, 2018 at 5:28 PM, Isiah Meadows <isiahmead...@gmail.com>
> > wrote:
> >>
> >> This is basically what I was proposing, ironically enough. There's a
> >> few small differences, but the only one that substantially varied from
> >> mine I filed an issue in your repo against. (I almost went for
> >> `value`.)
> >>
> >> BTW, yours looks a *lot* like OCaml's `ref 'a` type, which is just
> >> sugar for `{mutable contents : 'a}`. The only difference is that OCaml
> >> doesn't allow you to take a reference to a mutable property, while
> >> yours does.
> >> -
> >>
> >> Isiah Meadows
> >> m...@isiahmeadows.com
> >>
> >> Looking for web consulting? Or a new website?
> >> Send me an email and we can get started.
> >> www.isiahmeadows.com
> >>
> >>
> >> On Mon, Mar 19, 2018 at 7:57 PM, Ron Buckton <ron.buck...@microsoft.com
> >
> >> wrote:
> >> >> -Original Message-
> >> >> From: es-discuss <es-discuss-boun...@mozilla.org> On Behalf Of Isiah
> >> >> Meadows
> >> >> Sent: Monday, March 19, 2018 3:21 PM
> >> >> To: Michael J. Ryan <track...@gmail.com>
> >> >> Cc: es-discuss <es-discuss@mozilla.org>
> >> >> Subject: Re: Pointers
> >> >>
> >> >> And even if we *could* get pointers into JS, I'd *strongly* not want
> it
> >> >> to be
> >> >> like what's proposed here. Instead, I'd prefer an object
> encapsulating
> >> >> a
> >> >> reference to a variable, something like this (although engines could
> >> >> avoid the
> >> >> ceremony of closures here):
> >> >>
> >> >> ```js
> >> >> let foo = 1;
> >> >>
> >> >> func(ref foo, bar)
> >> >> // Equivalent to:
> >> >> func({deref: () => foo, set: v => foo = v}, bar)
> >> >>
> >> >> function func(ref foo, bar) {
> >> >> foo += 2
> >> >> }
> >> >>
> >> >> // Equivalent to:
> >> >> function func(foo) {
> >> >> foo.set(foo.deref() + 2)
> >> >> }
> >> >> ```
> >> >
> >> > I put together a strawman for this last year at
> >> > https://github.com/rbuckton/proposal-refs, but I haven't had much
> time to
> >> > work on it.
> >> >
> >> > Ron
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pointers

[J Decker]

Ahh parameters by reference yes have wished for that...

ref is C#-ism to me... which also maybe 'out' which really isn't different
in JS in C# it enforces that the value is set in the function receiving
an out 'must give value to parameter'.


On Mon, Mar 19, 2018 at 5:28 PM, Isiah Meadows 
wrote:

> This is basically what I was proposing, ironically enough. There's a
> few small differences, but the only one that substantially varied from
> mine I filed an issue in your repo against. (I almost went for
> `value`.)
>
> BTW, yours looks a *lot* like OCaml's `ref 'a` type, which is just
> sugar for `{mutable contents : 'a}`. The only difference is that OCaml
> doesn't allow you to take a reference to a mutable property, while
> yours does.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Mon, Mar 19, 2018 at 7:57 PM, Ron Buckton 
> wrote:
> >> -Original Message-
> >> From: es-discuss  On Behalf Of Isiah
> >> Meadows
> >> Sent: Monday, March 19, 2018 3:21 PM
> >> To: Michael J. Ryan 
> >> Cc: es-discuss 
> >> Subject: Re: Pointers
> >>
> >> And even if we *could* get pointers into JS, I'd *strongly* not want it
> to be
> >> like what's proposed here. Instead, I'd prefer an object encapsulating a
> >> reference to a variable, something like this (although engines could
> avoid the
> >> ceremony of closures here):
> >>
> >> ```js
> >> let foo = 1;
> >>
> >> func(ref foo, bar)
> >> // Equivalent to:
> >> func({deref: () => foo, set: v => foo = v}, bar)
> >>
> >> function func(ref foo, bar) {
> >> foo += 2
> >> }
> >>
> >> // Equivalent to:
> >> function func(foo) {
> >> foo.set(foo.deref() + 2)
> >> }
> >> ```
> >
> > I put together a strawman for this last year at
> https://github.com/rbuckton/proposal-refs, but I haven't had much time to
> work on it.
> >
> > Ron
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pointers

[J Decker]

Pointers are also useful for microoptimization of stepping through
arrays... but it wouldn't help JS without a lot of work in the engines...

for( var x = 0; x < width*height; x++ ) {
arr[x] = 3;
}

-

var ptr = arr;
for( var x = 0; x < width*height; x++ ) {
ptr[0] = 3;
ptr++;
}

since a pointer plus a constant is always more efficient than a pointer
plus a variable amount that usually also has to be multiplied.

The second also serializes into SSE instructions when optimized so it can
do multiple loop steps at a time.




On Mon, Mar 19, 2018 at 3:20 PM, Isiah Meadows 
wrote:

> And even if we *could* get pointers into JS, I'd *strongly* not want
> it to be like what's proposed here. Instead, I'd prefer an object
> encapsulating a reference to a variable, something like this (although
> engines could avoid the ceremony of closures here):
>
> ```js
> let foo = 1;
>
> func(ref foo, bar)
> // Equivalent to:
> func({deref: () => foo, set: v => foo = v}, bar)
>
> function func(ref foo, bar) {
> foo += 2
> }
>
> // Equivalent to:
> function func(foo) {
> foo.set(foo.deref() + 2)
> }
> ```
>
> I've found myself more than once wanting a way to manipulate a
> variable by reference, in a way that's a bit more ergonomic than just
> creating a single-property object. It doesn't need to be much, but it
> doesn't need to be much. As a concrete example, recursive string
> joining could just pass a shared reference instead of an object with a
> single property:
>
> ```js
> function recursiveJoinLoop(ref str, array, sep) {
> if (Array.isArray(array)) {
> for (const item of array) recursiveJoinLoop(ref str, item, sep)
> } else {
> if (str == null) str = ""
> str += String(array)
> }
> }
>
> function recursiveJoin(array, sep) {
> let str
> for (const item of array) recursiveJoinLoop(ref str, array, sep)
> return str
> }
> ```
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Mon, Mar 19, 2018 at 5:48 PM, Michael J. Ryan 
> wrote:
> > Please no, mutable objects are bad enough imho.
> >
> > On Mon, Mar 19, 2018, 12:47 Sebastian Malton 
> wrote:
> >>
> >> Proposal:
> >> Add a new variable-esk type called pointer which acts sort of like a
> >> reference to the data which it has been assigned to but modifies also
> the
> >> original reference when modified.
> >>
> >> Justification:
> >> When working with objects in particular it is often useful for satiny
> >> reasons to use local variables (mostly const's) as a shorthand reference
> >> both for compactness and also so that you don't have to type out the
> entire
> >> path every type. This would allow for non - objects but also overwriting
> >> objects if wanted but still have this freedom and convenience.
> >>
> >> Method:
> >> Add a new notation
> >>
> >> ```
> >> let:prt name = obj.field.name.fullname;
> >> ```
> >>
> >> Here if `name` is updated or if `obj.field.name.fullname` is updated so
> is
> >> the other.
> >>
> >> Sebastian Malton
> >>
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: add reverse() method to strings

[J Decker]

Other than for amusement or programming challenge I've never found a use
for it? Do you have one?

On Sat, Mar 17, 2018 at 4:11 PM, Felipe Nascimento de Moura <
felipenmo...@gmail.com> wrote:

> I would use `Array.from`:
>
> ```
> str = "a_\uD83D\uDE80_b"
> Array.from(str).reverse().join('')
> ```
>
> But I also upvote the idea of having a reverse method in strings :)
>
> If `reverse` might cause some retrocompatibility problem (although I don't
> think it requires params, what would pretty much avoid different
> implementations as the method itself is very straight forwards), we could
> go for `reverseText` or `reverseContent`.
>
> .o/
>
>
>
> [ ]s
>
> *--*
>
> *Felipe N. Moura*
> Web Developer, Google Developer Expert
> , Founder of
> BrazilJS  and Nasc .
>
> Website:  http://felipenmoura.com / http://nasc.io/
> Twitter:@felipenmoura 
> Facebook: http://fb.com/felipenmoura
> LinkedIn: http://goo.gl/qGmq
> -
> *Changing  the  world*  is the least I expect from  myself!
>
> On Sat, Mar 17, 2018 at 4:48 PM, Thomas Grainger 
> wrote:
>
>> String.prototype.reverse() might break web compatibility, how about
>> String.prototype.turnyRoundy()?
>>
>> On 17 Mar 2018 18:47, "Claude Pache"  wrote:
>>
>>>
>>>
>>> Le 17 mars 2018 à 19:29, Oriol _  a écrit :
>>>
>>> Be aware your code breaks pair surrogates, which might be undesirable:
>>>
>>> ```js
>>> var str = "a_\uD83D\uDE80_b";
>>> str.split("").reverse().join(""); // "b_\uDE80\uD83D_a" :(
>>> [...str].reverse().join("");  // "b_\uD83D\uDE80_a" :)
>>> ```
>>>
>>> —Oriol
>>>
>>>
>>> Well, but be aware that the corrected implementation still breaks
>>> graphemes composed by a sequence of code points, such as: n̈ ( LATIN SMALL
>>> LETTER N + COMBINING DIEARESIS), which might be undesirable...
>>>
>>> Anyway, what are the use cases?
>>>
>>> —Claude
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Native Tensor support

[J Decker]

https://github.com/yiransheng/tensor-ops-js

On Sun, Jan 28, 2018 at 6:08 AM, Michał Wadas  wrote:

> Why should be it included in standard library?
>
> Are there widely used  libraries providing similar capabilities?
>
> Why is it preferable to implementing tensor operations in Web Assembly?
>
>
> On 27 Jan 2018 2:50 am, "Robert Eisele"  wrote:
>
> Hello,
>
> Allocating multi-dimensional arrays in Javascript is only possible by
> building each dimension individually. In addition to being a very tedious
> job, a developer has no control over memory usage, which in general is
> likely to be very high.
>
> Seeing an array algebraically as a vector, typed arrays have already
> created the ability to work more efficiently and memory-consciously with
> lists of numbers. A natural extension of this is not just a matrix, but a
> tensor.
>
> I would like to suggest tensors as a native language construct in ES. This
> would have the advantage that developers could write highly parallelizable
> code independently of WebGL. As an API one could introduce the following
> classes in analogy to typed arrays:
>
> - IntXTensor
> - UintXTensor
> - FloatXTensor
>
> Where X is one of {8, 16, 32, 64}. To make these tensor objects really
> effective, it is necessary to introduce meaningful operations, maybe
> similar to the features of TensorFlow. I think by introducing tensors in
> the browser (but also node.js), a wide range of new applications open up.
> For example, working with deep learning right in the browser or calculating
> filters on images without having to write shaders for them.
>
> The most important thing probably is having a way of storing high
> dimensional data in the browser without worrying about the memory
> footprint, even for complex applications.
>
> What do you think about it?
>
> Robert Eisele
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Performance of frozen vs non-frozen objects

[J Decker]

On Wed, Dec 27, 2017 at 7:52 PM, Isiah Meadows 
wrote:

> Yeah...I've been having issues creating test cases, too. I feel one of
> us should probably report it. (I don't have the time ATM, and it's not
> something you can easily reproduce, so it might take a non-trivial
> amount of time.)
>
couldn't figure out where to report it.  Just gave up.   Finally got the
mod I wanted to see done though
https://jsperf.com/freeze-vs-seal-vs-normal/36  using 'const' instead of
var.  Results in the same performances anyway.

I did notice that often sealed and frozen objects in V8 are either slower
than or the same speed as unfrozen objects.  (in near latest Node JS).


> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Wed, Dec 27, 2017 at 8:23 PM, Boris Zbarsky  wrote:
> > On 12/26/17 9:07 AM, Mark Miller wrote:
> >>
> >> I tried https://jsperf.com/freeze-vs-seal-vs-normal/3 and
> >> https://jsperf.com/freeze-vs-seal-vs-normal/28 on Chrome, FF, and
> >> Safari. I don't know why the bar charts are not updating. I am
> >> traveling and do not currently have access to a machine running
> Edge.
> >>
> >> Could someone who has access to all four browsers, and knows how to
> >> get the displayed data to update, try these on all four? Thanks.
> >
> >
> > It's pretty hard to run both Edge and Safari on the same setup.
> >
> > That said, at least https://jsperf.com/freeze-vs-seal-vs-normal/3 is
> being
> > completely optimized away in Firefox for all of the testcases.  Or at
> least
> > running at the same speed as
> > ; for some reason
> jsperf is
> > refusing to create a revision that has both the control and the actual
> > tests...
> >
> > -Boris
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allow any quoted string to be multiline?

[J Decker]

On Mon, Dec 18, 2017 at 3:08 AM, Claude Pache <claude.pa...@gmail.com>
wrote:

>
>
> > Le 17 déc. 2017 à 22:03, J Decker <d3c...@gmail.com> a écrit :
> >
> > I do see there are work-arounds (similar as using a hammer to put in a
> screw)
> >
> > I don't see a reason for why not allow multiline strings for other quote
> types.  I know... because people want more errors and to have their hand
> held to identify missing close quotes?  much like the desire to add types
> and type checking.
>
> Yes, you gave a valid reason just after having said you didn’t see a
> reason: transforming bugs (missing quote) into early errors, so that it is
> easier to debug...
>
> The obvious workaround, i.e. using a template literal without placeholder,
> doesn’t seems too heavy-weight; on the contrary, it is probably the
> lightest one can imagine.
>
>
It's not actually :) lightest I can imagine is to allow single and double
quoted strings to be multiline also.
I was considering this because of an issue on my extended json parser.
during development it simplified the code making a single path for
gathering a string that only had to check for closing quote or backslash.
having to test for 4 more characters was then 3x the work... so I just cut
out the extra work, since it break anything.  The only thing left was ...
that it didn't break anything if a newline was found.

So I figured I'd mention the possibility here and see how much push back I
got.  I don't actually think that 'protection from bad coding' is a very
strong argument.  there's lots of single character omissions or insertions
that can cause ghosted errors that aren't nearly so obvious.  Especially
since syntax highlighting would show a overflowing string very quickly
(more than missing a + in += or having a +  on an = that you didn't mean
for instance).  It would be a change that would take some time to propagate
to a lot of tools; but is a change that's entirely backward compatible and
breaks nothing from the past.




> —Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allow any quoted string to be multiline?

[J Decker]

re are line continuations. :)
>
> On Friday, December 15, 2017 2:48:00 PM CET Isiah Meadows wrote:
>
> There are ES5 newline escapes. However, it'd be nice if I didn't have
> to resort to templates just for multiline strings. Note: it wouldn't
> actually simplify parsing by much - either you're handling the case
> and remapping CR/CRLF to NL, or you're handling the case and throwing
> an error.
>
> ```js
> // ES5 escaped newlines
> 'a multi-\
> line string'
> ```
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
> On Fri, Dec 15, 2017 at 8:43 AM, J Decker <d3c...@gmail.com> wrote:
>
> If any string were allowed to be multi-line it would not break any
> existing
> code, and it would simplify parsing strings.
>
> 'a multi-
> line string'
>
> Maybe this is a question... why not allow line spanning with single and
> double quoted strings?
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Allow any quoted string to be multiline?

[J Decker]

If any string were allowed to be multi-line it would not break any existing
code, and it would simplify parsing strings.

'a multi-
line string'

Maybe this is a question... why not allow line spanning with single and
double quoted strings?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allow specify numbers with suffixes

[J Decker]

On Tue, Dec 12, 2017 at 1:24 PM, kai zhu  wrote:

>
> On Dec 13, 2017, at 2:15 AM, Sam Goto  wrote:
>
> + rick that co-authored numeric separators too and may have thoughts on
> this. my first impression is that this (if kept purely as something that
> gets ignored by the VMs) shares a lot of the sentiments with numeric
> separators ….
>
>
> -1
> the difference is that numeric-separators are well-defined and hopefully a
> one-time language-change that never has to be re-visited again.  these
> proposed numbers-with-suffixes are arbitrary and nobody is naive enough to
> believe they won’t be revisited repeatedly in the future.  they open a
> can-of-worms to never-ending future language-feature requests (like
> destructuring and import-statements did), which harms tooling and language
> stability.
>
>
My concern would be the non-symmetry/irreversability of this (can't get
out what you put in)
Factorio uses such suffixes in their mods but that's a total one-off.  I've
not seen real standards anywhere for this sort of thing in any language
generally.

B as an additional suffix to say base 2 is actually fairly arbitrary...
(although this page suggests such a thiing)
http://people.csail.mit.edu/jaffer/MIXF/MIXF-08 says only languages could
be extended, but has no examples of any language with support.

There's also no NPM for such a thing (if there is it's called something I
wouldn't think of)

https://www.npmjs.com/package/convert-units  (converts a value to another
value, and uses such metric suffixes, but only as strings to .from() and
.to() )

And these two that convert from a number to text, but not the other way
around...
https://www.npmjs.com/package/metric-suffix
https://www.npmjs.com/package/number-suffix

Even math heavy lanauages (mathematica/Wolfram, R, FORTRAN );  human
friendly lanaguages (BASIC, COBOL); and kid friendly  Scratch, et al. son't
have such support.

So I think someone should first implement it as a library/package (maybe
even going as far as to overload Number()/new Number() when converting
numbers...


> On Tue, Dec 12, 2017 at 11:13 AM, Sam Goto  wrote:
>
>> Ha, that's quite interesting.
>>
>> Somewhat related to the proposal of https://github.com/tc39/pro
>> posal-numeric-separator that we moved forward earlier this year.
>>
>> Are you thinking that the suffixes are purely ignored by VMs or that the
>> conversation is effectively done? That is, is "populationSize = 1M"
>> equivalent to "populationSize = 1" or does it make a translation somewhere
>> to "populationSize = 1_000_000"?
>>
>>
>>
>> On Sun, Nov 26, 2017 at 8:27 AM, Andrey Muzalevsky 
>> wrote:
>>
>>> Thank for your answers
>>>
>>> Jerry, I think that in tagged template literals form it won't be widely
>>> used
>>>  e.g. `setTimeout(foo, millis`30s`);` is much harder to read than 
>>> `setTimeout(foo,
>>> 3);`
>>>
>>> ---
>>>
>>> Regarding https://github.com/littledan/proposal-extensible-n
>>> umeric-literals:
>>>
>>> Doesn't conflict with this idea.
>>>
>>> Also looks great at first sight. BTW - In my personal opinion - in most
>>> cases number suffixes/literals/syntaxes are just sugar, and must be
>>> processed at compile-time (0xFF00 syntax is also just sugar).
>>> Also to make this proposal useful - JS also need to support operators
>>> overloading, without operator overloading do something useful while writing
>>> `10px + 1em` is impossible, so it decreases usability of this innovation to
>>> just another way of calling function(for now).
>>>
>>> So in my _personal_ opinion, for now it is better to stay with fixed
>>> list of built-in compile-time executed number suffixes/literals
>>>
>>> ---
>>>
>>> Regarding https://github.com/tc39/proposal-bigint
>>>
>>> The only problem between proposals is the suffix `n` which specifies
>>> 10^-9. Few thoughts:
>>>  - milli, nano, etc. suffixes won't be widely used
>>>  - they always can be replaced with expotential notation 1e-3, 1e-6, ...
>>>
>>> So they are removed from this idea,
>>> Also removed full form, as it doesn't look semantically valid
>>>
>>> Updated list of sugar suffixes:
>>>  - Usable list analogues of 1e3, 1e6, 1e9:
>>>  - 1K = 1000 = 1e3
>>>  - 1M = 1000*1000 = 1e6
>>>  - 1G = 1000*1000*1000 = 1e9
>>>  - ... (T,P,E,Z,Y)
>>>  - The same with bytes, nobody will count nanobytes... Isn't it? Usable
>>> list:
>>>  - 1KB = 1024
>>>  - 1MB = 1024*1024
>>>  - 1GB = 1024*1024*1024
>>>  - ... (TB,PB,EB,ZB,YB)
>>>  - Updated time group, this can make life easier for each novice...
>>>  - 1s = 1000
>>>  - 1m = 60s
>>>  - 1h = 60m
>>>  - 1d = 24h
>>>  - 1w = 7d
>>>
>>> How it looks for you with updates?
>>>
>>> Best regards,
>>>
>>> Andrey
>>>
>>> 2017-11-25 1:22 GMT+02:00 Jerry Schulteis :
>>>
 I see the BigInt proposal at the moment uses a suffix 'n' for BigInt
 literals.
 That would 

Re: A way to prevent properties to be added to an object if they are null or undefined.

[J Decker]

Or feed it through JSON.parse( JSON.strinigfy( o ) ) which will delete
undefined things; doesn't help with null.

On Tue, Nov 28, 2017 at 5:50 PM, Michał Wadas  wrote:

> You can just use proxy with proper set trap.
>
> On Wed, 29 Nov 2017 at 02:30, Rodrigo Carranza <
> rodrigocarra...@outlook.com> wrote:
>
>> A way to prevent properties to be added to an object if they are null or
>> undefined.
>>
>> Currently this can be accomplished in many ways:
>>
>> With an if:
>> ```js
>> function foo(couldBeNull){
>> let ret = {}
>> if(couldBeNull){
>> ret.couldBeNull = couldBeNull
>> }
>> return  ret
>> }
>> ```
>>
>> With ternary (kind of gross)
>> ```js
>> function foo(couldBeNull){
>> let ret = {}
>> couldBeNull ? (ret.couldBeNull = couldBeNull) : null
>> return  ret
>> }
>> ```
>>
>> Also gross
>> ```js
>> function foo(couldBeNull){
>> let ret = {}
>> couldBeNull && (ret.couldBeNull = couldBeNull)
>> return  ret
>> }
>> ```
>>
>> A bit hard to read:
>> ```js
>> function foo(couldBeNull){
>> let ret = {
>> ...({couldBeNull} : {})
>> }
>> return  ret
>> }
>> ```
>>
>> Requires importing a lib or writing the function by yourself. Also it has
>> to iterate over all values
>> ```js
>> function foo(couldBeNull){
>> let ret = {
>> couldBeNull
>> }
>> ret = removeEmptyValues(ret) // imported from some library
>> return  ret
>> }
>> ```
>>
>> Wouldn't it be better something like this?:
>>
>> ```js
>> function foo(couldBeNull){
>> let ret = {
>> couldBeNull?
>> }
>> return  ret
>> }
>> ```
>>
>> Or if you want to set other property name
>>
>> ```js
>> function foo(couldBeNull){
>> let ret = {
>> bar ?:  couldBeNull // bar is not added if couldBeNull is null or
>> undefined
>> }
>> return  ret
>> }
>> ```
>>
>>
>> 
>>  Libre
>> de virus. www.avast.com
>> 
>> <#m_1540481831920124741_m_-273853769969316494_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: javascript vision thing

[J Decker]

On Tue, Nov 28, 2017 at 6:19 AM, kai zhu  wrote:

> > On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
> > You mean, it's a tool to write computer instructions for taking input,
> manipulating it, and generating output? Breaking news: That's what all
> programming languages are.
>
> @T.J. the thing about javascript as a "tool mainly for baton-passing
> JSON-data around",
> is that unlike other programming languages that take generic io data,
>

javascript has grown to be a generally useful language; and indeed because
it had the ability to read generic IO data; maybe that's somewhat
incorrect... systems supporting javascript have been created that allow
generic IO.

NodeOS   https://node-os.com/
some really powerful fontend chosts - Electron and NWJS for instances (
above and beyond what a browser can do itself, or working standalone
without requiring passing batons to anyone)

3D and Vr programming https://webvr.info/  https://threejs.org/

I used it to create 100's of millions of bingo cards (would have been able
to do that faster if I had threads but broke it up into several processes
in parallel and managed it quite quickly) Those got output as a binary
format (also SQL and CSV flavors)

It even works well to add logic to GUI elements created outside of a
browser https://www.npmjs.com/package/sack.vfs#frame-methods

I do think you're looking at the world somewhat myopically or with a bit of
tunnel vision.

While true, classes don't help in basically any of those cases... and they
really tke javascript as just the pure functional language it started as (
just like it's C roots, which I found rather amused that Functional
Programming is this 'grand new thing that javascript does'

I would have used classes more, but since they encapsulate no data, I found
them more of a hinderance to develop since I had to do all the work in a
constructor/factory anyway the extra cryptic layer I find unnessecary.  If
it had supported data fields, I'd think there would be additional
performance benefits to having a full template, without having to adjust
underlaying tracking to add fields all the time.

>From long time in C, my development practice is always to create the data
structures I'm using and then create the functions to manipulate said
structures;  having functions first and nothing to operate on is kinda
useless... Javascript does such a habit a little harder to follow,
requiring a factory for the structure first  like these ...
https://github.com/mrdoob/three.js/tree/dev/src/math vectors, matrixes,
etc




> javascript oftentimes doesn't need a
> class-abstraction layer to parse the input, or serialilze to output,
> because they are already in JSON.
>
> i already demonstrated the feasibility of a non-trivial webapp
> that has no class-abstraction layer -
> it relies on static-functions instead to directly manipulate
> JSON/plain-text
> to/from io (aside from builtin classes like XMLHttpRequest that i have
> to use for ajax).
>
> showing you can efficiently manage javascript's JSON-focused io with
> static-functions and no class-abstraction layer then raises the
> question of the necessity of all the class-related tc39 proposals
> being considered.
>
> demo urls:
> 1. https://kaizhu256.github.io/node-swgg-google-maps/build..
> beta..travis-ci.org/app/#!swgg_id__2Fmaps_2Fapi_
> 2Fdirections_2Fjson_20GET_1
>
> 2. https://kaizhu256.github.io/node-swgg-wechat-pay/build..
> beta..travis-ci.org/app/#!swgg_id__2Fpay_2Fmicropay_20POST_1
>
>
>
>
> On 11/28/17, Naveen Chawla  wrote:
> > I oppose moderation. These views about ES, however misguided they might
> > seem, allow us to reaffirm the reasons why decisions were made and guide
> > those with similar views to the answers to their concerns. I don't see
> any
> > loss, only gain, in engaging these concerns.
> >
> > On Tue, 28 Nov 2017 at 13:46 James Kyle  wrote:
> >
> >> I don't understand what this thread is even trying to achieve.
> >>
> >> This mailing list should really just be shut down. The lack of
> moderation
> >> ruins it and it sucks having to subscribe to it for the occasional
> >> important/interesting information/discussion. I'd rather have that
> >> content
> >> moved to one of the other channels of communication which have been more
> >> successful.
> >>
> >> On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <
> >> tj.crow...@farsightsoftware.com> wrote:
> >>
> >>> On Tue, Nov 28, 2017 at 6:40 AM, kai zhu  wrote:
> >>> >
> >>> > if i were asked what the vision of javascript is my current
> >>> > answer would be:
> >>> > "javascript is a tool to take JSON-input, manipulate it, and
> >>> > output it back out (via DOM, event-handling, network-socket,
> >>> > file-io, or db-driver)."
> >>>
> >>> You mean, it's a tool to write computer instructions for taking input,
> >>> manipulating it, and generating output? Breaking news: That's 

Re: Shorthand for "function" keyword

[J Decker]

On Sun, Nov 12, 2017 at 2:14 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Sun, Nov 12, 2017 at 9:56 AM, J Decker <d3c...@gmail.com> wrote:
> > Arrow functions passed as callback to Node.js addons execute 20%
> > slower than regular 'function()' functions.
>
> **Wow**. Is that written up somewhere one could read more?
>
> When you say "Node.js addon," are you excluding built-in Node APIs?
>

Basically it was an empty function I was calling with some simple
parameters  It was only something I found through experimentation.  It
really has nothing to do with NodeJS other than it was an addon, it was
just interacting with the V8 engine.

Writing file...
Wrote in  199  .. reading...
()=>{} Read in ... 30 3394
function(){} Read in ... 30 2690

https://github.com/d3x0r/sack.vfs/blob/master/tests/largeStreamtest.js#L15
and line 18 is the other one.
In the function I just increment a counter  126% or 79.25%  ...but then
there is quite a bit of overhead in my library to parse the JSON. that's
quite a nested object
`{\"a${i}\":{\"b${i}\":{\"c${i}\":{\"d${i}\":123`
--
Hmm... changed the file that was being generated to just a simple string,
and the timings were closer (but was less than 1 second run) so I added
some generation counts and ran the tests in various orders... and I guess
maybe it was because of other factors that coincidentally showed as ()=>{}
being slower than function(){}

function(){} Read in ... 10 958
()=>{} Read in ... 10 906
()=>{} Read in ... 10 784
function(){} Read in ... 10 783
()=>{} Read in ... 10 924
function(){} Read in ... 10 779
function(){} Read in ... 10 881
()=>{} Read in ... 10 805

then just reversed the two tests in the original script and the timing
stayed the same in-order... but then would show function() as being the
slower one.

My Bad; thanx for asking about that though I would have been stuck with
that misconception for a long time.



> -- T.J. Crowder
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Shorthand for "function" keyword

[J Decker]

On Sun, Nov 12, 2017 at 1:11 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Sun, Nov 12, 2017 at 6:09 AM, Naveen Chawla
>  wrote:
> >
> > Who uses functions instead of arrow functions and methods these
> > days, anyway? (I know, people who haven't adopted ES2015+)
>

Arrow functions fail to convey 'this'  There is this library I'm using that
calls the callback with .call( instance, ... ) and an arrow function does
not get the instance handle.  I've tried to convince the library maintainer
to pass it as an argument rather than trying to encode it as this, so that
both old and new function styles can be used; but not with much success.

Arrow functions passed as callback to Node.js addons execute 20% slower
than regular 'function()' functions.

Can't say that javascript itself is any slower; but when interfacing to
native code they are slower..


>
> Laurentiu's been fairly clear about his/her use case: Named inline
> callbacks. I don't think he/she cares whether the functions are arrow
> functions, so long as they have names. (Laurentiu, correct me if I'm wrong
> there.) Right now, if you want to pass a *named* inline callback to
> something, the simplest way is to use the `function` keyword.
>
> (I don't agree with the suggestion, but he/she's been clear about it.)
>
> -- T.J. Crowder
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Can `new` be optional?

[J Decker]

On Sun, Nov 5, 2017 at 7:53 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> oldie but goldie ?
>
> ```js
> Object.defineProperty(
>   Function.prototype,
>   'new',
>   {
> configurable: true,
> value(...args) {
>   return new this(...args);
> }
>   }
> );
> ```
>
> doesn't make new optional, just moves it, and doesn't apply to 'class'es
which the OP is saying.


>
>
>
>
> On Sun, Nov 5, 2017 at 11:28 AM, Oriol _ 
> wrote:
>
>> > Why can't `new` be optional?
>>
>> When you call a function, you are using the internal [[Call]] method.
>> When you use the `new` operator, it's the internal [[Construct]] method.
>>
>> They are different things, so IMO avoiding `new` when you are
>> instantiating is bad practice.
>>
>>
Of course it is... with out new, classes throw an exception.

This seems like a really short sighted issue.  Why can't calling a class
just invoke it's constructor?

I also don't see how decorators can solve it.

Seems just as arbitrary as the underscore proposal not accepting underscore
trailing a number or before or after a decimal.

Maybe, it would be better to ask 'Why does calling a class throw an
exception instead of just creating a new instance.


> But if you really want to avoid `new` when using ES6 `class` syntax, you
>> can use proxies, e.g.
>>
>> ```js
>> let MyClass = new Proxy(class MyClass {
>>   constructor(arg) { this.arg = arg; }
>> }, {
>>   apply: (target, thisArg, args) => Reflect.construct(target, args)
>> });
>> MyClass(1); // { arg: 1 }
>> new MyClass(2); // { arg: 2 }
>> ```
>>
>
At the cost of non-zero overhead.


> --Oriol
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Break out of non-loops

[J Decker]

On Fri, Oct 27, 2017 at 8:47 AM, Sébastien Doeraene 
wrote:

> This is already possible:
>
> $ node
> > console.log('one'); *foo:* { console.log('two'); *break foo;*
> console.log('three'); }; console.log('four')
> one
> two
> four
>
>
probably just me, but this makes it very unobvious where the break goes
to... I'd rather see as a matter of style

console.log('one'); *do*{ console.log('two'); *break;* console.log('three');
}while(false); console.log('four')


but again; probably just my C basis.

Cheers,
> Sébastien
>
> On Fri, Oct 27, 2017 at 5:40 PM, Sebastian Malton 
> wrote:
>
>> Something that is very useful that was recently released into Rust was
>> the idea of using a break statement to break out of the current level. This
>> is already the case for loops but in Rust it was extended to all statements
>> encased in {}.
>>
>> This would make some code a lot easier to understand as it can eliminate
>> flag variables
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

How it feels to learn JavaScript in 2016

[J Decker]

(humor?)
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

It all seemed so simple
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[J Decker]

On Wed, Oct 25, 2017 at 4:57 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Tue, Oct 24, 2017 at 6:26 PM, dante federici
>  wrote:
> >
> > So, something like:
> > ```
> > myFn() {
> > }
> > ```
> >
> > Would be considered as:
> > ```
> > var myFn = function() {
> > }
> > ```
> >
> > with what semantics exist now. Not best practices, but what is
> > currently interpreted in the language.
>
> No, it isn't. It's a `SyntaxError: Unexpected token {`. There's a big
> difference between `myFn() { }` and `myFn = function() { };` The latter is
> valid syntax for the horror of implicit globals (in loose mode; strict mode
> fixed it). The former is just a syntax error. (It would be valid method
> syntax if it were inside an object initializer or `class`.)
>

ya this is not a syntax error.
myFn()
{
}


> But AFAIK, Brian Blakely wasn't promoting that syntax anyway. His original
> post only ever uses this shorthand with `export`, so I think it was meant
> to be specific to exporting.
>
> -- T.J. Crowder
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Compiled JS

[J Decker]

Each javascript engine uses different opcodes internally; there is no
universal bytecode like Java, C# or Vulkan.
using closure compiler or some other minification is the closest you can
come; short symbols are quicker to process.

Trying to learn how to do that for V8 Engine, it is possible to generate
precompiled javascript chunks and link them into the compiled product; but
it's not a universal solution, and, as far as I can tell, isn't even really
possible to do into dynamic libraries to add dynamically.


On Tue, Oct 24, 2017 at 10:48 PM, Peter Jaszkowiak 
wrote:

> Compiling JS into an intermediate representation like the JVM or LLVM
> isn't really possible because JavaScript is a dynamic language.
>
> That's my understanding anyways. The binary AST is as close as we can get.
>
> On Oct 24, 2017 23:43, "doodad-js Admin"  wrote:
>
>> No WASM/AST Don’t challenge my ignorance I’m basically suggesting
>> a way to compile:
>>
>>
>>
>> js
>>
>> const a = {};
>>
>> ```
>>
>>
>>
>> to opcodes, like:
>>
>>
>>
>> ```hex
>>
>> F10B6100
>>
>> ```
>>
>>
>>
>> *From:* Karl Cheng [mailto:qantas94he...@gmail.com]
>> *Sent:* Wednesday, October 25, 2017 12:57 AM
>> *To:* doodad-js Admin 
>> *Cc:* es-discuss 
>> *Subject:* Re: Compiled JS
>>
>>
>>
>> It seems that you're referring to something like WebAssembly
>>  or a binary AST
>> . Please check them out
>> and see if they're similar to what you're thinking of.
>>
>>
>>
>> On 25 October 2017 at 08:06, doodad-js Admin  wrote:
>>
>> Hi,
>>
>>
>>
>> By seeing many proposals about reducing the syntax for X and Y, I just
>> want to open the idea of a [non-native] compiled JS world. What do you
>> think?
>>
>>
>>
>> Because, if that’s not the problem (code size), what it is ?
>>
>>
>>
>> Claude Petit
>>
>>
>>
>>
>>
>>
>> 
>>
>> Virus-free. *www.avg.com*
>> 
>>
>>
>> ___
>> es-discuss mailing list
>> *es-discuss@mozilla.org*
>> *https://mail.mozilla.org/listinfo/es-discuss*
>> 
>>
>>
>>
>>
>> --
>> 
>>
>> - Karl Cheng (Qantas94Heavy)
>> 
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Math.minmax

[J Decker]

```js
const minMax = (arr=[]) => { if( arr.length==1 ) return [arr[0],arr[0]];
   const result=[Infinity, -Infinity];
   for( let i=0;i < arr.length;i++ ) {
  result[0] = arr[i] < result[0] ? arr[i]: ((result[1] = arr[i] >
result[1]? arr[i]: result[1]), result[0]) ;
   }
   return result;
}

Would be slightly faster to only do the max if it's not a min. Which fails
if there's only 1 number to compare.

On Mon, Oct 2, 2017 at 9:12 AM, Xavier Stouder  wrote:

> JDecker: Just added your solution on the benchmark, it beats every
> others solution and it's a elegant solution.
>
> Kai Zhu: We can't see the screenshot. But please take in consideration
> that it's been a long time that ECMAScript isn't only used in webapp,
> and that some of applications using it can eat more than a million
> numbers.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Math.minmax

[J Decker]

On Mon, Oct 2, 2017 at 8:49 AM, Xavier Stouder  wrote:

> No problem Boris, I edited this times a long time ago.
>
> Naveen, you missed he point. In fact, I just added your code the
> benchmark (link aboce) and it has catastrophic performances.
>

Ya, that's a lot of array creations, not to mention the callback in the
reduce()...

```js
const minMax = (arr=[]) => { let result=[Infinity, -Infinity]; for( let
i=0;i < arr.length;i++ ) {
  result[0] = Math.min(arr[i], result[0]);
  result[1] = Math.max(arr[i], result[1]);
 }
 return result;
}
```
although I suspect this will be faster...
```js
const minMax = (arr=[]) => { let result=[Infinity, -Infinity]; for( let
i=0;i < arr.length;i++ ) {
  result[0] = arr[i] < result[0] ? arr[i]:result[0];
  result[1] = arr[i] > result[1]? arr[i]: result[1];
 }
 return result;
}
```



> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[J Decker]

Within the context of an array or object definition I could see
implementing automatic commas between elements but not outside; think
the thread is straying a little from the original post (const isn't
available in either context).  But only between completed
expressions/function definitions.
It wouldn't be horribly hard to option that into my json-6 parsing... just
still don't really think I'm a fan anyway. (but that doesn't have to deal
with get/set/function definitions).

On Wed, Sep 13, 2017 at 8:22 AM, Boris Zbarsky  wrote:

> On 9/13/17 9:57 AM, Naveen Chawla wrote:
>
>> By this behaviour (a modification to the initial "complete statement
>> produces comma" version of this proposal), everything would work perfectly,
>> no?
>>
>
> If by "perfectly" you mean "have hard-to-predict somewhat nonlocal
> behavior that makes any code relying on this a hard-to-read footgun", then
> the answer might be "yes".  For pretty much any other definition of
> "perfectly", I'm fairly sure the answer is "no".
>
> Great to hear those counter-examples as I don't know enough about ASI,
>>
>
> Still in the context of ASI, here are some examples of why ASI is a bad
> idea:
>
> 1) What does this return?
>
>   function f() {
> return
> 5;
>   }
>
> 2) What does this alert?
>
>   var str = "hello";
>   var x = str
>   [x].forEach(() => alert(x))
>
> Now back to automatic comma insertion... In your example:
>
>   function doStuff(
>   x
>   y
>   z
>   ){
>   }
>
> if someone changes doStuff to take an array as the second arg and you
> modify the call as:
>
>   function doStuff(
>   x
>   [y]
>   z
>   ){
>   }
>
> suddenly you need to insert a comma after the "x" to preserve the right
> semantics, no?  This is not terribly intuitive or obvious.  It gets even
> worse in a situation like this:
>
>   function doStuff(
>   x
>   /* The next argument is an array for good reasons that we
>  will now expound on in a long comment, etc, etc */
>   [y]
>   ){
>   }
>
> Quick, tell me without testing this or looking at the spec for a while
> whether this is a valid call to doStuff, with one argument, or a syntax
> error that would trigger comma insertion.
>
> But more generally, if you just use your favorite search engine on the
> phrase "automatic semicolon insertion", you will get a slew of articles
> explaining the pitfalls.
>
>
> -Boris
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are objects values?

[J Decker]

note 1) 'pointer' and 'reference' are not synonymous.  Although they should
be, c++ and languages evolved from it have changed the definition such that
they are not.

Unfortunately; 'reference' when used by C++ people means a pointer to the
value being passed; but hides the details that it is a pointer by making
'.' operator behave like '->'.  transparently, and just setting 'a = new
thing()' actually be '(*a) = new thing()', again, transparently.

( I really wanted to use 'reference' in the place of 'pointer' at several
places in this; and have instead used 'pointer to a value' when I want to
say 'a reference of a value' which, since C++ does not mean the same thing
at all really)


there's a few good, diferent explanations of the terms but I'll add my own.
https://stackoverflow.com/questions/373419/whats-the-
difference-between-passing-by-reference-vs-passing-by-value



by there are really 3 options, pass by value, pass by reference, pass by
pointer; and in this case the world should not be so black and white.

any primitive value passes by value.  1, 2,3; "apple", "banana" null, etc.
 a copy of the value is passed to the called function.  Changing values
does not change the original value... if you add to a string the caller
does not get its string updated.

pass by pointer, a pointer to the value is passed.  Changing the pointer in
the callee does not change the caller's pointer.  changing the content of
what the pointer is pointing does change the content in the caller's
pointer.

pass by reference, setting a reference to a new value updates the (pointer)
in the caller.  In javascript there is no good way to pass by reference.
So given the choice of 'pass by value' or 'pass by reference' the only
choice is that javascript is always 'pass by value' because changing the
values that are passed do not change the caller's original variables.

Wish I had more knowledge of what sort of language background you have.

in C...

pass by value  ( A pretty obvious thing)
```
void f( int a ) {
a = 3;  // this does not change the caller's variable.
}
f( 86 );
```

pass by pointer
```
void f( int *a ) {
   (*a) = 5; // de'referenc'ing the pointer, allows changing the value in
the caller
a = (some other pointer to int); // this would not change the caller's
value.
}
int value = 3;
f(  );
```

pass by reference  (and this, being a double pointer might be tough to wrap
your head around)
```
void f( int **a ) {
(*a[0] ) = 5; // change the value in a
( *a ) = New( int ); // New being a macro that allocates a new int,
updates the 'reference' in caller.
   a = (some other change); // this is never reflected back to the caller.
}
int a = 5;
int *b = 
f(  ); // gives the function the ability to change the pointer that is b,
or the value a
```

In the third case the double-pointer is hidden in C++ so you never have the
choice to try and affect the local copy of the variable, and all changes
update the variables that the caller has passed.

-
in C# there is a parameter attribute 'ref' that you can pass pointers
values.
Structures are simple values like numbers, so if they are passed to a
function, they are copied so the callee's changes to the content of the
structures does not update in the caller.

(and this is not something javascript has, nor should have)
```
struct  Point { int x, int y };
Point p;

void byValue( p ) {
   p = new Point( 1,2 ); // updates to 'p' do not update the caller
   p.x = 44;  // updates to values in structures do not  update to the
caller
}
Point a = { 1, 3 };
byValue( a );
```
so in the previous case, since no changes to the arguments are given to the
caller, this is 'pass by value'


```
struct  Point { int x, int y };
Point p;

void byValue( Point ref p ) {
   p = new Point( 1,2 ); // updates to 'p' DO update the caller's variable
   p.x = 44;  // updates to values in structures DO update the caller's
values
}
Point a = { 1, 3 };
byValue( ref a );
```
in this case, a doesn't need to be allocated by the caller, and instead the
called function can create a new point, or update values in the referred to
pointer.  This is much more like C++ 'reference' in which there is no way
to make a change in the called function the does not update to the caller.

a class type in C# is passed by pointer (a copy of the pointer is passed)
but the contents of a class can update.  Although you can also use the
'ref' parameter argument to pass the pointer to the caller's class (hmm
pointer-value), so the callee can update the caller's class pointer.
 (there are no pointers in c# and a C# purist will flame me for saying so,
but I'm trying really hard to not use 'reference to a value; see note 1')
-

Java behaves a lot like C#; but doesn't have structure type to cloud the
issue.  Passing by reference allows the callee to update the caller's value
that references a class instance.  by normal calls in that regard are pass
by value, so changes to the argument value itself does not update 

Re: nits on BigInt Proposal

[J Decker]

On Fri, Aug 4, 2017 at 10:16 AM, Sebastian Malton <sebast...@malton.name>
wrote:

> I remember that was a proposal for operator overloading. Was it decided
> against? I think that packages could solve this and many other problems if
> there was overloading.
>
>
I looked through outstanding proposals and didn't see any regarding
operator overloading.  I'm personally not a fan of operator overloading,
although one can do clever things with abstract types like neurons and
neural meshes to use ( like building a merged input using N1 = N2+N3, it's
actually better to just use N1 = N2.Add( N3 ). which gives the ability to
add other parameters in the mix anyway)  I'm not even a fan of C++ function
overloading, but rather, when porting backward from C++ to C, using well
named functions for appropriate inputs turned out to be much better for
clarity and maintenance.

With such vehement opposition to transparent things like extending JSON to
support a wider range of valid inputs; or even adding an additional
namespace for a separate version that does, I don't see how this has made
it so far, which adds an entirely new type that is sort of like Numbers,
but really nothing at all like Numbers.


Sebastian
>
> *From:* d3c...@gmail.com
> *Sent:* August 4, 2017 12:20 PM
> *To:* es-discuss@mozilla.org
> *Subject:* Re: nits on BigInt Proposal
>
>
>
> On Fri, Aug 4, 2017 at 9:10 AM, J Decker <d3c...@gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 4, 2017 at 7:52 AM, kai zhu <kaizhu...@gmail.com> wrote:
>>
>>> looking at the use-cases for this feature @ https://github.com/tc39/prop
>>> osal-bigint#use-cases, i'm not convinced it improves everyday
>>> programming, or outweigh the benefit and simplicity having a single number
>>> type.
>>>
>>> my nits are:
>>>
>>> - will this break or complicate existing/future code that does typeof
>>> checks for numbers? what are the costs of retooling nodejs mongodb / mysql
>>> / etc drivers and the apps that use them?
>>>
>>
>> from what I interpret, it's not a number; it's a different type entirely,
>> and does not interop with existing numbers
>>
>>
>>> - how will JSON.parse and JSON.stringify deal with BigInt? the mentioned
>>> use-cases for wire-protocols, guids, timestamps, and fixed-point BigDecimal
>>> aren’t very useful if it can’t easily be serialized / deserialized across
>>> db / persistent storage
>>>
>>> Apparently it will tostring and require a reviver.
>>
>>
>>> - are there actual common algorithmic use-cases in frontend programming
>>> or nodejs apps that need arithmetic on integers greater than 52-bits?
>>> should that rather be the domain of webassembly?
>>>
>>>
>> it's definitely NOT a webassembly thing, because it's a high level
>> structure.
>>
>> It would simplify computing large factorials... instead of manually
>> chunking stuff to 5 decimal digits or 4 hex digits... not that it's much of
>> a use case...
>>
>> But; there's already a library for this https://www.npmjs.com/package/
>> bigint.  Why would this be something to add to the language any more
>> than extending JSON?
>>
>> Regarding currency manipulation; I don't see that as something that is as
>> useful on the client side as it is on a server side... so it doesn't really
>> need to be in every javascript implementation.
>>
>> And, it seems more like a way to get around no operator overloading, by
> saying 'this specific case warrants it' but not vectors or complex numbers.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: nits on BigInt Proposal

[J Decker]

On Fri, Aug 4, 2017 at 9:10 AM, J Decker <d3c...@gmail.com> wrote:

>
>
> On Fri, Aug 4, 2017 at 7:52 AM, kai zhu <kaizhu...@gmail.com> wrote:
>
>> looking at the use-cases for this feature @ https://github.com/tc39/prop
>> osal-bigint#use-cases, i'm not convinced it improves everyday
>> programming, or outweigh the benefit and simplicity having a single number
>> type.
>>
>> my nits are:
>>
>> - will this break or complicate existing/future code that does typeof
>> checks for numbers? what are the costs of retooling nodejs mongodb / mysql
>> / etc drivers and the apps that use them?
>>
>
> from what I interpret, it's not a number; it's a different type entirely,
> and does not interop with existing numbers
>
>
>> - how will JSON.parse and JSON.stringify deal with BigInt? the mentioned
>> use-cases for wire-protocols, guids, timestamps, and fixed-point BigDecimal
>> aren’t very useful if it can’t easily be serialized / deserialized across
>> db / persistent storage
>>
>> Apparently it will tostring and require a reviver.
>
>
>> - are there actual common algorithmic use-cases in frontend programming
>> or nodejs apps that need arithmetic on integers greater than 52-bits?
>> should that rather be the domain of webassembly?
>>
>>
> it's definitely NOT a webassembly thing, because it's a high level
> structure.
>
> It would simplify computing large factorials... instead of manually
> chunking stuff to 5 decimal digits or 4 hex digits... not that it's much of
> a use case...
>
> But; there's already a library for this https://www.npmjs.com/package/
> bigint.  Why would this be something to add to the language any more than
> extending JSON?
>
> Regarding currency manipulation; I don't see that as something that is as
> useful on the client side as it is on a server side... so it doesn't really
> need to be in every javascript implementation.
>
> And, it seems more like a way to get around no operator overloading, by
saying 'this specific case warrants it' but not vectors or complex numbers.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: nits on BigInt Proposal

[J Decker]

On Fri, Aug 4, 2017 at 7:52 AM, kai zhu  wrote:

> looking at the use-cases for this feature @ https://github.com/tc39/
> proposal-bigint#use-cases, i'm not convinced it improves everyday
> programming, or outweigh the benefit and simplicity having a single number
> type.
>
> my nits are:
>
> - will this break or complicate existing/future code that does typeof
> checks for numbers? what are the costs of retooling nodejs mongodb / mysql
> / etc drivers and the apps that use them?
>

from what I interpret, it's not a number; it's a different type entirely,
and does not interop with existing numbers


> - how will JSON.parse and JSON.stringify deal with BigInt? the mentioned
> use-cases for wire-protocols, guids, timestamps, and fixed-point BigDecimal
> aren’t very useful if it can’t easily be serialized / deserialized across
> db / persistent storage
>
> Apparently it will tostring and require a reviver.


> - are there actual common algorithmic use-cases in frontend programming or
> nodejs apps that need arithmetic on integers greater than 52-bits? should
> that rather be the domain of webassembly?
>
>
it's definitely NOT a webassembly thing, because it's a high level
structure.

It would simplify computing large factorials... instead of manually
chunking stuff to 5 decimal digits or 4 hex digits... not that it's much of
a use case...

But; there's already a library for this https://www.npmjs.com/package/bigint.
Why would this be something to add to the language any more than extending
JSON?

Regarding currency manipulation; I don't see that as something that is as
useful on the client side as it is on a server side... so it doesn't really
need to be in every javascript implementation.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Migrating to a better communication tool

[J Decker]

On Thu, Jul 27, 2017 at 11:58 AM, Brandon Andrews <
warcraftthre...@sbcglobal.net> wrote:

> Previous discussion:
>
> https://esdiscuss.org/topic/meta-proposal-switch-es-
> discuss-from-a-mailing-list-to-using-the-tc39-github-
> issue-tracker-for-discussion
>
> I argued there for using Github issues in the TC39 account and covered
> every concern brought up. I'll point out it's trivial to use github's API
> to convert all of the mailing list into individual issues.
>

How do I get all issues?

>
>
> Also I've noticed people don't know how mailing lists work. (This should
> be obvious glancing at any topic brought up). I regularly still get people
> sending me emails and they don't CC things correctly. If I would hazard a
> guess there has been hundreds of lost comments from people replying to the
> mailing list wrong.
>

sqlite fixed their list so it doesn't come in from X person and Y person
but only from the list so it only goes back to their list... sounds like a
configuration issue.

>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Sealed & Frozen Object/Array Syntax

[J Decker]

On Mon, Jul 17, 2017 at 2:19 AM, Michał Wadas  wrote:

> However there exists perfectly good solutions inside of JS with
> Object.seal & Object.freeze.
>
> Actually these solutions are very bad for immutable data structures,
> because creating deep copy of object on every modification cause very
>

If you're mutating an immutable object you're kinda breaking the rules and
it shouldn't have been immutable in the first place.


> significant overhead. This overhead can be significant even in optimized
> Haskell implementations (link
> ) and for imperative
> languages it's even worser.
>
> Immutable.js use many of tricks to avoid deep copying.
>
> On Mon, Jul 17, 2017 at 10:51 AM, Keith Cirkel <
> esdisc...@keithcirkel.co.uk> wrote:
>
>> As functional programming because more mainstream - developers are
>> leaning more and more on immutability - with tools like immutable.js.
>> However there exists perfectly good solutions inside of JS with Object.seal
>> & Object.freeze.
>>
>> I propose making a short syntax to allow for creating of sealed/frozen
>> objects that looks like this:
>>
>> ```js
>> {| foo: 1 |} // same as Object.seal({ foo: 1 })
>> {# foo: 1 #} // same as Object.freeze({ foo: 1 })
>>
>> [| 1, 2, 3 |] // same as Object.seal([ 1, 2, 3 ])
>> [# 1, 2, 3 #] // same as Object.freeze([ 1, 2, 3 ])
>>
>> // Deep frozen objects becomes a case of using frozen notation all the
>> way down:
>> {# foo: {# bar: 1 #} #} // same as Object.freeze({ foo: Object.freeze({
>> bar: 1 }) })
>> [# [# 1, 2 #], [# 3, 4 #] #] // same as Object.freeze([Object.freeze([1,2]),
>> Object.freeze([3, 4]])
>> ```
>>
>> This short syntax allows for a much more expressive way of
>> writing/reading sealed & frozen objects. I look forward to a discussion
>> about this.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Quoted map keys (was: Re: JSON5)

[J Decker]

On Sat, Jul 15, 2017 at 9:39 AM, Mike Samuel <mikesam...@gmail.com> wrote:

> There seem to be two separable concerns that keep coming up in this thread.
>
> 1. Increasing the value domain that can be serialized & deserialized
> easily to include e.g. undefined, NaNs, Infinities, dates, timestamps.
> 2. More human friendly syntax that is easily deserialized.
>
> Both can be done in library code.  A library of composable JSON replacers
> & revivers would extend the value domain.
> There are many candidates for the second but no consensus but many do have
> similar interface to revivers & replacers.
>
> How do people feel about this statement.
>

then JSON should be removed from the standard if it's supposed to be
external.


> "
> It's premature to standardize as part of ecmascript more than JSON now
> since there's no consensus but both replacer/revivers libraries and human
> friendlier syntax would be worth considering as long as the two play nicely
> together and are so widely used that its hard to imagine starting a large
> project without using either.
> "
>
> On Jul 14, 2017 7:46 PM, "J Decker" <d3c...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jul 14, 2017 at 9:39 AM, Dirk Pranke <dpra...@chromium.org>
>> wrote:
>>
>>> On Fri, Jul 14, 2017 at 6:37 AM, J Decker <d3c...@gmail.com> wrote:
>>>
>>>>
>>>> but; JSON5 is ES5 and will end up staying that way.   trailing commas
>>>> in arrays end up making if function diffferently that JS.
>>>>
>>>> So I forked it; and made JSON6 (npm json-6); not that anyone will use
>>>> it or even know about it.  Probably will end up adding a date format for
>>>> Date().toISOString() handling.  as JS implementation it's as fast as
>>>> Crockford's reference code with added features instead of half the speed
>>>> like JSON5; and as a native plugin is 2x as fast as that; have to dig into
>>>> JSON code in Node to see why it's soo fast (still 2.4x faster than my
>>>> native code).
>>>>
>>>
>>> What's the difference between JSON5 and JSON6, language-wise? The only
>>> thing that jumped out at me is support for empty commas ([1,,3])?
>>>
>>> Back-tick quoted strings (format template strings- without templating
>> features since it would be static data)  which allow just direct multi-line
>> strings.  Extended that (removed one break basically) so any quoted string
>> can contain binary \n and be multiline; added undefined keyword, .  And
>> it's 2x the speed of JSON5.
>>
>> In my C version I had originally tracked down Unicode character
>> defintions and got a list of all characters that are not
>> ID_Start/ID_Continue to cause errors on property names; didn't implement
>> that in javascript version, and since any property can be referenced with a
>> quoted name, doesn't really matter if there are 'bad' identifier
>> characters, the application just has to quote it to reference it; and it
>> doesn't matter on the object creation side; this then just requires quotes
>> for identifiers that have whitespace,quotes, colon, comma, '{','}','[', or
>> ']' in them. (hmm or '/' because of comments, would entertain '#' for
>> comments too)
>>
>> After posting this I've had a lot of insights on format exploitations
>> come to me that may or may not matter.  It definitely handles well
>> formatted json; and well formatted of its own dialect; just not sure if
>> there's edge cases that could require better error handling.
>> Needs to be revisited to change logging errors to throwing them.
>>
>>> -- Dirk
>>>
>>>
>>>>
>>>> On Fri, Jul 14, 2017 at 2:24 AM, Reinis Ivanovs <da...@untu.ms> wrote:
>>>>
>>>>> YAML is an alternative to JSON in that they're both data serialization
>>>>> formats. YAML lost out in this role to XML in the past, to JSON more
>>>>> recently, and will most likely lose to TOML as a config format (it being a
>>>>> special case of data serialization). YAML simply has a bloated spec with
>>>>> too many ways to do things and some misfeatures. It's a terse format, but
>>>>> at the cost of readability. Basically, there's a reason why YAML has been
>>>>> around for so long and has seen relatively limited adoption. Adding YAML 
>>>>> to
>>>>> JS is a poor idea.
>>>>>
>>>>> On Wed, Jul 12, 2017 at 11:42 PM, Carsten Bormann <c...@tzi.org>
>>>>> wrote:
&

Re: Quoted map keys (was: Re: JSON5)

[J Decker]

On Fri, Jul 14, 2017 at 9:39 AM, Dirk Pranke <dpra...@chromium.org> wrote:

> On Fri, Jul 14, 2017 at 6:37 AM, J Decker <d3c...@gmail.com> wrote:
>
>>
>> but; JSON5 is ES5 and will end up staying that way.   trailing commas in
>> arrays end up making if function diffferently that JS.
>>
>> So I forked it; and made JSON6 (npm json-6); not that anyone will use it
>> or even know about it.  Probably will end up adding a date format for
>> Date().toISOString() handling.  as JS implementation it's as fast as
>> Crockford's reference code with added features instead of half the speed
>> like JSON5; and as a native plugin is 2x as fast as that; have to dig into
>> JSON code in Node to see why it's soo fast (still 2.4x faster than my
>> native code).
>>
>
> What's the difference between JSON5 and JSON6, language-wise? The only
> thing that jumped out at me is support for empty commas ([1,,3])?
>
> Back-tick quoted strings (format template strings- without templating
features since it would be static data)  which allow just direct multi-line
strings.  Extended that (removed one break basically) so any quoted string
can contain binary \n and be multiline; added undefined keyword, .  And
it's 2x the speed of JSON5.

In my C version I had originally tracked down Unicode character defintions
and got a list of all characters that are not ID_Start/ID_Continue to cause
errors on property names; didn't implement that in javascript version, and
since any property can be referenced with a quoted name, doesn't really
matter if there are 'bad' identifier characters, the application just has
to quote it to reference it; and it doesn't matter on the object creation
side; this then just requires quotes for identifiers that have
whitespace,quotes, colon, comma, '{','}','[', or ']' in them. (hmm or '/'
because of comments, would entertain '#' for comments too)

After posting this I've had a lot of insights on format exploitations come
to me that may or may not matter.  It definitely handles well formatted
json; and well formatted of its own dialect; just not sure if there's edge
cases that could require better error handling.
Needs to be revisited to change logging errors to throwing them.

> -- Dirk
>
>
>>
>> On Fri, Jul 14, 2017 at 2:24 AM, Reinis Ivanovs <da...@untu.ms> wrote:
>>
>>> YAML is an alternative to JSON in that they're both data serialization
>>> formats. YAML lost out in this role to XML in the past, to JSON more
>>> recently, and will most likely lose to TOML as a config format (it being a
>>> special case of data serialization). YAML simply has a bloated spec with
>>> too many ways to do things and some misfeatures. It's a terse format, but
>>> at the cost of readability. Basically, there's a reason why YAML has been
>>> around for so long and has seen relatively limited adoption. Adding YAML to
>>> JS is a poor idea.
>>>
>>> On Wed, Jul 12, 2017 at 11:42 PM, Carsten Bormann <c...@tzi.org> wrote:
>>>
>>>>
>>>> > On Jul 12, 2017, at 22:20, Reinis Ivanovs <da...@untu.ms> wrote:
>>>> >
>>>> > YAML is not a viable alternative to JSON for these reasons and more:
>>>> https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html
>>>>
>>>> YAML isn’t an alternative to JSON, it is a superset of JSON that is
>>>> useful for humans to use.
>>>> I’m not saying it is perfect; it is out there and well-implemented, and
>>>> any new effort would take a long time to be as useful.  It can also do a
>>>> lot more than JSON can do, things you don’t have a need for.  Right now.
>>>>
>>>> (I’m not going to spend time on commenting on the article you cite —
>>>> lots of valid observations, mixed with a lack of knowledge how to work with
>>>> these traits.  I wonder what would happen if the authors of these lines
>>>> would ever get hold of a JavaScript language spec :-)
>>>>
>>>> > TOML is what's needed, and it would also avoid a JSON/JSON5 confusion.
>>>>
>>>> TOML is pretty much the only format in the general vicinity of JSON
>>>> that is starting to get as widely used as YAML already has been for a
>>>> decade or so.
>>>> It plays well with the tastes of people who have been weaned on Windows
>>>> .INI files.
>>>> It also has some nice ways to flatten out overly complex structure.
>>>> It is not a superset of JSON, though, so it is kind of off-topic for
>>>> the current conversation.
>>>>
>>>> (I wouldn’t mind getting nativ

Re: Quoted map keys (was: Re: JSON5)

[J Decker]

TOML is just INI format.  It doesn't even support nesting objects very
well. If that was so great, it wouldn't have been replaced since the 90's.
  YAML with required spaces and newlines doesn't make a very good format
for protocol and interchange.  Neither are > JSON.

but; JSON5 is ES5 and will end up staying that way.   trailing commas in
arrays end up making if function diffferently that JS.

So I forked it; and made JSON6 (npm json-6); not that anyone will use it or
even know about it.  Probably will end up adding a date format for
Date().toISOString() handling.  as JS implementation it's as fast as
Crockford's reference code with added features instead of half the speed
like JSON5; and as a native plugin is 2x as fast as that; have to dig into
JSON code in Node to see why it's soo fast (still 2.4x faster than my
native code).

On Fri, Jul 14, 2017 at 2:24 AM, Reinis Ivanovs  wrote:

> YAML is an alternative to JSON in that they're both data serialization
> formats. YAML lost out in this role to XML in the past, to JSON more
> recently, and will most likely lose to TOML as a config format (it being a
> special case of data serialization). YAML simply has a bloated spec with
> too many ways to do things and some misfeatures. It's a terse format, but
> at the cost of readability. Basically, there's a reason why YAML has been
> around for so long and has seen relatively limited adoption. Adding YAML to
> JS is a poor idea.
>
> On Wed, Jul 12, 2017 at 11:42 PM, Carsten Bormann  wrote:
>
>>
>> > On Jul 12, 2017, at 22:20, Reinis Ivanovs  wrote:
>> >
>> > YAML is not a viable alternative to JSON for these reasons and more:
>> https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html
>>
>> YAML isn’t an alternative to JSON, it is a superset of JSON that is
>> useful for humans to use.
>> I’m not saying it is perfect; it is out there and well-implemented, and
>> any new effort would take a long time to be as useful.  It can also do a
>> lot more than JSON can do, things you don’t have a need for.  Right now.
>>
>> (I’m not going to spend time on commenting on the article you cite — lots
>> of valid observations, mixed with a lack of knowledge how to work with
>> these traits.  I wonder what would happen if the authors of these lines
>> would ever get hold of a JavaScript language spec :-)
>>
>> > TOML is what's needed, and it would also avoid a JSON/JSON5 confusion.
>>
>> TOML is pretty much the only format in the general vicinity of JSON that
>> is starting to get as widely used as YAML already has been for a decade or
>> so.
>> It plays well with the tastes of people who have been weaned on Windows
>> .INI files.
>> It also has some nice ways to flatten out overly complex structure.
>> It is not a superset of JSON, though, so it is kind of off-topic for the
>> current conversation.
>>
>> (I wouldn’t mind getting native support for both YAML and TOML in a
>> future JavaScript; everyone to their taste.)
>>
>> Grüße, Carsten
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Quoted map keys (was: Re: JSON5)

[J Decker]

I didn't get that mail at all; I assume it was a mistaken private response?

On Tue, Jul 11, 2017 at 10:23 PM, Don Griffin <d...@sencha.com> wrote:

> ​I don't think your "DO NOT USE JSON ... FOR HUMAN INPUT" notion was
> noticed by ... anyone really :)​
>
> Node.js has package.json, other package managers use component.json,
> editors use settings.json and some even throw that file in to a text editor
> as the configuration UI. AFAICT this whole notion of making JSON more like
> JavaScript object notation is because human's do interact with JSON quite
> often and want some of the little creature comforts.
>
> JSON5 may be overkill, but it seem unquoted keys and comments (and real
> dates) would be welcome by us unfortunate humans. :)
>
>
>
>
> Best,
> Don
> --
> Don Griffin
> Sr Director of Engineering
> Sencha, Inc.
> https://www.sencha.com/
>
> On Mon, Jul 10, 2017 at 11:33 PM, Carsten Bormann <c...@tzi.org> wrote:
>
>> On Jul 11, 2017, at 06:14, J Decker <d3c...@gmail.com> wrote:
>> >
>> > Why does JSON have quoted field names anyway (which I could understand
>> if they included spaced).
>>
>> Douglas Crockford has explained this bit of history in talks about JSON:
>>
>> Originally, they weren’t quoting map keys (names of object members) if
>> they looked like identifiers in JavaScript.  (In early JavaScript-based
>> implementations, JSON data was directly fed as code into the JavaScript
>> interpreter so there was no need to write a decoder.)
>>
>> But then some application was using “do” as a map key.  “do” happens to
>> be a reserved word in JavaScript, breaking the decoding process.  So they
>> had to check if the map keys were reserved words and quote them in that
>> case.  That set then would have to become part of the JSON
>
> I see.  keywords in that direction.


> specification.  Worse, the set of reserved word in JavaScript could
>> (theoretically) change, so either the JSON specification would need to
>> change, too, or the next version of JavaScript would no longer support
>> direct use of JSON as JavaScript code.
>>
>> So they decided to simply always quote, and that was that.
>>
>> The approach to execute JSON as JavaScript code of course is history now,
>> but JSON hasn’t changed back.
>>
>> Actually, with RFC 7159 and ECMA 404 out and JSON very widely
>> implemented, any proposal to change the JSON syntax is a complete
>> non-starter.
>>
>
I'm not proposing any change; I was proposing another facility JSON5 in
parallel to the existing JSON.  Although JSON5 being a superset of JSON and
there not being any immediate issue with using JSON with JSON5, except it
would be impossible to knowing whether a platform actually has JSON5
support in 'JSON' namespace.  It would be much more clear if it was in a
separate namespace entirely.
but all of that is about parse(); on the side of stringify, if the JSON
original was changed, it would start generating invalid output that
existing JSON readers would not work with, sounds like a bad plan also.

Well it appears JSON5 is trying to stay at ES5 level (some sort of matching
identifier there) and as such won't support `(back-tick) quoted strings.

So I don't care so much.

and I don't think tail commas in arrays don't behave correctly.

>
>> (Most of these proposals come from people who notice that JSON is bad for
>> conversing about data or for human input.  Well, that is not what JSON is
>> meant for.  DO NOT USE JSON FOR CONVERSING ABOUT DATA OR FOR HUMAN INPUT.
>> JSON is an interchange format.  There are much better formats for humans
>> inputting and conversing about JSON-modeled data, such as YAML, which is
>> even a superset of JSON.  No point in messing around with JSON if the
>> problem has already been solved.)
>>
>> Of course, if saving bytes is your objective, you might want to look at
>> CBOR.  I wonder when that is picked up by the JavaScript spec (there are
>> libraries, of course).
>>
>> Grüße, Carsten
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON5

[J Decker]

(combined a couple messages...)
On Tue, Jul 11, 2017 at 6:12 AM, Mike Samuel  wrote:
>> Why does JSON have quoted field names anyway (which I could understand if
>> they included spaced).

>To avoid intersecting the reserved identifier set in languages that
>wanted to provide a JSON-like syntax for producing values that
>serialize to JSON.

that justification makes no sense; 'serialize to json' kinda voids any
keyword argument; although, I vaguely remember a mention that crockford had
some single regex expression that could parse json simply, so maybe it's
part of that.




(fixed error handling escaped quotes in strings that was causing mine to
crash; so throwing in C++ Node Addon)

delta JSON(c): 2929
delta JSON5: 4632
delta JSON: 683
delta JSON(svfs): 1640  (before JSON5 extension)

delta JSON(c): 2891
delta JSON5: 4581
delta JSON: 647
delta JSON(svfs): 1631 (before JSON5 extension)

delta JSON(c): 2859
delta JSON5: 4483
delta JSON: 642
delta JSON(svfs): 1764 (after JSON5 extension)

delta JSON(c): 2860
delta JSON5: 4536
delta JSON: 641
delta JSON(svfs): 1762 (after JSON5 extension)

native code 2.5x faster than JSON5 and 1.62x faster than crockford
reference code.

what's going to be in the browser is going to be more like the Node
internal than any of the JS versions or my C++ Node.  addon version.


8% loss in mine; separated the test to test just native code, same test is
761ms; so think most of my loss is in the handoff between node and my
addon.



> 1.57 times slower than crockford reference code.
> 7.32 times as slow as JSON.parse()
>
>
> 

it's obvious(to me anyway) that having a javascript version of either
(reference code) or JSON5 is going to be slower than a builtin facility.
Even a node Addon isn't really that effective, losing half the time just in
interchanging between V8 and the outside world.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON5

[J Decker]

On Tue, Jul 11, 2017 at 3:48 AM, kai zhu <kaizhu...@gmail.com> wrote:

> any significant degradation in json parsing-performance would impact the
> world wide web.  can anyone knowledgeable on js engines comment on parsing
> performance?
>
I wouldn't expect to replace JSON.xxx but rather add JSON5.xxx for those
that require absolute speed over maintainability/flexibility.

that said...

it's based on crockford's original

https://github.com/douglascrockford/JSON-js/blob/master/json_parse.js

and comparting with
https://github.com/json5/json5/blob/master/lib/json5.js

it's essentialy the same (err maybe not; a diff shows lots of diff)

--
I found some test data
https://github.com/RichardHightower/json-parsers-benchmark
in data there's a handful of JSON files; I loaded these all into an array
of strings and data.forEach( data=>.parse(data ) );

50 iterations took

JSON(crockford ref): 2971ms
JSON5: 4688ms
JSON: 644ms

63.37% the speed of crockford refernce code (not quite half the speed)
13.7% the speed of Node's native JSON.parse().
-or-
1.57 times slower than crockford reference code.
7.32 times as slow as JSON.parse()


my own native code parser addon was about 1/2 as fast as node's, so I
didn't flesh mine out to a great extent; but the modifications required to
go from supporting no-quotes, single-or double quotes, comments, line
continuation, Infinity/NaN values really shouldn't slow it down that much;
 (mine dies on the test data; so that's a thing for another day; and will
be hard to tell JSON vs JSON5 because It won't do JSON only anymore (maybe)
).




> On Jul 11, 2017 15:39, "Dong Nguyen" <ndaid...@gmail.com> wrote:
>
>> @Jordan: I think that's just work-around, not official feature.
>>
>> Dong
>>
>> On Tue, Jul 11, 2017 at 12:31 PM, Jordan Harband <ljh...@gmail.com>
>> wrote:
>>
>>> JSON already has comments:
>>>
>>> ```json
>>> {
>>>   "foo": "the 'foo' field is for putting important stuff!",
>>>   "foo": "the real value for 'foo'"
>>> }
>>> ```
>>>
>>> On Mon, Jul 10, 2017 at 10:16 PM, Don Griffin <d...@sencha.com> wrote:
>>>
>>>> Seems like whitespace stripping is more of a serialization concern...
>>>> and hence comments are moot.
>>>>
>>>> Where comments are needed (and single line ones are handy) is human
>>>> edited JSON and also not likely to be stripped.
>>>>
>>>> Just my $2e-02
>>>>
>>>> Best,
>>>> Don
>>>> --
>>>> Don Griffin
>>>> Sr Director of Engineering
>>>> Sencha, Inc.
>>>> https://www.sencha.com/
>>>>
>>>> On Tue, Jul 11, 2017 at 12:13 AM, Ryan Birmingham <
>>>> rainventi...@gmail.com> wrote:
>>>>
>>>>> I believe that that's a reasonable solution, Sebastian.
>>>>>
>>>>> -Ryan Birmingham
>>>>>
>>>>> On 11 July 2017 at 01:12, Sebastian Malton <sebast...@malton.name>
>>>>> wrote:
>>>>>
>>>>>> If that is a concern then allow C-style block comments or some other
>>>>>> style of block comments
>>>>>>
>>>>>> Sebastian
>>>>>>
>>>>>> *From:* rainventi...@gmail.com
>>>>>> *Sent:* July 11, 2017 1:04 AM
>>>>>> *To:* ndaid...@gmail.com
>>>>>> *Cc:* es-discuss@mozilla.org
>>>>>> *Subject:* Re: JSON5
>>>>>>
>>>>>> My concern with single-lined comments is that json is often
>>>>>> whitespace removed.
>>>>>>
>>>>>> -Ryan Birmingham
>>>>>>
>>>>>> On 11 July 2017 at 00:48, Dong Nguyen <ndaid...@gmail.com> wrote:
>>>>>>
>>>>>>> Personally, I appreciate this idea. That's exactly how JSON should
>>>>>>> work. Sometimes I feel bad with current JSON specs: no comment, no 
>>>>>>> trailing
>>>>>>> commas, double quotes, etc.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Dong
>>>>>>>
>>>>>>> On Tue, Jul 11, 2017 at 11:14 AM, J Decker <d3c...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Since JSON is apparently part of the standard now, can JSON5 maybe
>>>>>>>> be considered for addition?  It's a very slight change, and simplifies
>>>>>>>> conversions.
>>>>>>>>
>>>>>>>>
>>>>>>>> Why does JSON have quoted field names anyway (which I could
>>>>>>>> understand if they included spaced).
>>>>>>>>
>>>>>>>> I searched archives and only came up with this result
>>>>>>>>
>>>>>>>> https://mail.mozilla.org/pipermail/es-discuss/2012-August/02
>>>>>>>> 4479.html
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/json5/json5
>>>>>>>>
>>>>>>>> https://github.com/json5/json5/blob/master/lib/json5.js
>>>>>>>>
>>>>>>>> (although I would like to see the keyword 'undefined' also allowed
>>>>>>>> as a value) which is just an 8 line addition.
>>>>>>>>
>>>>>>>> Comments in JSON?  Wonderful!
>>>>>>>> Unquoted field names? Wonderful!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON5

[J Decker]

On Mon, Jul 10, 2017 at 10:04 PM, Ryan Birmingham <rainventi...@gmail.com>
wrote:

> My concern with single-lined comments is that json is often whitespace
> removed.
>
> -Ryan Birmingham
>
> On 11 July 2017 at 00:48, Dong Nguyen <ndaid...@gmail.com> wrote:
>
>> Personally, I appreciate this idea. That's exactly how JSON should work.
>> Sometimes I feel bad with current JSON specs: no comment, no trailing
>> commas, double quotes, etc.
>>
>>
their quoted line continuations kinda bother me too... they say just escape
the end... but then that's
\  \r \n  -or- just \ \n   and if the \r is just a whitespace it should
silently be ignored or something anyway

but ya, I can see single line comments being an issue depending on the
parser too.



> Regards,
>> Dong
>>
>> On Tue, Jul 11, 2017 at 11:14 AM, J Decker <d3c...@gmail.com> wrote:
>>
>>> Since JSON is apparently part of the standard now, can JSON5 maybe be
>>> considered for addition?  It's a very slight change, and simplifies
>>> conversions.
>>>
>>>
>>> Why does JSON have quoted field names anyway (which I could understand
>>> if they included spaced).
>>>
>>> I searched archives and only came up with this result
>>>
>>> https://mail.mozilla.org/pipermail/es-discuss/2012-August/024479.html
>>>
>>>
>>> https://github.com/json5/json5
>>>
>>> https://github.com/json5/json5/blob/master/lib/json5.js
>>>
>>> (although I would like to see the keyword 'undefined' also allowed as a
>>> value) which is just an 8 line addition.
>>>
>>> Comments in JSON?  Wonderful!
>>> Unquoted field names? Wonderful!
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>> Dong Nguyen at* Green Global <http://greenglobal.vn/>*
>>
>> *tweet* me <https://twitter.com/ndaidong>
>> *plus* me <https://www.google.com/+DongNguyenbellajs>
>> *git* me <https://github.com/dongnd>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

JSON5

[J Decker]

Since JSON is apparently part of the standard now, can JSON5 maybe be
considered for addition?  It's a very slight change, and simplifies
conversions.


Why does JSON have quoted field names anyway (which I could understand if
they included spaced).

I searched archives and only came up with this result

https://mail.mozilla.org/pipermail/es-discuss/2012-August/024479.html


https://github.com/json5/json5

https://github.com/json5/json5/blob/master/lib/json5.js

(although I would like to see the keyword 'undefined' also allowed as a
value) which is just an 8 line addition.

Comments in JSON?  Wonderful!
Unquoted field names? Wonderful!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Syntax for non-writability and non-configurability

[J Decker]

https://esdiscuss.org/topic/wiki-ecmascript-org

wiki.ecmascript.org hasn't been up for 2 years?  when I ping it I get no
address (v4 or v6)

On Sat, Jul 8, 2017 at 10:18 AM, Allen Wirfs-Brock 
wrote:

> Note that something similar was given serious consideration by TC39 for
> ES6 but was ultimately being rejected: http://wiki.
> ecmascript.org/doku.php?id=harmony:concise_object_literal_extensions
>
> You can probably find relevant discussions in the es-discuss archive and
> TC39 notes.
>
> Allen
>
>
>
>
>
> On Jul 8, 2017, at 12:09 AM, Raul-Sebastian Mihăilă <
> raul.miha...@gmail.com> wrote:
>
> I'd like to propose the following syntax:
>
> ```js
> const obj = {
>   x:| 3, // non-writable property with value 3
>   y:] 4, // non-configurable property with value 4
>   z:} 5 // non-writable non-configurable property with value 5
> };
> ```
>
> Perhaps class fields could also use this syntax. Maybe decorators can take
> care of this but should you really need to use a decorator for something so
> basic?
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: InterleavedTypedArray type

[J Decker]

On Mon, Jul 3, 2017 at 11:10 AM, Steve Fink <sph...@gmail.com> wrote:

> On 07/02/2017 11:20 AM, Lars Hansen wrote:
>
> On Sun, Jul 2, 2017 at 9:12 AM, J Decker <d3c...@gmail.com> wrote:
>
>>
>>
>> On Sun, Jul 2, 2017 at 8:25 AM, Lars Hansen <lhan...@mozilla.com> wrote:
>>
>>> The TypedObjects proposal does this, for what it calls non-opaque types
>>> (you can define types and then map them onto an ArrayBuffer in various
>>> ways).  I'm not 100% sure what the latest text is, I expect it is here:
>>> https://github.com/tschneidereit/typed-objects-explainer but it could
>>> also be here: https://github.com/nikomatsakis/typed-objects-explainer.
>>>
>>>
>> That's about a single structure; as is the thing Isiah suggested
>> (ref-struct) and not an array of packed structures such as would be used
>> for interleaved vertex data.
>>
>
> ​No, the TypedObjects proposal allows for packed arrays of structures,
> without references.  See https://github.com/tschneidereit/typed-objects-
> explainer/blob/master/core.md#struct-arrays.
>
> --lars​
>
>>
>>
>>> TypedObjects is currently a stalled proposal.  I expect it may be
>>> revived when WebAssembly integration into JS becomes a more seriously
>>> discussed topic.
>>>
>>>
> TypedObjects are exactly what you want for this sort of use case, and are
> really quite nice. I'm no expert, but TypedArrays probably ought to be
> subsumed by the TypedObject spec since AFAICT they are a proper subset of
> TypedObject arrays, at least for practical purposes.
>
>
Yes; I read the proposal more and found that unfortunately the typed
objects are padded.
https://github.com/tschneidereit/typed-objects-explainer/blob/master/core.md#alignment-and-padding-examples
and there's no way to specify unpadded.  (although optimal vertex buffers
should be arranged so multibyte members are aligned)





> Spidermonkey has had them implemented since sometime in 2013, though we
> haven't used them much and the constructors are of course not exposed to
> the Web. (And the implementation of TypedArrays is still separate, and has
> better JIT support.) They're really quite nice when you have the sorts of
> problems they're meant for. For other problems, I would guess they would be
> quite an attractive nuisance. ;-)
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: InterleavedTypedArray type

[J Decker]

On Sun, Jul 2, 2017 at 8:25 AM, Lars Hansen <lhan...@mozilla.com> wrote:

> The TypedObjects proposal does this, for what it calls non-opaque types
> (you can define types and then map them onto an ArrayBuffer in various
> ways).  I'm not 100% sure what the latest text is, I expect it is here:
> https://github.com/tschneidereit/typed-objects-explainer but it could
> also be here: https://github.com/nikomatsakis/typed-objects-explainer.
>
>
That's about a single structure; as is the thing Isiah suggested
(ref-struct) and not an array of packed structures such as would be used
for interleaved vertex data.


> TypedObjects is currently a stalled proposal.  I expect it may be revived
> when WebAssembly integration into JS becomes a more seriously discussed
> topic.
>
> --lars
>
> On Sun, Jul 2, 2017 at 6:53 AM, J Decker <d3c...@gmail.com> wrote:
>
>>
>> On Sun, Jul 2, 2017 at 6:50 AM, Isiah Meadows <isiahmead...@gmail.com>
>> wrote:
>>
>>> I'm not sure this belongs in the spec.
>>
>>
>> Typed arrays are in the spec
>> http://www.ecma-international.org/ecma-262/6.0/#sec-typedarray-objects
>>
>>
>>> There exists a similar thing on
>>> npm [1] which deals with Buffers instead, but you could adapt it
>>> similarly to work with ArrayBuffers (via a DataView). In reality, this
>>> really only would have two uses: native C interop (in Node/etc.) and
>>> WebAssembly interop (which is better addressed by separate
>>> `foo_create` and `foo_destroy` exports with raw pointers and creating
>>> a JS wrapper to manage them more idiomatically).
>>>
>>> [1]: https://www.npmjs.com/package/ref-struct
>>> -----
>>>
>>> Isiah Meadows
>>> m...@isiahmeadows.com
>>>
>>> Looking for web consulting? Or a new website?
>>> Send me an email and we can get started.
>>> www.isiahmeadows.com
>>>
>>>
>>> On Sun, Jul 2, 2017 at 9:42 AM, J Decker <d3c...@gmail.com> wrote:
>>> >
>>> > I would like to open a discussion to propose that an extension to
>>> > http://www.ecma-international.org/ecma-262/6.0/#sec-typedarray-objects
>>> > should be defined that would allow defintiion of interleaved typed
>>> data.
>>> >
>>> > Support for interleaved vertex data is one use...
>>> >
>>> > https://developer.apple.com/library/content/documentation/3D
>>> Drawing/Conceptual/OpenGLES_ProgrammingGuide/TechniquesforWo
>>> rkingwithVertexData/TechniquesforWorkingwithVertexData.html
>>> >  section Use Interleaved Vertex Data
>>> >
>>> >
>>> > https://www.khronos.org/opengl/wiki/Vertex_Specification
>>> > Defines how OpenGL describes interleaved data.
>>> >
>>> > This could also be used to interop with native code as an array of
>>> packed
>>> > (C) structs.
>>> >
>>> > I don't really know what the definition mechanics might be, but for
>>> usage I
>>> > might like to see...
>>> >
>>> > var arr = new InterleavedTypeArray( [ { name: "fieldName",
>>> type:"uint32' },
>>> > ... probably an array of objects defining the fields in an element ],
>>> >  );
>>> >
>>> > arr[x].fieldName = value.
>>> >
>>> >
>>> >
>>> > ___
>>> > es-discuss mailing list
>>> > es-discuss@mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: InterleavedTypedArray type

[J Decker]

On Sun, Jul 2, 2017 at 6:50 AM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

> I'm not sure this belongs in the spec.


Typed arrays are in the spec
http://www.ecma-international.org/ecma-262/6.0/#sec-typedarray-objects


> There exists a similar thing on
> npm [1] which deals with Buffers instead, but you could adapt it
> similarly to work with ArrayBuffers (via a DataView). In reality, this
> really only would have two uses: native C interop (in Node/etc.) and
> WebAssembly interop (which is better addressed by separate
> `foo_create` and `foo_destroy` exports with raw pointers and creating
> a JS wrapper to manage them more idiomatically).
>
> [1]: https://www.npmjs.com/package/ref-struct
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Sun, Jul 2, 2017 at 9:42 AM, J Decker <d3c...@gmail.com> wrote:
> >
> > I would like to open a discussion to propose that an extension to
> > http://www.ecma-international.org/ecma-262/6.0/#sec-typedarray-objects
> > should be defined that would allow defintiion of interleaved typed data.
> >
> > Support for interleaved vertex data is one use...
> >
> > https://developer.apple.com/library/content/documentation/
> 3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/
> TechniquesforWorkingwithVertexData/TechniquesforWorkingwithVertexData.html
> >  section Use Interleaved Vertex Data
> >
> >
> > https://www.khronos.org/opengl/wiki/Vertex_Specification
> > Defines how OpenGL describes interleaved data.
> >
> > This could also be used to interop with native code as an array of packed
> > (C) structs.
> >
> > I don't really know what the definition mechanics might be, but for
> usage I
> > might like to see...
> >
> > var arr = new InterleavedTypeArray( [ { name: "fieldName", type:"uint32'
> },
> > ... probably an array of objects defining the fields in an element ],
> >  );
> >
> > arr[x].fieldName = value.
> >
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

InterleavedTypedArray type

[J Decker]

I would like to open a discussion to propose that an extension to
http://www.ecma-international.org/ecma-262/6.0/#sec-typedarray-objects
should be defined that would allow defintiion of interleaved typed data.

Support for interleaved vertex data is one use...

https://developer.apple.com/library/content/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/TechniquesforWorkingwithVertexData/TechniquesforWorkingwithVertexData.html
 section Use Interleaved Vertex Data


https://www.khronos.org/opengl/wiki/Vertex_Specification
Defines how OpenGL describes interleaved data.

This could also be used to interop with native code as an array of packed
(C) structs.

I don't really know what the definition mechanics might be, but for usage I
might like to see...

var arr = new InterleavedTypeArray( [ { name: "fieldName", type:"uint32' },
... probably an array of objects defining the fields in an element ],
 );

arr[x].fieldName = value.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allowing object field name shorthand

[J Decker]

On Thu, Jun 22, 2017 at 7:56 AM, Sebastian Malton 
wrote:

> I would like to propose that the dot or '.' is allowed in object field
> names so that the following are allowed.
>
> var obj = {
> field1: "val" ,
> field2.field3: 3,
> field2.field4: true
> };
>
>
This is much like
var obj = {
   field1: 3
   field2 : 4
   field3 : obj.field2+3
}

which falls apart because obj isn't technically fully defined, and doesn't
have a field2.  So your second field2.field4 wouldn't be able to reference
the previous object created for field2.field3.

it would be a huge complexity for engines to create objects


>
>
> Sebastian
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Nonconstructors

[J Decker]

function Entity() {
if (this instanceof Entity) throw new Error("Please do not call with new");
}

oh the other side; you can bind this to a simple function call...


function f() {
}
var fWithThis = f.bind( {} /*Something to use as 'this' */ )

call with fWithThis()

and f's this will be the object you passed to bind.

On Mon, Apr 24, 2017 at 1:42 PM, Raul-Sebastian Mihăilă <
raul.miha...@gmail.com> wrote:

> I have a dilemma. I like how typically the built-in methods are not
> constructors (like Array.prototype.forEach). I have cases in which I'm
> creating a function in which I want to use `this` but I would like the
> function to not be constructible. There are ways of doing this:
> - checking new.target - but you have to check and the last time I checked
> uglifyjs was failing because of it.
> - ({function() { ... }}).function - but this requires creating an object
> every time, so it's ugly.
>
> It would probably be too much to add a new kind of function definition,
> but I was wondering if anybody ever cared about this kind of things. For
> instance, would people usually expect frameworks/libaries or Javascript
> itself to not make functions constructible if they're not meant to be?
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Resource management

[J Decker]

Just a shot; but something ilke deasync ?
https://www.npmjs.com/package/deasync

it's not so much about ordering wait in the current code, but the current
code within outer code that's the issue somehow?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[J Decker]

On Thu, Nov 3, 2016 at 9:10 AM, Michał Wadas <michalwa...@gmail.com> wrote:

> Why you can't solve it with shared memory buffer? Shared - I mean instance
> of *SharedArrayBuffer. *
>
> not in node; in browser ya... where webworkers are threads.  (and not in
javascript base)
And while firefox is beginning to look appealing again I'm stuck on chrome
(native android)


> On 3 Nov 2016 5:05 p.m., "J Decker" <d3c...@gmail.com> wrote:
>
>>
>>
>> On Wed, Nov 2, 2016 at 7:44 AM, Michał Wadas <michalwa...@gmail.com>
>> wrote:
>>
>>> Actually, is there any problem that can't be easily solved with
>>> message-passing for high-level structures or low-level shared memory
>>> buffers?
>>>
>>>
>> Yes, meshing dynamic geometries that involve a few 20k faces.   If you
>> have a thread do the work, the overhead of srealizing the resulting buffers
>> will kill any benefit.
>>
>> But; typed arrays can be shared also.  (they are with C++ addons in node)
>>
>> The biggest problem with node's lack of threads is they really need
>> separate but equal heaps.  I heard that there's a global heap lock... that
>> wouldn't be required except when allocating addition space for each heap.
>>
>>
>>
>> To the general - stop treating programmers like idiots.  Give us the
>> rope.  Let us hang ourselves.
>>
>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[J Decker]

On Wed, Nov 2, 2016 at 7:44 AM, Michał Wadas  wrote:

> Actually, is there any problem that can't be easily solved with
> message-passing for high-level structures or low-level shared memory
> buffers?
>
>
Yes, meshing dynamic geometries that involve a few 20k faces.   If you have
a thread do the work, the overhead of srealizing the resulting buffers will
kill any benefit.

But; typed arrays can be shared also.  (they are with C++ addons in node)

The biggest problem with node's lack of threads is they really need
separate but equal heaps.  I heard that there's a global heap lock... that
wouldn't be required except when allocating addition space for each heap.



To the general - stop treating programmers like idiots.  Give us the rope.
Let us hang ourselves.


> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Power operator, why does -2**3 throws?

[J Decker]

probably because it's floating point native not integer like you'd think,
so -2.0001 ** 3 is hard?

On Fri, Oct 14, 2016 at 4:30 AM, Cyril Auburtin 
wrote:

> I would expect `-2**3` to return -8, or `-2**2 == -4`, since it should be
> like `-(2**3)`
>
> Firefox gives a clearer error then Chrome with:
> > SyntaxError: unparenthesized unary expression can't appear on the
> left-hand side of '**'
>
> Is there a reason for this restriction? Python does it `-2**3` fine
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: anaphoric if and while syntax

[J Decker]

On Fri, Sep 16, 2016 at 10:43 AM, J Decker <d3c...@gmail.com> wrote:

> I saw it mentioned in several messages earlier about the comma operator as
> applied to the let/var statement... I suppose that IS an issue.
>
> for example : if( let a = 1, b = 0 )
>   1)  if( 1, 0 )  the comma operator clears the expression stack and
> results with only the value after the comma... so you can chain some
> expressions that may have side effects... /* if( a=f(), b=g(a) )  */
>

Sorry I did that again; ... that would really be like ' a = (  f(), b=g(a))
' and would fail I always do that.  maybe

if( ( a=f() ), g(a) ) intead?


>
>   2) if the comma is then interpreted as an operator for the declaration,
> then the result is... undeterminate... because there's really not a
> testable result ?
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: anaphoric if and while syntax

[J Decker]

I saw it mentioned in several messages earlier about the comma operator as
applied to the let/var statement... I suppose that IS an issue.

for example : if( let a = 1, b = 0 )
  1)  if( 1, 0 )  the comma operator clears the expression stack and
results with only the value after the comma... so you can chain some
expressions that may have side effects... /* if( a=f(), b=g(a) )  */

  2) if the comma is then interpreted as an operator for the declaration,
then the result is... undeterminate... because there's really not a
testable result ?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: anaphoric if and while syntax

[J Decker]

On Fri, Sep 16, 2016 at 2:43 AM, Bob Myers <r...@gol.com> wrote:

> I often find myself wanting to do this in the case of `while`. I've been
> writing
>
> ```
> for (let a; a = someLongCondition();) { doSomethingWith(a); }
> ```
>
> In that spirit, an oddball proposal:
>
> ```
> while (let a = someLongCondition(); a) { ...use a... }
> if (let a = someLongCondition(); a) { ...use a... }
>

switch( let a = something() ) {   }

would   ' do { ... use a ... } while( let a = f() ); '  work?

( (let a = f() ) > 3 ) ? (a-3) : (a+3) //ternary operator?

which begins to look like   '( [let/var/const] ... ) '  in any expression.


```
>
> On Fri, Sep 16, 2016 at 2:39 AM, Isiah Meadows <isiahmead...@gmail.com>
> wrote:
>
>> I say let's hold off until JavaScript gets pattern matching support
>> (assuming it does). It's rather limiting otherwise, and the use case IMHO
>> doesn't really merit a new syntax for it.
>>
>> On Thu, Sep 15, 2016, 15:47 Jeremy Martin <jmar...@gmail.com> wrote:
>>
>>> > If yes ... why would anyone write that ?
>>>
>>> I think it would have to be "yes" (and that's probably just a contrived
>>> example that doesn't demonstrate the usefulness).
>>>
>>> Slightly less contrived, I could see the value in this, though. E.g.,
>>>
>>> ```
>>> router.get('/user', (req, res, next) => {
>>> if (let user = req.session.user) {
>>> // do stuff with user here
>>> } else {
>>> res.status(401).end();
>>> }
>>> });
>>> ```
>>>
>>> I don't think it works as cleanly with `var`, but `const` and `let` has
>>> some nice precedence with for-statements.
>>>
>>>
>>> On Thu, Sep 15, 2016 at 2:45 PM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>>> > if( let a = ( let b = 10 ) * 3 > 10 )
>>>>
>>>> I've honestly no idea, at first/quick read, what the hell that would
>>>> produce.
>>>>
>>>> Is `a` going to be just `true` ? 'cause if not, this proposal violates
>>>> operator precedence.
>>>>
>>>> If yes ... why would anyone write that ?
>>>>
>>>> On Thu, Sep 15, 2016 at 7:30 PM, J Decker <d3c...@gmail.com> wrote:
>>>>
>>>>> Why not more generally - allow let/var declarations in expressions?
>>>>>
>>>>> coming from a long and rich C background, I have no issues with the
>>>>> existing mechanisms... but for those languages that do support variable
>>>>> declarations in for loops; I've always wondered why not any expression?
>>>>>
>>>>> if( let a = ( let b = 10 ) * 3 > 10 )
>>>>> ... or ...
>>>>>
>>>>> c = (let a = b*d)
>>>>>
>>>>> granted, the scope is extremely limited in the last case...
>>>>>
>>>>> ___
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>>
>>> --
>>> Jeremy Martin
>>> 661.312.3853
>>> http://devsmash.com
>>> @jmar777
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: anaphoric if and while syntax

[J Decker]

Why not more generally - allow let/var declarations in expressions?

coming from a long and rich C background, I have no issues with the
existing mechanisms... but for those languages that do support variable
declarations in for loops; I've always wondered why not any expression?

if( let a = ( let b = 10 ) * 3 > 10 )
... or ...

c = (let a = b*d)

granted, the scope is extremely limited in the last case...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to solve this basic ES6-module circular dependency problem?

[J Decker]

Just out of curiosity; And because this is a singular issue using babel...
why are you bothering to use import when nothing supports it or apparently
plans to?

Why Was import designed in such a way to not be polyfillable?  But instead
requires a magical syntax to invoke?

Why structured reuse of modules such a bastard child?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ignoring arguments

[J Decker]

On Thu, Aug 11, 2016 at 5:55 PM, Cyril Auburtin <cyril.aubur...@gmail.com>
wrote:

> > `( ( ignore_me, ignore_me2, asdf ) => { /* ... */ } ) (undefined,
> undefined, {whatever:1} )`
>
> Let's forget about functions invocations, a bad idea, so that's more the 
> `ignore_me,
> ignore_me2` that are quite polluting/unpractical
>
> I'm not either a fan of skipping in arrays, but again function arguments
> is an array, that same syntax represent literally holes. there's also
> like for invocations the risks of a typo, but the coder has to be really
> distracted to not see it..
>
> Thanks for that discussion, it'll very likely never make it to the spec,
> and sorry my last message had typos, corrected on
> https://esdiscuss.org/topic/ignoring-arguments, mailing-lists :/
>
>
but the point of that really is... why can't you just use the token
'undefined' instead of trying to use whitespace?



> 2016-08-11 23:44 GMT+02:00 Michał Wadas <michalwa...@gmail.com>:
>
>> If you want to have new syntax for this feature, keyword void can be
>> easily reused:
>>
>> ((void, void, void, param)=>param)(1,2,3,4) // 4
>>
>> But I don't think it's worth it.
>>
>> On Thu, Aug 11, 2016 at 10:53 PM, J Decker <d3c...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Aug 11, 2016 at 1:28 PM, Isiah Meadows <isiahmead...@gmail.com>
>>> wrote:
>>>
>>>> If you're talking about ignored function parameters in a declaration or
>>>> expression, much like `_` in several functional languages (like Haskell and
>>>> Scala), I could see value in that. I'd prefer an explicit token for that,
>>>> though, something like this:
>>>>
>>>
>>> 'undefined' is what, too many characters to type?
>>>
>>> ( ( ignore_me, ignore_me2, asdf ) => { /* ... */ } ) (undefined,
>>> undefined, {whatever:1} )
>>>
>>>
>>>
>>>
>>>> ```js
>>>>
>>> // ImmutableJS: convert map to list, only
>>>> // keeping values with integer keys
>>>> map
>>>> .filter((*, key) => typeof key === "number" && key % 1 === 0)
>>>> .toList()
>>>> ```
>>>>
>>>> On Thu, Aug 11, 2016, 12:51 Kris Siegel <krissie...@gmail.com> wrote:
>>>>
>>>>> ignoring/skipping argument in functions declarations (indeed the
>>>>>> invocations could be let apart)
>>>>>
>>>>>
>>>>> I am of the opinion that this is not a problem that needs to be solved
>>>>> at the language standardization level. The commas (or really any 
>>>>> separator)
>>>>> for "skipping" a parameter looks like a mistake and is unintuitive (it's
>>>>> certainly not obvious to me what its intent is had I seen it without the
>>>>> context of this thread).
>>>>>
>>>>> This seems like a problem solved with better coding practices. I
>>>>> typically make required parameters first and then any optional ones in a
>>>>> separate, single parameter called options. Callbacks can be done with
>>>>> chaining / promises / I fmake them required / etc. Skipping callbacks
>>>>> usually isn't a good idea. We could talk all day about who's coding
>>>>> practice is better than who's but ultimately this problem should be solved
>>>>> by developing / adopting good coding practices.
>>>>>
>>>>> (Honestly I'm not a fan of the skipping in arrays either but
>>>>> considering it's an array I feel like it's at least a magnitude less
>>>>> confusing than doing it with function parameters)
>>>>>
>>>>> On Thu, Aug 11, 2016 at 4:00 AM, Cyril Auburtin <
>>>>> cyril.aubur...@gmail.com> wrote:
>>>>>
>>>>>> > Confused by this thread.
>>>>>>
>>>>>> It's quite simple though, _ would be a useless allocated variable,
>>>>>> you an't have more than 1, ...
>>>>>>
>>>>>> > What is the problem that this proposal is trying to solve?
>>>>>>
>>>>>> ignoring/skipping argument in functions declarations (indeed the
>>>>>> invocations could be let apart)
>>>>>>
>>>>>> > `Math.min(x,,y)`
>>>>>>
>>>>>> yes this kind of thing would give NaN, that's why you can `Math.min(x,
>>>>

Re: Ignoring arguments

[J Decker]

On Thu, Aug 11, 2016 at 1:28 PM, Isiah Meadows 
wrote:

> If you're talking about ignored function parameters in a declaration or
> expression, much like `_` in several functional languages (like Haskell and
> Scala), I could see value in that. I'd prefer an explicit token for that,
> though, something like this:
>

'undefined' is what, too many characters to type?

( ( ignore_me, ignore_me2, asdf ) => { /* ... */ } ) (undefined, undefined,
{whatever:1} )




> ```js
>
// ImmutableJS: convert map to list, only
> // keeping values with integer keys
> map
> .filter((*, key) => typeof key === "number" && key % 1 === 0)
> .toList()
> ```
>
> On Thu, Aug 11, 2016, 12:51 Kris Siegel  wrote:
>
>> ignoring/skipping argument in functions declarations (indeed the
>>> invocations could be let apart)
>>
>>
>> I am of the opinion that this is not a problem that needs to be solved at
>> the language standardization level. The commas (or really any separator)
>> for "skipping" a parameter looks like a mistake and is unintuitive (it's
>> certainly not obvious to me what its intent is had I seen it without the
>> context of this thread).
>>
>> This seems like a problem solved with better coding practices. I
>> typically make required parameters first and then any optional ones in a
>> separate, single parameter called options. Callbacks can be done with
>> chaining / promises / I fmake them required / etc. Skipping callbacks
>> usually isn't a good idea. We could talk all day about who's coding
>> practice is better than who's but ultimately this problem should be solved
>> by developing / adopting good coding practices.
>>
>> (Honestly I'm not a fan of the skipping in arrays either but considering
>> it's an array I feel like it's at least a magnitude less confusing than
>> doing it with function parameters)
>>
>> On Thu, Aug 11, 2016 at 4:00 AM, Cyril Auburtin > > wrote:
>>
>>> > Confused by this thread.
>>>
>>> It's quite simple though, _ would be a useless allocated variable, you
>>> an't have more than 1, ...
>>>
>>> > What is the problem that this proposal is trying to solve?
>>>
>>> ignoring/skipping argument in functions declarations (indeed the
>>> invocations could be let apart)
>>>
>>> > `Math.min(x,,y)`
>>>
>>> yes this kind of thing would give NaN, that's why you can `Math.min(x,
>>> , y)` write it with more spaces to avoid a typo mistake, indeed you could
>>> still have like `Math.min(x, /*y (no longer used)*/ , z)` would. Like
>>> said above, I realize the function invocations are sensible.
>>>
>>> So, it would be only for function declarations
>>>
>>> `div.addEventListener('click', () => { } )` says to skip all arguments,
>>> and you've your callback scope is free of any additional vars
>>>
>>> `arr.forEach( x => { } )` says to only consider first argument, others
>>> are skipped, and not in scope
>>>
>>> `Array.from({length: 19}, (, i) => i )` would be similar for the second
>>> argument, similarly to array destructuring. It's not just for saving one
>>> character, that's really not the matter, it's for standardizing this way,
>>> because some people use `_`, some don't, 
>>>
>>> 2016-08-10 16:27 GMT+02:00 Bob Myers :
>>>
 Confused by this thread.

 > What if you could use a `.` as a wildcard?

 You can already use `_` or anything you want, as was already pointed
 out in early iterations of this idea.

 > it would avoid binding a usable identifier.

 What is the problem with that?

 What is the problem that this proposal is trying to solve? Any chance
 we could move on?

 Bob



 On Wed, Aug 10, 2016 at 7:48 PM, Alan Johnson  wrote:

> What if you could use a `.` as a wildcard? I don’t think it would
> conflict with existing syntax, and it would avoid binding a usable
> identifier. It would be more obvious than nothing between the commas.
>
>
> On Aug 8, 2016, at 06:33, Cyril Auburtin 
> wrote:
>
> Just bumping this up
>
> Calling `foo(1)` where foo is defined with 3 arguments, lets the 2
> others undefined, this behavior is already a bit magic and similar to the
> behavior of an array, so I still think foo(a,,b,,,c) should be like
> foo(...[a,,b,,,c])
>
> Other example:
> ```
> var m=new Map([[1], [2,], [3,7]]) // Map {1 => undefined, 2 =>
> undefined, 3 => 7} // here commas fantasies are allowed in arrays
> m.set(3) // Map {1 => undefined, 2 => undefined, 3 => undefined} //
> setting implicitely value as undefined
> m.set(3, ) // not allowed, which should be m.set(...[3,])
> ```
>
> and again, it would help for callbacks too, `something( ( , ,
> thirdArg) => {} )`
>
> I saw this https://jeffmo.github.io/es-trailing-function-commas/, it
> seems like a sub-case
>
> 

Re: Redefining a let variable inside a for loop scope doesn't work?

[J Decker]

On Fri, Jul 15, 2016 at 7:18 AM, Allen Wirfs-Brock 
wrote:

> This is by design.  ECMAScript block scoped declarations generally conform
> to the principle that within a single block or statement a name may have
> only a single binding. For example,
>
> ```js
> let x=0;
> {
>   let x = x+1;  //access to uninitialized variable error because both the
> RHS and LHS refer to the inner x
>  //which has not yet been initialized when the RHS is
> evaluated
> }
>
> ```
>
> The same principle also applies to
> ```js
> let n = {a:[]};
> for (let n of n.a) ;
> ```
>
> although the actual scoping of the `for` statement is more complex.
> Basically, such `for` statements consider all names bound by the `let` part
> of of the `for` header to be undefined while the `of` expression is being
> evaluated.
>
>
Wouldn't that scope for the 'for' loop declaration allow testing the 'n'
variable after the loop?  (test to see if it was broken out of completed),
without requiring extra braces around the for?  (Although sounds like just
dong

{
   for( let n ...) {
   }
   // can test/use N here?
}

would also have worked like the workaround for C#/C++?


> This is done to avoid any confusion about which `n` the expression
> references. Such confusion is avoid by all references to the `let` bound
> names from the RHS errors.
>
> Allen
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss