Re: Native Assertions

[Sebastian Zartner]

console.assert is standardized by the WHATWG at
https://console.spec.whatwg.org/#assert.

Sebastian

On Mon, 14 Jan 2019 at 12:39, Michael Haufe  wrote:

> console.assert is not standardized at this point, nor is it part of the
> language. Additionally, the semantics are inappropriate for the required
> use cases.
>
> To requote the relevant part from the linked thread:
>
> 1. AssertionError <: Error
> 2. assert(x === 12); // throws an AssertionError with a default error
> message
> 3. assert(x === 12, "twelve, supposedly") // throws an AssertionError with
> the given error message
>
> console.assert does not throw and its intent is not the same. The assert
> I'm referring to is related to Code Contracts. Therefore your reference is
> seemingly orthogonal.
>
> /Michael
>
> On Sun, Jan 13, 2019, 12:49 Cyril Auburtin  wrote:
>
>> There's `console.assert`
>>
>> also check
>> https://github.com/michaelficarra/proposal-first-class-protocols/issues/27#issuecomment-386975099
>>
>>
>> On Sun, Dec 16, 2018 at 10:01 PM Michael Haufe 
>> wrote:
>>
>>> Seven years ago there was discussion around standardizing "assert". Has
>>> there been any movement on this since then?
>>>
>>> https://esdiscuss.org/topic/native-assertion-module
>>>
>>>
>>> ___
>>> 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: Removal of language features

[Sebastian Zartner]

On 24 July 2017 at 10:47, Naveen Chawla  wrote:
> If reducing the available feature set would increase performance then a 
> declaration to the browser to ignore deprecated features should be enough to 
> get this optimization, but only for this reason.
>
> But do we even know that there is any performance gain for doing so?
>
> I'm not bothered about browser code complexity to support old features - I 
> don't see that code anyway. I don't know to what extent other javascript 
> developers are bothered about it either.

Well, JavaScript developers may not bother about the complexity of
browser code, though browser developers, or more generally spoken,
JavaScript engine developers should care about the complexity of their
code. Supporting old features may not only be a question of engine
performance but also memory consumption and (download) sizes of their
programs.
So, it should be in their interest to deprecate misfeatures, even when
it takes 5, 10, or 15 years until their usage drops enough so they can
actually be removed.

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

Re: Proposal: Expose offsets for capturing groups in regular expression matches

[Sebastian Zartner]

I've filed issue
https://github.com/tc39/proposal-regexp-named-groups/issues/21 to start the
discussion there.

Sebastian

On 30 March 2017 at 12:25, Daniel Ehrenberg <little...@chromium.org> wrote:

