RE: The name of Array.prototype.includes
https://github.com/tc39/Array.prototype.includes#why-includes-instead-of-has > -Original Message- > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Axel > Rauschmayer > Sent: Tuesday, October 13, 2015 16:33 > To: es-discuss mailing list > Subject: The name of Array.prototype.includes > > There are two existing methods that are loosely similar to > `Array.prototype.includes()`: > > 1. `String.prototype.includes()` > 2. `Set.prototype.has()` > > Isn’t #2 more similar than #1? Shouldn’t the method be called > `Array.prototype.has`, then? > > -- > 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
The name of Array.prototype.includes
There are two existing methods that are loosely similar to `Array.prototype.includes()`: 1. `String.prototype.includes()` 2. `Set.prototype.has()` Isn’t #2 more similar than #1? Shouldn’t the method be called `Array.prototype.has`, then? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Swift style syntax
On 10/13/2015 10:27, Isiah Meadows wrote: Steve, I have little problem with whatever ends up the case, as long as it's shorter than `(x, y) => x + y`. The current idea was inspired by Swift's `list.sort(>)` and `list.reduce(0, +)`. I second the concern with this being far too full of hazards to carry its weight. Let's say you allow something like the list.reduce(0, +) syntax for the various arithmetic operators. Then we get to the fun ones: list.reduce(0, /) /x Oops, you've just started a regular expression. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Look-behind proposal in trouble
Erik Corry wrote on Tue, 13 Oct 2015 at 11:18:48 +0200:
> Yes, that makes sense.
>
> This could be fixed by removing {n} loops from positive lookbehinds. Or by
> doing the .NET-style back-references immediately.
Personally, I am reluctant to remove any feature from the current
proposal intentionally for a future proposal that it is uncertain
whether it really comes or not. It might end up only making lookbehinds
of ECMAScript and ones of Perl 5 incompatible.
>> On 10/10/2015 03:48, Erik Corry wrote:
>>
>>>
>>> On Sat, Oct 10, 2015 at 12:47 AM, Waldemar Horwat wrote:
>>>
>>> It's not a superset. Captures would match differently.
>>>
>>>
>>> Can you elaborate? How would they be different?
>>>
>>
>> If you have a capture inside a loop (controlled, say, by {n}), one of the
>> proposals would capture the first instance, while the other proposal would
>> capture the last instance.
I was missing that point. I just confirmed that
perl -e "$a = 'abcdef'; $a =~ /(?<=.(.){2}.)./; print $1;"
returned 'c' whereas .NET returned 'b'. Implementation based on my
proposal would return the same result as Perl 5.
By the way, at one point in this thread, I moved some email addresses
from To to Cc when sending my reply. But somehow several of them had
disappeared from the Cc field in the delivered email while they all
remain in a copy in my sent-email folder. I apologize to those who
received disconnected emails in this thread.
Regards,
Nozomu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Look-behind proposal in trouble
On 10/13/2015 02:18, Erik Corry wrote:
Yes, that makes sense.
This could be fixed by removing {n} loops from positive lookbehinds. Or by
doing the .NET-style back-references immediately.
I think it would be cleanest to do the full reverse-order matching (what I
think you're calling .NET-style) from the start.
Waldemar
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Swift style syntax
Ok... I don't have a device to properly learn Swift with, as I don't own or have easy access to a Mac. On Tue, Oct 13, 2015, 13:48 Mohsen Azimi wrote: > > > > > > > > Isiah, > > In Swift it's not allowed to assign an operator so the ambiguous case you > brought up can be avoided by not allowing assigning operators. > > ``` > let x = +; // not allowed > ``` > > Or it's not allowed to store operators in dictionaries: > > ``` > > let dic = [ > "add": + > ]; > > ``` > The only place (as far as I know) you can pass operators as functions is > in arguments list of a function call. I don't know why but it doesn't work > with unary operators either: > ``` > let nums = [1,3,4]; > > > numsnums.map(++) // error > > ``` > > On Tue, Oct 13, 2015 at 10:27 AM Isiah Meadows > wrote: > >> Steve, I have little problem with whatever ends up the case, as long as >> it's shorter than `(x, y) => x + y`. The current idea was inspired by >> Swift's `list.sort(>)` and `list.reduce(0, +)`. >> >> On Tue, Oct 13, 2015, 12:34 Steve Fink wrote: >> >>> On 10/12/2015 11:06 PM, Isiah Meadows wrote: >>> > >>> > +1 for operators as functions (I frequently is them in languages that >>> > have them), but there is an ambiguous case that frequently gets me: >>> > does `(-)` represent subtraction or negation. It's usually the former >>> > in languages with operators as functions. >>> > >>> > But here's a couple other potential syntactical ambiguities, dealing >>> > with ASI: >>> > >>> > ```js >>> > // Is this `x => f(x)` or `x = (>); f(x)` >>> > x => >>> > f(x) >>> > >>> > // Is this `-x` or `-; x`? >>> > - >>> > x >>> > ``` >>> > >>> > Those can be addressed with a cover production to be used for >>> > expression statements and direct value assignment, requiring >>> > parentheses to clarify the latter case in each. >>> > >>> > A similar ambiguity problem, arguably harder to resolve, is partially >>> > applied subtraction, such as `(- 2)`. Is that a -2 or is it equivalent >>> > to `x => x - 2`? I will caution on this idea, as I know that's the >>> > next logical step. >>> > >>> >>> It it just me? I find all this talk of bare operators to be >>> completely... uh, I'll go with "inadvisable". >>> >>> I can believe that you could carve out an unambiguous path through the >>> grammar. But (a) it's going the way of line noise, (b) it uses up lots >>> of possibilities for future expansion on something that isn't all that >>> useful in the first place, and (c) it seems to be choosing concise >>> syntax over readability in a big way. >>> >>> C++ has an 'operator' keyword (and even then it comes out pretty ugly -- >>> operator()(), anyone?) Perl6 has better syntax (syntax syntax?) for this: >>> >>> infix:<+> >>> circumfix:«( )» >>> >>> or whatever. And of course Python uses double __underscores__ with ASCII >>> operator names. All those are preferable to bare operators, to me. >>> >>> -compose(+, *)(++x, +(3, 4), --y) - (3 + 4) - -(1, 2); >>> >>> I don't really *want* that to parse! At least make it >>> >>>list.sort(#`>`); >>> >>> or something. >>> >>> ___ >>> 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: Swift style syntax
Isiah, In Swift it's not allowed to assign an operator so the ambiguous case you brought up can be avoided by not allowing assigning operators. ``` let x = +; // not allowed ``` Or it's not allowed to store operators in dictionaries: ``` let dic = [ "add": + ]; ``` The only place (as far as I know) you can pass operators as functions is in arguments list of a function call. I don't know why but it doesn't work with unary operators either: ``` let nums = [1,3,4]; numsnums.map(++) // error ``` On Tue, Oct 13, 2015 at 10:27 AM Isiah Meadows wrote: > Steve, I have little problem with whatever ends up the case, as long as > it's shorter than `(x, y) => x + y`. The current idea was inspired by > Swift's `list.sort(>)` and `list.reduce(0, +)`. > > On Tue, Oct 13, 2015, 12:34 Steve Fink wrote: > >> On 10/12/2015 11:06 PM, Isiah Meadows wrote: >> > >> > +1 for operators as functions (I frequently is them in languages that >> > have them), but there is an ambiguous case that frequently gets me: >> > does `(-)` represent subtraction or negation. It's usually the former >> > in languages with operators as functions. >> > >> > But here's a couple other potential syntactical ambiguities, dealing >> > with ASI: >> > >> > ```js >> > // Is this `x => f(x)` or `x = (>); f(x)` >> > x => >> > f(x) >> > >> > // Is this `-x` or `-; x`? >> > - >> > x >> > ``` >> > >> > Those can be addressed with a cover production to be used for >> > expression statements and direct value assignment, requiring >> > parentheses to clarify the latter case in each. >> > >> > A similar ambiguity problem, arguably harder to resolve, is partially >> > applied subtraction, such as `(- 2)`. Is that a -2 or is it equivalent >> > to `x => x - 2`? I will caution on this idea, as I know that's the >> > next logical step. >> > >> >> It it just me? I find all this talk of bare operators to be >> completely... uh, I'll go with "inadvisable". >> >> I can believe that you could carve out an unambiguous path through the >> grammar. But (a) it's going the way of line noise, (b) it uses up lots >> of possibilities for future expansion on something that isn't all that >> useful in the first place, and (c) it seems to be choosing concise >> syntax over readability in a big way. >> >> C++ has an 'operator' keyword (and even then it comes out pretty ugly -- >> operator()(), anyone?) Perl6 has better syntax (syntax syntax?) for this: >> >> infix:<+> >> circumfix:«( )» >> >> or whatever. And of course Python uses double __underscores__ with ASCII >> operator names. All those are preferable to bare operators, to me. >> >> -compose(+, *)(++x, +(3, 4), --y) - (3 + 4) - -(1, 2); >> >> I don't really *want* that to parse! At least make it >> >>list.sort(#`>`); >> >> or something. >> >> ___ >> 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: Swift style syntax
Steve, I have little problem with whatever ends up the case, as long as it's shorter than `(x, y) => x + y`. The current idea was inspired by Swift's `list.sort(>)` and `list.reduce(0, +)`. On Tue, Oct 13, 2015, 12:34 Steve Fink wrote: > On 10/12/2015 11:06 PM, Isiah Meadows wrote: > > > > +1 for operators as functions (I frequently is them in languages that > > have them), but there is an ambiguous case that frequently gets me: > > does `(-)` represent subtraction or negation. It's usually the former > > in languages with operators as functions. > > > > But here's a couple other potential syntactical ambiguities, dealing > > with ASI: > > > > ```js > > // Is this `x => f(x)` or `x = (>); f(x)` > > x => > > f(x) > > > > // Is this `-x` or `-; x`? > > - > > x > > ``` > > > > Those can be addressed with a cover production to be used for > > expression statements and direct value assignment, requiring > > parentheses to clarify the latter case in each. > > > > A similar ambiguity problem, arguably harder to resolve, is partially > > applied subtraction, such as `(- 2)`. Is that a -2 or is it equivalent > > to `x => x - 2`? I will caution on this idea, as I know that's the > > next logical step. > > > > It it just me? I find all this talk of bare operators to be > completely... uh, I'll go with "inadvisable". > > I can believe that you could carve out an unambiguous path through the > grammar. But (a) it's going the way of line noise, (b) it uses up lots > of possibilities for future expansion on something that isn't all that > useful in the first place, and (c) it seems to be choosing concise > syntax over readability in a big way. > > C++ has an 'operator' keyword (and even then it comes out pretty ugly -- > operator()(), anyone?) Perl6 has better syntax (syntax syntax?) for this: > > infix:<+> > circumfix:«( )» > > or whatever. And of course Python uses double __underscores__ with ASCII > operator names. All those are preferable to bare operators, to me. > > -compose(+, *)(++x, +(3, 4), --y) - (3 + 4) - -(1, 2); > > I don't really *want* that to parse! At least make it > >list.sort(#`>`); > > or something. > > ___ > 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: Swift style syntax
On 10/12/2015 11:06 PM, Isiah Meadows wrote: +1 for operators as functions (I frequently is them in languages that have them), but there is an ambiguous case that frequently gets me: does `(-)` represent subtraction or negation. It's usually the former in languages with operators as functions. But here's a couple other potential syntactical ambiguities, dealing with ASI: ```js // Is this `x => f(x)` or `x = (>); f(x)` x => f(x) // Is this `-x` or `-; x`? - x ``` Those can be addressed with a cover production to be used for expression statements and direct value assignment, requiring parentheses to clarify the latter case in each. A similar ambiguity problem, arguably harder to resolve, is partially applied subtraction, such as `(- 2)`. Is that a -2 or is it equivalent to `x => x - 2`? I will caution on this idea, as I know that's the next logical step. It it just me? I find all this talk of bare operators to be completely... uh, I'll go with "inadvisable". I can believe that you could carve out an unambiguous path through the grammar. But (a) it's going the way of line noise, (b) it uses up lots of possibilities for future expansion on something that isn't all that useful in the first place, and (c) it seems to be choosing concise syntax over readability in a big way. C++ has an 'operator' keyword (and even then it comes out pretty ugly -- operator()(), anyone?) Perl6 has better syntax (syntax syntax?) for this: infix:<+> circumfix:«( )» or whatever. And of course Python uses double __underscores__ with ASCII operator names. All those are preferable to bare operators, to me. -compose(+, *)(++x, +(3, 4), --y) - (3 + 4) - -(1, 2); I don't really *want* that to parse! At least make it list.sort(#`>`); or something. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Swift style syntax
I failed to mention that clearly enough... In most functional languages,
that's binary. And I think that should be the same for JS. It's surprising
otherwise.
I'd say the closest precedent here I know of would be LiveScript, where the
operator is treated as binary when used as a function. Most functional
languages have separate functions for subtraction and negation, including
Haskell (`-` vs `negate`) and OCaml (`-` and `.-` vs `negate` and
`fnegate`).
On Tue, Oct 13, 2015, 04:13 Andreas Rossberg wrote:
> All this is well-known from functional languages, with well-known
> solutions. The only real problem is:
>
> let f = (-)
>
> Is this unary or binary `-`?
>
> On 13 October 2015 at 08:06, Isiah Meadows wrote:
> > +1 for operators as functions (I frequently is them in languages that
> have
> > them), but there is an ambiguous case that frequently gets me: does `(-)`
> > represent subtraction or negation. It's usually the former in languages
> with
> > operators as functions.
> >
> > But here's a couple other potential syntactical ambiguities, dealing with
> > ASI:
> >
> > ```js
> > // Is this `x => f(x)` or `x = (>); f(x)`
> > x =>
> > f(x)
> >
> > // Is this `-x` or `-; x`?
> > -
> > x
> > ```
> >
> > Those can be addressed with a cover production to be used for expression
> > statements and direct value assignment, requiring parentheses to clarify
> the
> > latter case in each.
> >
> > A similar ambiguity problem, arguably harder to resolve, is partially
> > applied subtraction, such as `(- 2)`. Is that a -2 or is it equivalent
> to `x
> > => x - 2`? I will caution on this idea, as I know that's the next logical
> > step.
> >
> >
> > On Mon, Oct 12, 2015, 06:43 Thomas
> wrote:
> >>
> >>
> >> Is it possible to extend JavaScript syntax to support Swift style block
> >> syntax[1]?
> >>
> >> In Swift it's possible to omit return keyword
> >> ```
> >>
> >> reversed = names.sort( { s1, s2 in s1 > s2 } )
> >>
> >> ```
> >>
> >>
> >> As you note below this is already possible in es6, and might I add, has
> >> much more intuitive syntax in Es6. The swift syntax looks like a list
> >> comprehension gone wrong.
> >>
> >> or omit argument declaration like this:
> >>
> >> ```
> >>
> >> reversed = names.sort( { $0 > $1 } )
> >>
> >> ```
> >>
> >>
> >> I for one think this is a bad idea - use rest arguments instead. It's
> >> pretty terrible as far as readability goes, although I'd like to see
> more
> >> examples of it being used in Swift code.
> >>
> >> or apply an operator to arguments of a function
> >>
> >> ```
> >>
> >> reversed = names.sort(>)
> >>
> >> ```
> >>
> >>
> >> This might actually be possible - I can't think of any ambiguous
> >> situations for passing operators as if they were first class functions.
> If
> >> it is possible, I'd like to see this done.
> >>
> >> We have the first feature in ES2015 already:
> >>
> >> ```
> >> let sorted = names.sort((a, b)=> a > b);
> >> ```
> >>
> >> But for omitting argument declaration we need to find an alternative to
> >> $0, $1... since those are valid variable names in JS. Maybe we can use
> #0,
> >> #1... instead.
> >>
> >> This is very useful for functional programming aspect of JS. For example
> >> in a filter function:
> >>
> >> ```
> >> let passed = objs.filter(#0.passed)
> >> ```
> >>
> >>
> >> [1][
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Closures.html
> ]
> >>
> >> ___
> >> 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: Look-behind proposal in trouble
Yes, that makes sense.
This could be fixed by removing {n} loops from positive lookbehinds. Or by
doing the .NET-style back-references immediately.
On Mon, Oct 12, 2015 at 10:01 PM, Waldemar Horwat
wrote:
> On 10/10/2015 03:48, Erik Corry wrote:
>
>>
>>
>> On Sat, Oct 10, 2015 at 12:47 AM, Waldemar Horwat > > wrote:
>>
>> It's not a superset. Captures would match differently.
>>
>>
>> Can you elaborate? How would they be different?
>>
>
> If you have a capture inside a loop (controlled, say, by {n}), one of the
> proposals would capture the first instance, while the other proposal would
> capture the last instance.
>
> Waldemar
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Swift style syntax
All this is well-known from functional languages, with well-known
solutions. The only real problem is:
let f = (-)
Is this unary or binary `-`?
On 13 October 2015 at 08:06, Isiah Meadows wrote:
> +1 for operators as functions (I frequently is them in languages that have
> them), but there is an ambiguous case that frequently gets me: does `(-)`
> represent subtraction or negation. It's usually the former in languages with
> operators as functions.
>
> But here's a couple other potential syntactical ambiguities, dealing with
> ASI:
>
> ```js
> // Is this `x => f(x)` or `x = (>); f(x)`
> x =>
> f(x)
>
> // Is this `-x` or `-; x`?
> -
> x
> ```
>
> Those can be addressed with a cover production to be used for expression
> statements and direct value assignment, requiring parentheses to clarify the
> latter case in each.
>
> A similar ambiguity problem, arguably harder to resolve, is partially
> applied subtraction, such as `(- 2)`. Is that a -2 or is it equivalent to `x
> => x - 2`? I will caution on this idea, as I know that's the next logical
> step.
>
>
> On Mon, Oct 12, 2015, 06:43 Thomas wrote:
>>
>>
>> Is it possible to extend JavaScript syntax to support Swift style block
>> syntax[1]?
>>
>> In Swift it's possible to omit return keyword
>> ```
>>
>> reversed = names.sort( { s1, s2 in s1 > s2 } )
>>
>> ```
>>
>>
>> As you note below this is already possible in es6, and might I add, has
>> much more intuitive syntax in Es6. The swift syntax looks like a list
>> comprehension gone wrong.
>>
>> or omit argument declaration like this:
>>
>> ```
>>
>> reversed = names.sort( { $0 > $1 } )
>>
>> ```
>>
>>
>> I for one think this is a bad idea - use rest arguments instead. It's
>> pretty terrible as far as readability goes, although I'd like to see more
>> examples of it being used in Swift code.
>>
>> or apply an operator to arguments of a function
>>
>> ```
>>
>> reversed = names.sort(>)
>>
>> ```
>>
>>
>> This might actually be possible - I can't think of any ambiguous
>> situations for passing operators as if they were first class functions. If
>> it is possible, I'd like to see this done.
>>
>> We have the first feature in ES2015 already:
>>
>> ```
>> let sorted = names.sort((a, b)=> a > b);
>> ```
>>
>> But for omitting argument declaration we need to find an alternative to
>> $0, $1... since those are valid variable names in JS. Maybe we can use #0,
>> #1... instead.
>>
>> This is very useful for functional programming aspect of JS. For example
>> in a filter function:
>>
>> ```
>> let passed = objs.filter(#0.passed)
>> ```
>>
>>
>> [1][https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Closures.html]
>>
>> ___
>> 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
