Re: let function
On 2015-05-19 06:09, Bergi a.d.be...@web.de writes: Alternatively just use a single equals sign with a parameter list: let f(x) = y let f() = y This looks very nice indeed. Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 signature.asc Description: PGP signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Look-behind proposal
Allen Wirfs-Brock wrote on Mon, 18 May 2015, at 15:08:13 -0700:
On May 18, 2015, at 2:20 PM, Jason Orendorff wrote:
On Mon, May 18, 2015 at 8:50 AM, Nozomu Katō wrote:
It is a Syntax Error if Disjunction contains Quantifier ::
QuantifierPrefix except QuantifierPrefix :: { DecimalDigits }.
Backreferences must be ruled out, too.
Yes, I forgot to mention backreferences in my proposal. I have modified
my proposal to reflect this.
1. Let n be the exact number of the sequence of code points which
Disjunction matches [NOTE].
I don't think a NOTE is strong enough for spec purposes, so you can
improve the proposal by adding a Static Semantics: section that
formally specifies this.
The spec uses attribute grammars for dozens of things like this, where
some piece of information has to be determined from the parse tree.
See Static Semantics: ElisionWidth for a simple example.
Thank you. This sample is helpful. I was unsure how to describe this
information.
The proposal also needs to follow the conventions and terminology of
the ES6 RegExp spec. In particular, the RegExp pattern matching
algorithms use the term character with a specific meaning rather
than using code unit or code point
(see
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-pattern-semantics ).
It does this so that the same algorithms can be use to describe the
matching semantic of both normal and unicode patterns. Any
extensions also will need t work with both kinds of patterns.
Based on these comments, I re-submit a modified proposal:
Abstract
Basically, the evaluation for the look-behind assertion is performed by
rewind the target sequence and do the same thing as the look-ahead
assertion:
1. When compiling a regular expression pattern, count the total number
of PatternCharacter and . and \ AtomEscape and CharacterClass in
Disjunction per look-behind assertion. Each Atom may be followed by
{n}, but may not be followed by the other quantifiers.
2. When a look-behind assertion evaluated, rewind the target sequence
by that number and evaluate as if the look-ahead assertion from
that point.
--
Static Semantics: Early Errors
Assertion :: ( ? = Disjunction )
Assertion :: ( ? ! Disjunction )
It is a Syntax Error if Disjunction contains Quantifier ::
QuantifierPrefix except QuantifierPrefix :: { DecimalDigits }.
It is a Syntax Error if Disjunction contains AtomEscape ::
DecimalEscape.
When Disjunction is separated by the | regular expression, if the
number of the sequence of characters which the left Alternative
matches and the number of the sequence of characters which the right
Disjunction matches are different, then it is a Syntax Error.
Static Semantics: DisjunctionSize
1. return the total sum of the following Atoms in the Disjunction:
a. Atom :: PatternCharacter
b. Atom :: .
c. Atom :: \ AtomEscape except AtomEscape :: DecimalEscape
d. Atom :: CharacterClass
If an Atom is followed by a QuantifierPrefix :: { DecimalDigits },
then that Atom is counted as the number of DecimalDigits instead of
one. If the Disjunction contains an Atom :: ( Disjunction ) or
Atom :: ( ? : Disjunction ) that is followed by a QuantifierPrefix
:: { DecimalDigits }, then the total number of the sequence of Atoms
in that inner-Disjunction is multiplied by the number of
DecimalDigits.
Assertion
The production Assertion :: ( ? = Disjunction ) evaluates as follows:
1. Evaluate Disjunction to obtain a Matcher m.
2. Return an internal Matcher closure that takes two arguments, a State
x and a Continuation c, and performs the following steps:
1. Let n be the result of DisjunctionSize for Disjunction.
2. Let xe be x's endIndex.
3. If xe n, return failure.
4. Let xcap be x's captures List.
5. Let y be the State (xe-n, xcap).
6. Let d be a Continuation that always returns its State argument as a
successful MatchResult.
7. Call m(y, d) and let r be its result.
8. If r is failure, return failure.
9. Let z be r's State.
10. Let zcap be z's captures List.
11. Let a be the State (xe, zcap).
12. Call c(a) and return its result.
The production Assertion :: ( ? ! Disjunction ) evaluates as follows:
1. Evaluate Disjunction to obtain a Matcher m.
2. Return an internal Matcher closure that takes two arguments, a State
x and a Continuation c, and performs the following steps:
1. Let n be the result of DisjunctionSize for Disjunction.
2. Let xe be x's endIndex.
3. If xe n, then call c(x) and return its result.
4. Let xcap be x's captures List.
5. Let y be the State (xe-n, xcap).
6. Let d be a Continuation that always returns its State argument as a
successful MatchResult.
7. Call m(y, d) and let r be its result.
8. If r is not failure, return failure.
9. Call c(x) and return its result.
Nozomu
___
es-discuss mailing list
Re: Look-behind proposal
* the `s`, or `.dotall` flag: the dot `.` matches every character, including newlines; * true support of Unicode, namely: escape sequences such as `\Lu` for uppercase letter, or `\X` for grapheme cluster. Why not submit proposals for these? You are right, but procrastination and other activities... But I'll try to write some more concrete proposals for those ideas. Unlike Perl, there is no special treatment for ] that appears just after [ or [^ in RegExp of ECMAScript. Thanks to this, [^] can be used for what matches every character including newlines. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Look-behind proposal
Sorry, I accidentally posted an unfinished e-mail. I was about to add the link of a html version of my proposal to my previous post: http://www.akenotsuki.com/misc/srell/lookbehind_proposal.html Nozomu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: let function
Your point about decorators vs. hoisting is good, everyone should keep it in mind. Still doesn't mean we can't add a special form for const function, as followups aver. /be Alexander Jones wrote: On 19 May 2015 at 02:02, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: This seems like a better shorthand to discuss, compared to `let function` (which function-in-block covers already, as noted). function-in-block does not have the same semantics as the proposed let function. It hoists, thus has no TDZ, and appears to preclude a reasonable decorator syntax behaviour, and it has no provisions for const binding, i.e. const function. let f(x) = y appears attractive indeed, but by virtue of it being an arrow function, has lexical this and no prototype property. Also no generator syntax, unless I'm missing something? Cheers ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: let function
On Tue, May 19, 2015 at 12:24 PM, Steve Fink sph...@gmail.com wrote:
That visually collides with destructuring for me.
let [a, b] = foo();
let {a, b} = foo();
let f(a, b) = foo(); # Very different
I almost expect that last one to use f as a custom matcher of some sort,
given the previous two.
Well *there's* an interesting proposal. As I understand it, this corner of
the grammar is free, so custom matchers would be a possibility here.
I can imagine some interesting uses for custom data types, eg:
let pair(a, b) = foo(); // like `let {head, tail} = foo();` but with custom
type checking.
let polar(radius, angle) = point(1, 2); // custom matcher can convert
between coordinate respresentations
or even build a simple matching case statement for a recursive decent
parser:
let for_statement(init, cond, incr) = input_text;
Does that spark ideas in anyone else?
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Label statement moveable
Since we have block scope, and we have continue statement to which we can use
in loops to jump back to the conduction statement part.
Than can we consider making label stamens moveable by its name.
I'll like to say that the side effect would be sudo(pseudo) function, example:
function foo(v){
return v + 1;
}
var i = 0;
baz:{
i += 1;
}
continue baz;//same as foo(i);
console.log(i);
Note that I said sudo function. Its mobility is what of value; depending on how
JavaScript handle the continue statement in a loop to transport that effect out
side a loop.
Stripping this privilege to black scope; where the continue statement is
expanded to work only in block scope and nested block scope; to where it can
only jump to the beginning of that block or any other block scope that is
scoped to that outer block scope but not nested block scope with in the
scope... Like function.
Continue and break statement could be of more power; where we can avoid some
function call in speed matter application.
Excuse any grammar errors.
JS4Lf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: let function
On 19 May 2015 at 02:02, Brendan Eich bren...@mozilla.org wrote: This seems like a better shorthand to discuss, compared to `let function` (which function-in-block covers already, as noted). function-in-block does not have the same semantics as the proposed let function. It hoists, thus has no TDZ, and appears to preclude a reasonable decorator syntax behaviour, and it has no provisions for const binding, i.e. const function. let f(x) = y appears attractive indeed, but by virtue of it being an arrow function, has lexical this and no prototype property. Also no generator syntax, unless I'm missing something? Cheers ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: let function
function-in-block does not have the same semantics as the proposed let function. It hoists, thus has no TDZ, and appears to preclude a reasonable decorator syntax behaviour, But that would not fix the decorator/function problem. Specifically, we would not want to have a situation where let functions are decorable but function declarations are not. and it has no provisions for const binding, i.e. const function. A const function syntax was proposed during ES6 development and might still be an option. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: let function
C. Scott Ananian wrote:
On Tue, May 19, 2015 at 12:24 PM, Steve Fink sph...@gmail.com
mailto:sph...@gmail.com wrote:
That visually collides with destructuring for me.
let [a, b] = foo();
let {a, b} = foo();
let f(a, b) = foo(); # Very different
I almost expect that last one to use f as a custom matcher of some
sort, given the previous two.
Well *there's* an interesting proposal. As I understand it, this
corner of the grammar is free, so custom matchers would be a
possibility here.
I can imagine some interesting uses for custom data types, eg:
let pair(a, b) = foo(); // like `let {head, tail} = foo();` but with
custom type checking.
let polar(radius, angle) = point(1, 2); // custom matcher can convert
between coordinate respresentations
or even build a simple matching case statement for a recursive decent
parser:
let for_statement(init, cond, incr) = input_text;
Does that spark ideas in anyone else?
Sure, and we've had pattern matching on the agenda for a while (distinct
from destructuring in ES6: refutable match, richer pattern language).
http://wiki.ecmascript.org/doku.php?id=harmony:refutable_matching
(arossberg: anything newer on github?)
http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching (older
strawman from dherman)
I agree that `let f(x) = y` encroaches confusingly on pattern matching,
not let-function declaration.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: let function
Yes. I proposed it and plan to do so again. Likewise with const classes. In both cases, it imposes additional tamper-proofing restrictions along the lines of the StrongScript proposal in order to support writing defensively consistent abstractions. On Tue, May 19, 2015 at 3:02 PM, Kevin Smith zenpars...@gmail.com wrote: function-in-block does not have the same semantics as the proposed let function. It hoists, thus has no TDZ, and appears to preclude a reasonable decorator syntax behaviour, But that would not fix the decorator/function problem. Specifically, we would not want to have a situation where let functions are decorable but function declarations are not. and it has no provisions for const binding, i.e. const function. A const function syntax was proposed during ES6 development and might still be an option. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: let function
On 05/19/2015 12:23 AM, Alan Schmitt wrote:
On 2015-05-19 06:09, Bergi a.d.be...@web.de writes:
Alternatively just use a single equals sign with a parameter list:
let f(x) = y
let f() = y
This looks very nice indeed.
That visually collides with destructuring for me.
let [a, b] = foo();
let {a, b} = foo();
let f(a, b) = foo(); # Very different
I almost expect that last one to use f as a custom matcher of some sort,
given the previous two.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