> I've been trying to organize feedback to the named captures proposal in
> bugs on the repository in GitHub at https://github.com/tc39/
> proposal-regexp-named-groups/issues . I'd be happy to have your input.
> This proposal's implementation is in progress in V8.
>
> Dan
>
> On Mar 30, 2017 10:29 AM, "Sebastian Zartner" <sebastianzart...@gmail.com>
> wrote:
>
>> Hi, and sorry for the response delay!
>>
>> On 24 March 2017 at 01:47, Jordan Harband <ljh...@gmail.com> wrote:
>>
>>> Adding a property to the match result is indeed tricky.
>>>
>>
>> Why? The match result already has the properties index and input
>> <http://www.ecma-international.org/ecma-262/6.0/#sec-regexpbuiltinexec>.
>>
>>
>>> Not sure if you're already aware that named capture groups are stage 3:
>>> https://github.com/tc39/proposal-regexp-named-groups
>>>
>>
>> Thank you for the reference! At the time I wrote my proposal (which was
>> the last time I looked), named captured groups were at stage 0. I read
>> about that proposal back then, though it doesn't allow to get the related
>> offsets, either.
>> My proposal may be changed to work together with named captured groups
>> (i.e. by adding the offsets to the groups property), though the offsets
>> should also be available when the captured groups are not named.
>>
>> On Thu, Mar 23, 2017 at 8:08 AM, T.J. Crowder <
>>> tj.crow...@farsightsoftware.com> wrote:
>>>
>>>> Excellent idea, and nice and simple as well. I wouldn't think adding a
>>>> property to the match result would rattle cages, it'll be interesting to
>>>> find out.
>>>>
>>>> @eric - I prefer the proposal's approach to offsets. If you need to
>>>> know where the end is, you can always add the length of the captured text,
>>>> so the information is already there.
>>>>
>>>> -- T.J. Crowder
>>>>
>>>> On Thu, Mar 23, 2017 at 3:00 PM, Erik Corry <erik.co...@gmail.com>
>>>> wrote:
>>>>
>>>>> This would be great.  Can I suggest that both the start and end of
>>>>> each match should be there.  So instead of offsets you would have "starts"
>>>>> and "ends".  Alternatively, offsets should be twice as long with start-end
>>>>> pairs in it.
>>>>>
>>>>
>> Initially I had an advanced approach to this
>> <https://github.com/SebastianZ/es-proposal-regexp-capturing-group-offsets/blob/983af857ec2dce5e3c0af5e8438ca6dc8d74c3f0/README.md>
>> similar to the named captured groups proposal including start and end
>> properties for each group. Though after a discussion related to
>> String.prototype.matchAll()
>> <https://github.com/tc39/String.prototype.matchAll/issues/13> due to the
>> fact that the end offset can easily be calculated by the start offset and
>> the length of the captured group, I thought a simpler approach would easier
>> get traction. Also, this approach is conformant to how other languages like
>> ColdFusion solve this.
>> Having said that, I am happy to discuss different approaches to this.
>>
>> Sebastian
>>
>>
>>> On Mon, Oct 31, 2016 at 9:53 AM, Sebastian Zartner <
>>>>> sebastianzart...@gmail.com> wrote:
>>>>>
>>>>>> Hello together,
>>>>>>
>>>>>> for advanced processing of capturing groups in regular expression,
>>>>>> I'd like to propose to expose their offsets within the results of 
>>>>>> executing
>>>>>> an expression on a string.
>>>>>>
>>>>>> The complete proposal can be found at https://github.com/SebastianZ/
>>>>>> es-proposal-regexp-capturing-group-offsets.
>>>>>>
>>>>>> I'd like it to be added to the Stage 0 proposals
>>>>>> <https://github.com/tc39/proposals/blob/master/stage-0-proposals.md>
>>>>>> and I'm asking for feedback and a champion to help me bring it into shape
>>>>>> and get it into the standard.
>>>>>>
>>>>>> Thank you in advance,
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> ___
>>>> 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: Expose offsets for capturing groups in regular expression matches

[Sebastian Zartner]

Hi, and sorry for the response delay!

On 24 March 2017 at 01:47, Jordan Harband <ljh...@gmail.com> wrote:

> Adding a property to the match result is indeed tricky.
>

Why? The match result already has the properties index and input
<http://www.ecma-international.org/ecma-262/6.0/#sec-regexpbuiltinexec>.


> Not sure if you're already aware that named capture groups are stage 3:
> https://github.com/tc39/proposal-regexp-named-groups
>

Thank you for the reference! At the time I wrote my proposal (which was the
last time I looked), named captured groups were at stage 0. I read about
that proposal back then, though it doesn't allow to get the related
offsets, either.
My proposal may be changed to work together with named captured groups
(i.e. by adding the offsets to the groups property), though the offsets
should also be available when the captured groups are not named.

On Thu, Mar 23, 2017 at 8:08 AM, T.J. Crowder <tj.crowder@farsightsoftware.c
> om> wrote:
>
>> Excellent idea, and nice and simple as well. I wouldn't think adding a
>> property to the match result would rattle cages, it'll be interesting to
>> find out.
>>
>> @eric - I prefer the proposal's approach to offsets. If you need to know
>> where the end is, you can always add the length of the captured text, so
>> the information is already there.
>>
>> -- T.J. Crowder
>>
>> On Thu, Mar 23, 2017 at 3:00 PM, Erik Corry <erik.co...@gmail.com> wrote:
>>
>>> This would be great.  Can I suggest that both the start and end of each
>>> match should be there.  So instead of offsets you would have "starts" and
>>> "ends".  Alternatively, offsets should be twice as long with start-end
>>> pairs in it.
>>>
>>
Initially I had an advanced approach to this
<https://github.com/SebastianZ/es-proposal-regexp-capturing-group-offsets/blob/983af857ec2dce5e3c0af5e8438ca6dc8d74c3f0/README.md>
similar to the named captured groups proposal including start and end
properties for each group. Though after a discussion related to
String.prototype.matchAll()
<https://github.com/tc39/String.prototype.matchAll/issues/13> due to the
fact that the end offset can easily be calculated by the start offset and
the length of the captured group, I thought a simpler approach would easier
get traction. Also, this approach is conformant to how other languages like
ColdFusion solve this.
Having said that, I am happy to discuss different approaches to this.

Sebastian


> On Mon, Oct 31, 2016 at 9:53 AM, Sebastian Zartner <
>>> sebastianzart...@gmail.com> wrote:
>>>
>>>> Hello together,
>>>>
>>>> for advanced processing of capturing groups in regular expression, I'd
>>>> like to propose to expose their offsets within the results of executing an
>>>> expression on a string.
>>>>
>>>> The complete proposal can be found at https://github.com/SebastianZ/
>>>> es-proposal-regexp-capturing-group-offsets.
>>>>
>>>> I'd like it to be added to the Stage 0 proposals
>>>> <https://github.com/tc39/proposals/blob/master/stage-0-proposals.md>
>>>> and I'm asking for feedback and a champion to help me bring it into shape
>>>> and get it into the standard.
>>>>
>>>> Thank you in advance,
>>>>
>>>> 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
>>>
>>>
>>
>> ___
>> 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

Proposal: Expose offsets for capturing groups in regular expression matches

[Sebastian Zartner]

Hello together,

for advanced processing of capturing groups in regular expression, I'd like
to propose to expose their offsets within the results of executing an
expression on a string.

The complete proposal can be found at
https://github.com/SebastianZ/es-proposal-regexp-capturing-group-offsets.

I'd like it to be added to the Stage 0 proposals
 and
I'm asking for feedback and a champion to help me bring it into shape and
get it into the standard.

Thank you in advance,

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

Re: Could we add the missing Regexp features from perl?

[Sebastian Zartner]

There are already a few regexp features in the pipeline, see
https://github.com/goyakin/es-regexp (listed in the Stage 0 proposals at
https://github.com/tc39/proposals/blob/master/stage-0-proposals.md).

The list of proposed features is not complete yet[1], though they already
cover some main itches ECMAScript's implementation is currently missing.

Sebastian

[1] Some missing features are listed at
http://www.regular-expressions.info/javascript.html

On 17 June 2016 at 18:19, Brian Jemilo II  wrote:

> Javascript regexp is based on a subset of perl's regexp engine, but its
> missing a lot of features that would make javascript more powerful.
> Wondering if we can put it into spec to add the missing features. Regexp is
> very powerful and currently, Javascript is being held by by the missing
> features.
>
> ___
> 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: Look-behind proposal in trouble

[Sebastian Zartner]

Hi together,

Brian, where can people get the information about the reasons of such
decisions (besides asking) and more generally about the processes behind
the ES development?

I was following Nozomu's proposal[1] closely, though to me it looked like
the progress on this just died out.

Non-the-less, great to hear that new champions could be found!

Sebastian

[1] https://mail.mozilla.org/pipermail/es-discuss/2015-May/042910.html

On 5 October 2015 at 23:42, Nozomu Katō  wrote:

> Hello Brian,
>
> I thank you very much indeed for your email and bringing really good
> news! I thought that my proposal might not be able to move forward
> anymore.
>
> I am also thankful that you searched for a new champion and Gorkem
> undertakes this proposal!
>
> Regards,
>   Nozomu
>
>
> Brian Terlson wrote on Mon, 5 Oct 2015, at 20:29:18 +:
> > Hi Nozomu,
> >
> > Brendan has indeed discovered he doesn't have time to champion the
> > proposal through TC39, so I removed it while I searched for a new
> > champion. Good news on that front - I have found one! Gorkem Yakin
> > works on the Chakra team and is available to help move this proposal
> > forward. I will also help out where I can. I've added the proposal
> > back to the stage 0 list!
> >
> > Thanks,
> > Brian
> ___
> 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: Additional Math functions

[Sebastian Zartner]

While Math.sum() and Math.mean() currently don't exist, they can easily be
polyfilled:
See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce#Sum_all_the_values_of_an_array
for summarizing the values of an array and the following code for building
the average of the array values:

let arr = [0, 1, 2, 3];
let total = arr.reduce(function(a, b) {
  return a + b;
});
let mean = total / arr.length;

Calculating the variance and standard deviation would require a bit more
code, though are also easy to polyfill.
Non-the-less I can see the need for having standard functions for this.

Sebastian

On 2 October 2015 at 00:55, Eli Perelman  wrote:

> In case it didn't come across, this is the thread I'm reviving:
>
> https://mail.mozilla.org/pipermail/es-discuss/2015-April/042732.html
>
> Eli Perelman
> Mozilla
>
> On Thu, Oct 1, 2015 at 5:51 PM, Eli Perelman  wrote:
>
>> Reviving this thread, doing any type of simple statistics is more verbose
>> than it probably needs to be as calculating sums, averages, etc. makes most
>> resort to Array reduction. I understand the need for methods such as
>> `Math.hypot(...values)`, but for ECMAScript to evolve to be useful in
>> statistics programming without needing to resort to R would definitely also
>> be a nice-to-have. I'm sure there are many statistical functions you
>> *could* add, but at a bare minimum, it would be useful:
>>
>> Math.sum(...values) or Math.summation(...values)
>> Math.mean(...values) // Spelling out mean here is succinct while still
>> intentional, instead of .avg
>> Math.variance(...values)
>> Math.stddev(...values)
>>
>> Obviously some of these can be computed from the results of others, but I
>> think the convenience and intent of the methods, not to mention their wide
>> usefulness outweigh the concern of Math bloat. Thoughts?
>>
>> P.S. Definitely not against even more core stats methods, but have to
>> start somewhere. :)
>>
>> Eli Perelman
>> Mozilla
>>
>
>
> ___
> 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: for statement with index and value

[Sebastian Zartner]

That only works if all values are distinct. The following will result
in the wrong index for the last item:

let values = [a, b, a];

for (let value of values) {
   let index = values.indexOf(value);
}

Also that construct is not very performant.

Sebastian

On 15 July 2015 at 03:02, Rick Waldron waldron.r...@gmail.com wrote:
 If you need the _index of_ a value in an array, there is always... indexOf
 ;)

 for (let value of values) {
   let index = values.indexOf(value);
 }

 Rick

 On Tue, Jul 14, 2015 at 4:16 PM Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Mon, Jul 13, 2015 at 7:13 PM, Tingan Ho tinga...@gmail.com wrote:
  Just following a discussion we had on TypeScript
  https://github.com/Microsoft/TypeScript/issues/3835
 
  In most times, I just need the value in an array, so I use a for..of
  loop.
  But then, I find out that I need the index too, then I need to rewrite
  my
  whole for loop expression. Happens all the time for me.
 
  I have to ask why there doesn't exist a `for statement` where I can get
  the
  index and value of an array directly? Or for that matter property and
  value
  of an object?
 
  `.forEach` is not ideal since you can't break, break to outer loop and
  continue cleanly. Even though you can achieve this with other array
  methods,
  I don't think they are as productive as a for-statement.
 
  What I'm suggesting is augmenting the current syntax for `for..of`
  loops.
  And support an overloading pattern so that we don't need to rewrite the
  whole for loop expression to just to get the index when we already
  getting
  the value.
 
  ```
  // overloads
  for (let value, index of values) { ... }
  for (let value of values) { ... }
  ```
 
  PS. Sorry if this has already discussed. Couldn't find any on Google and
  the
  esdiscuss.org page doesn't have any search capabilities.

 Kevin provided the built-in answer for arrays, but for arbitrary
 iterables, the Python solution is trivial:

 function* enumerate(iter) {
   let i = 0;
   for(let value of iter) {
 yield [i, value];
 i++
   }
 }

 for(let [i, v] of enumerate(values)) {
   ...
 }

 I expect there's already libraries that duplicate all of Python's
 itertools and more; the iterator algebra is really trivially hackable.

 ~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: Look-behind proposal

[Sebastian Zartner]

Thank you Brendan for picking this up!
Nozomu, Brendan, please let me know if I can be of any help.

Sebastian

On 8 June 2015 at 18:47, Brendan Eich bren...@mozilla.org wrote:
 I will do it if no one else steps up by 10pm tonight PDT.

 Thank you to Nozomu Katō for writing it up!

 /be


 Sebastian Zartner wrote:

 So the question is, how to recruit a TC39 member? Through this list? Is it
 possible to become a member as a private person?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Look-behind proposal

[Sebastian Zartner]

So the question is, how to recruit a TC39 member? Through this list? Is it
possible to become a member as a private person?

Sebastian

On 5 June 2015 at 14:58, Nozomu Katō noz...@akenotsuki.com wrote:

 Thank you for the clarification.

 Unfortunately, I do not know at all who is a TC39 member. I wonder if
 there is a member who will work for this proposal.

 Even in the case that no one is found this time, I will leave the html
 version of the proposal as it is at that url. If anyone later come to
 have an interest in that proposal please take it and modify (if needed)
 freely.

 Nozomu


 Allen Wirfs-Brock wrote on Thu, 4 Jun 2015, at 13:23:08 -0700:
  In order to keep this moving forward, you need to recruit a TC39
  member who will work with you and act as the champion for the
  proposal within TC39.
 
  Allen

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

Re: Look-behind proposal

[Sebastian Zartner]

Thank you for picking this up again!
I asked for adding look-behinds back in 2013[1], though I didn't find the
time to come up with an algorithm and read into writing this down for the
specification.
So let's hope this discussion will result in something this time.

Sebastian

[1] https://mail.mozilla.org/pipermail/es-discuss/2013-September/033837.html

On 21 May 2015 at 14:01, Nozomu Katō noz...@akenotsuki.com wrote:

 I revised my proposal for lookbehinds:
 http://www.akenotsuki.com/misc/srell/lookbehind_proposal.html

 I rewrote the paragraphs about how to count Atoms in Disjunction, to
 clarify that the recursive call is used for nested Disjunctions.

 Regards,
   Nozomu
 ___
 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: Multiline template strings that don't break indentation

[Sebastian Zartner]

 The tag goes at the front.

 I know. I didn't see this functionality as a tag, though, but rather as a
flag for the client. Having this functionality available as a tag has some
consequences. See below.

 What's missing from the design that can't be provided as a standard
 exported deindent function?

 Concatenating tags, maybe? And the function itself?

 exactly:

 var a = dontIndent
 `This is a template string.
  Even though each line is indented to keep the
  code neat and tidy, the white space used to indent
  is not in the resulting string`;

 or, following the precedent to 'raw':

 var a = String.noIndentation
 `This is a template string.
  Even though each line is indented to keep the
  code neat and tidy, the white space used to indent
  is not in the resulting string`;


And if someone wants to use his own tag? Would he have to reimplement
dontIndent or String.noIndentation by himself?

What I meant above with tag concatenation would be something like this:

var a = String.noIndentation myTag
`This is a template string.
 Even though each line is indented to keep the
 code neat and tidy, the white space used to indent
 is not in the resulting string`;

So first the template string would be parsed by String.noIndentation and
subsequently by myTag.

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

Re: ... A community is writing the spec...

[Sebastian Zartner]

I don't see why you're complaining. If you don't like the features in ES6,
then just don't use them. The features of ES5 are still available.
If you want to have more strict code, then add a use strict; statement to
your code.
And if you're against adding more features to the core language, then you
should have complained several years ago at the planning of ES6.

Sebastian

On 10 September 2014 08:12, L2L 2L emanuelal...@hotmail.com wrote:

 This These feature--most of them-- would be something I see in the
 browser api... This is truly looking like w3c working group...

 ... But I don't see any chance of my words changing the direction of the
 spec Especially when you consider the original designer of the language
 steering this course...

 So in term, if you can't beat them, change them, might as well aid them
 --in what I feel to be In truth, the destruction of the original syntax,
 by the original creature of the language... Kinda wish they had a flag for
 these new syntax to be set... At least than, those who are toward the
 originally syntax style, would feel some sort of preservation for it--
 In their quest to farther add on to ES as a --application-- language.

 --as duo to a private email by /be. This to me is not trolling, I'm
 responding to this person who respond two times to my post... So in terms,
 I should not have to worry about being banned from the mailing list cause
 of this message.

 E-S4L
 N-S4L

 On Sep 10, 2014, at 1:17 AM, Axel Rauschmayer a...@rauschma.de wrote:

 Now is second half of 2014, and lots of issues are not closed yet, from
 what I see.


 The spec already looks pretty complete to me and Traceur and TypeScript do
 a pretty good job of letting you use ES6 today.

 As previously announced here, the current schedule is to be finished by
 the end of the year, to start the publication process in March 2014 and to
 have a standard by June 2014.

 I got delusioned as well.

 Isn't the model of big new editions of spec over; in the times we live
 now, with two-week frequent releases? I think ES6 will never see the light
 when taken from this approach. That's why, shouldn't the release policy be
 changed so that:


 It has already changed, but not for ES6. ECMAScript 7 and later will have
 fixed release dates. Only features that are ready at a given date will be
 included.
 Background: https://github.com/tc39/ecma262

 --
 Dr. Axel Rauschmayer
 a...@rauschma.de
 rauschma.de




 ___
 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: Multiline template strings that don't break indentation

[Sebastian Zartner]

On 9 September 2014 16:51, Allen Wirfs-Brock al...@wirfs-brock.com wrote:

 Well, just for fun

 const N = \n;  //maybe we could find evocative unicode name.
 var a = `This is a template string. ${
N}Even though each line is indented to keep the ${
N}code neat and tidy, the white space used to indent ${
N}is not in the resulting string`;


To me this looks still somewhat hacky.
Couldn't a simple keyword be added at the the end of a template string?
So it would be something like this:

var a = `This is a template string.
 Even though each line is indented to keep the
 code neat and tidy, the white space used to indent
 is not in the resulting string` keepindentation;

This would explicitly keep the spaces at the beginning of each line while
without the keyword they would be removed. Of course the keyword may also
indicate the opposite depending on parsing would be chosen as default.
Surely the name for this keyword is not optimal yet and would need to be
discussed.

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

Re: standardizing Error.stack or equivalent

[Sebastian Zartner]

 Hi John, supposedly 
 https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript
 and 
 http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/#toc-sourceurl
 document the emerging de facto std for providing this name to the existing
 API. However, I have not seen it work on any browser. See point #5 at 
 https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html. Am
 I doing something wrong here that account for my not seeing this, or does
 it in fact not work anywhere?


sourceURL and displayName are also working in Firefox. Not consistently
yet, though. FWIW Firebug is making use of these in it's 2.0 alpha 1
version. See
http://www.softwareishard.com/blog/firebug/firebug-2-support-for-dynamic-scripts/
.
Would be great if these could be standardized.

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

Re: Array.prototype.contains

[Sebastian Zartner]

   But it seems the thread fizzled out a couple years ago, and
 Array.prototype.contains didn't seem to make its way into ES6. That seems
 odd, since we do have String.prototype.contains, and it seemed like it was
 desirable for DOM.

 The DOM won't inherit from it directly, shall it?


Why not? A use case would be to check whether a specific node is within a
NodeList.

  It's also a standard utility function in several libraries.

  Was it left out on purpose? If so, what was the justification?

 I predict code like this without it:

 ''.contains.call([1, 2, 3], 2);  // true

 .indexOf === -1 works today for this use case and will continue to.
 I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of
 .contains() though.


While .indexOf() just gets you the index of one item, .contains() could
even be extended to allow to check whether an array contains several items.
E.g.

.contains([1, 2, 3], [1, 3]) // true
.contains([1, 2, 3], [1, 4]) // false

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

Re: Add regular expressions lookbehind

[Sebastian Zartner]

As I understand it the problem with lookbehinds are not parentheses but
variable lengths. Therefore many regular expression flavors only allow
fixed-length lookbehinds[1], which could also be the restriction within
ECMAScript for now. This restriction could then be addressed at a later
point.

 Backtrack into capturing results?
Seems like at least PCRE does that. for parenthesed parts within
lookbehinds.

Sebastian

[1] http://www.regular-expressions.info/lookaround.html#limitbehind


On 1 October 2013 00:55, Waldemar Horwat walde...@google.com wrote:

 No one has yet submitted a well-defined proposal for lookbehinds on the
 table.  Lookbehinds are difficult to translate into the language used by
 the spec and get quite fuzzy when the order of evaluation of parts of the
 regexp matters, which is what happens if capturing parentheses are
 involved.  Where do you start looking for the lookbehind?  Shortest first,
 longest first, or reverse string match?  Greedy or not?  Backtrack into
 capturing results?

 Waldemar



 On 09/28/2013 01:54 PM, Sebastian Zartner wrote:

 I wonder if the discussion about lookbehinds[1] and Marc Harter's
 proposal for them[2] in the past led to anything.
 I'd really like to see these implemented in ECMAScript specification and
 it seems I am not the only one.[3][4][5] This even caused people to try to
 mimic them.[6]
 So I wanted to pick up the discussion again and ask, what info was
 missing that they didn't get specified?

 Sebastian

 [1] https://mail.mozilla.org/**pipermail/es-discuss/2010-**
 November/012164.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2010-November/012164.html
 [2] https://docs.google.com/**document/pub?id=**
 1EUHvr1SC72g6OPo5fJjelVESpd4nI**0D5NQpF3oUO5UMhttps://docs.google.com/document/pub?id=1EUHvr1SC72g6OPo5fJjelVESpd4nI0D5NQpF3oUO5UM
 [3] http://stackoverflow.com/**questions/12273112/will-js-**
 regex-ever-get-lookbehindhttp://stackoverflow.com/questions/12273112/will-js-regex-ever-get-lookbehind
 [4] http://stackoverflow.com/**questions/13993793/error-**
 using-both-lookahead-and-look-**behind-regexhttp://stackoverflow.com/questions/13993793/error-using-both-lookahead-and-look-behind-regex
 [5] 
 http://regexadvice.com/forums/**thread/85210.aspxhttp://regexadvice.com/forums/thread/85210.aspx
 [6] http://blog.stevenlevithan.**com/archives/mimic-lookbehind-**
 javascripthttp://blog.stevenlevithan.com/archives/mimic-lookbehind-javascript


 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss



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

Re: Add regular expressions lookbehind

[Sebastian Zartner]

I can try to help, though my time and technical knowledge about regexp
implementations are limited. So wouldn't someone of the people, who already
implemented a working regexp engine, be a better help? Did somebody of you
ever contact the e.g. the people behind PCRE?

Sebastian


On 2 October 2013 18:35, Brendan Eich bren...@mozilla.com wrote:

 I think this is right, we need help and are open to it from someone who
 can lift the weight. Waldemar may be able to help, I'm not sure how much
 (but he wrote the ES3 regexp spec, so at least as reviewer he is a key part
 of the solution).

 Sebastian, if you have time to help, that would be tremendous.

 /be

  Jason Orendorff 
 mailto:jason.orendorff@gmail.**comjason.orendo...@gmail.com
 
 October 2, 2013 5:15 AM

 Sebastian,

 Here is how I interpret Waldemar's post:

 On Mon, Sep 30, 2013 at 5:55 PM, Waldemar Horwatwalde...@google.com
  wrote:

 No one has yet submitted a well-defined proposal for lookbehinds on the
 table. Lookbehinds are difficult to translate into the language used by
 the
 spec [...]


 This is the real problem. No one has taken on the work. It's a fair
 amount of very technical work.

  [...] and get quite fuzzy when the order of evaluation of parts of the
 regexp
 matters, which is what happens if capturing parentheses are involved.
  Where
 do you start looking for the lookbehind?  Shortest first, longest first,
 or
 reverse string match?  Greedy or not?  Backtrack into capturing results?


 Sebastian, as you pointed out, these technical points have all been
 addressed one way or another in practice. My guess is that TC39
 *would* accept some commonly-implemented lookbehind behavior, if
 someone put up the work. I could be wrong.

 -j
 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss

 Waldemar Horwat mailto:walde...@google.com
 September 30, 2013 3:55 PM
 No one has yet submitted a well-defined proposal for lookbehinds on the
 table.  Lookbehinds are difficult to translate into the language used by
 the spec and get quite fuzzy when the order of evaluation of parts of the
 regexp matters, which is what happens if capturing parentheses are
 involved.  Where do you start looking for the lookbehind?  Shortest first,
 longest first, or reverse string match?  Greedy or not?  Backtrack into
 capturing results?

 Waldemar





 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss

 Sebastian Zartner 
 mailto:sebastianzartner@**gmail.comsebastianzart...@gmail.com
 
 September 28, 2013 1:54 PM

 I wonder if the discussion about lookbehinds[1] and Marc Harter's
 proposal for them[2] in the past led to anything.
 I'd really like to see these implemented in ECMAScript specification and
 it seems I am not the only one.[3][4][5] This even caused people to try to
 mimic them.[6]
 So I wanted to pick up the discussion again and ask, what info was
 missing that they didn't get specified?

 Sebastian

 [1] https://mail.mozilla.org/**pipermail/es-discuss/2010-**
 November/012164.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2010-November/012164.html
 [2] https://docs.google.com/**document/pub?id=**
 1EUHvr1SC72g6OPo5fJjelVESpd4nI**0D5NQpF3oUO5UMhttps://docs.google.com/document/pub?id=1EUHvr1SC72g6OPo5fJjelVESpd4nI0D5NQpF3oUO5UM
 [3] http://stackoverflow.com/**questions/12273112/will-js-**
 regex-ever-get-lookbehindhttp://stackoverflow.com/questions/12273112/will-js-regex-ever-get-lookbehind
 [4] http://stackoverflow.com/**questions/13993793/error-**
 using-both-lookahead-and-look-**behind-regexhttp://stackoverflow.com/questions/13993793/error-using-both-lookahead-and-look-behind-regex
 [5] 
 http://regexadvice.com/forums/**thread/85210.aspxhttp://regexadvice.com/forums/thread/85210.aspx
 [6] http://blog.stevenlevithan.**com/archives/mimic-lookbehind-**
 javascripthttp://blog.stevenlevithan.com/archives/mimic-lookbehind-javascript
 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss


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

Add regular expressions lookbehind

[Sebastian Zartner]

I wonder if the discussion about lookbehinds[1] and Marc Harter's proposal
for them[2] in the past led to anything.
I'd really like to see these implemented in ECMAScript specification and it
seems I am not the only one.[3][4][5] This even caused people to try to
mimic them.[6]
So I wanted to pick up the discussion again and ask, what info was missing
that they didn't get specified?

Sebastian

[1] https://mail.mozilla.org/pipermail/es-discuss/2010-November/012164.html
[2]
https://docs.google.com/document/pub?id=1EUHvr1SC72g6OPo5fJjelVESpd4nI0D5NQpF3oUO5UM
[3]
http://stackoverflow.com/questions/12273112/will-js-regex-ever-get-lookbehind
[4]
http://stackoverflow.com/questions/13993793/error-using-both-lookahead-and-look-behind-regex
[5] http://regexadvice.com/forums/thread/85210.aspx
[6] http://blog.stevenlevithan.com/archives/mimic-lookbehind-javascript
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Continuing woes in reading the ES6 spec language

[Sebastian Zartner]

  * You can pass undefined to trigger defaulting -- this is important for
 composition / delegation.
 No, it's a terrible feature :D i'm unaware of any language that supports
 arbitrary ordering of arguments.


FWIW, ColdFusion allows to call functions with named parameters in an
arbitrary order.[1] This has one benefit: You can simply skip arguments in
the middle instead of having to provide a default value for them the call.

Transferred to JS syntax that would be:

function sayHello(a, b=true, c=people)
{
return b ? a +   + c : a;
}

foo(a=Hey, c=there!); // returns Hey there!

(Excuse the poor example, but it should be enough to understand the idea
behind it.)

Sebastian

[1]
http://stackoverflow.com/questions/1071396/how-to-specify-only-some-optional-arguments-when-calling-function-in-coldfusion
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss