On 21 May 2011 01:16, felix feli...@gmail.com wrote:
how about the fish operator , easy to type.
Whow, apparently, you are not cursed with a German keyboard. ;)
Seriously, easy to type is an argument that is highly subjective to
i18n-related concerns. The majority of JS programmers does not
Hi,
I think there lot's of proposals for ES.next that require syntax extensions,
which is probably worth if new functionality added or shortens most commonly
used constructs like functions (were no other option is available). In case of
this proposal:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,
I think there lot's of proposals for ES.next that require syntax
extensions, which is probably worth if new functionality added or
shortens most commonly used constructs like functions (were no other
option is available). In case of this
On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,
I think there lot's of proposals for ES.next that require syntax
extensions, which is probably worth if new functionality added or shortens
most commonly used
On May 22, 2011, at 10:15 PM, Kam Kasravi wrote:
Is this valid?
function Person(a) {
this.age = a;
}
Person.prototype.myage = {|| this.age};
Block-lambda, per Tennent's Correspondence Principle as cited, uses the same
this as if you moved the code inside the {|| ... } outside. This is
On 23/05/2011, at 07:15, Kam Kasravi wrote:
Is this valid?
function Person(a) {
this.age = a;
}
Person.prototype.myage = {|| this.age};
function info(myage) {
console.log('my age is '+myage());
}
info(new Person(10).myage);
info(new Person(12).myage);
If it's valid (I don't
On 20 May 2011 18:00, David Herman dher...@mozilla.com wrote:
I think modules are a construct that evaluates to an object is the wrong
way to think about them. Syntactic modules are a second-class construct that
is not an expression. You can reflect on modules at runtime, and that
On 20 May 2011 15:42, Mark S. Miller erig...@google.com wrote:
Modules aren't generative.
If you mean that you cannot create several objects from them, then
yes, but see my reply to Dave.
However, I was primarily wondering about static members, which don't
provide any generativity in that sense
On May 23, 2011, at 7:06 AM, Jorge wrote:
On 23/05/2011, at 07:15, Kam Kasravi wrote:
Is this valid?
function Person(a) {
this.age = a;
}
Person.prototype.myage = {|| this.age};
function info(myage) {
console.log('my age is '+myage());
}
info(new Person(10).myage);
info(new
On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,
I think there lot's of proposals for ES.next that require syntax
extensions, which is probably worth if new
On Sun, May 22, 2011 at 7:35 PM, Brendan Eich bren...@mozilla.com wrote:
On May 22, 2011, at 5:21 PM, Isaac Schlueter wrote:
Yes, I guess we are pushing opinions at each other. I'd say that they
are that bad.
I have experience only with Ruby, not SmallTalk or E. Maybe they're
handled
On May 23, 2011, at 8:31 AM, Brendan Eich wrote:
On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
1. More syntax means larger language surface, which adds complexity more
things to remember / learn. More things to consider in ES.next.next
It's true, although not everyone learns it
On Monday, 2011-05-23 at 17:31 , Brendan Eich wrote:
On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,
I think there lot's of proposals for ES.next that require
My expectation was that that this would not be bound in the same manner as
this.myage = function() { return this.age }.bind(this); using block lambdas.
Thanks
for the clarifications below. In the block lambda strawman examples, the
surprise
is the use of return (and other goto constructs like
On May 23, 2011, at 9:04 AM, Kam Kasravi wrote:
In the block lambda strawman examples, the surprise
is the use of return (and other goto constructs like break). At least in
similar discussions related
to closures in java, Neal Grafter
(Gafter)
suggests that return and other control
On Mon, May 23, 2011 at 08:51, Brendan Eich bren...@mozilla.com wrote:
Class syntax is like a lint brush for such features. If we add it, it will
accrete more semantics (with unambiguous syntax, I hope) over time. This is
just inevitable, in my view. It makes me want to resist classes and
On Monday, 2011-05-23 at 18:14 , Isaac Schlueter wrote:
On Mon, May 23, 2011 at 08:51, Brendan Eich bren...@mozilla.com wrote:
Class syntax is like a lint brush for such features. If we add it, it will
accrete more semantics (with unambiguous syntax, I hope) over time. This is
just
Sugar is fine for defining classes (as opposed to defining types in terms of
the constructor) but I get a little worried when I see the 'extends'
keyword. I'm probably biased but I see many JavaScript trainees eager to
simulate classical inheritance because it fits right in their comfort zone.
The class syntax would be a great boon to the Closure Compiler. Much of
ADVANCED mode optimizations depends on understanding class relationships,
currently this means teaching it about each framework's extend or
inherit methods and each of their subtleties.
On Mon, May 23, 2011 at 4:10 AM,
On Monday, 2011-05-23 at 18:47 , John Lenz wrote:
The class syntax would be a great boon to the Closure Compiler. Much of
ADVANCED mode optimizations depends on understanding class relationships,
currently this means teaching it about each framework's extend or
inherit methods and each
On May 23, 2011, at 8:31 AM, Brendan Eich wrote:
On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,
I think there lot's of proposals for ES.next that require syntax
On May 23, 2011, at 9:45 AM, Angus Croll wrote:
Sugar is fine for defining classes (as opposed to defining types in terms of
the constructor) but I get a little worried when I see the 'extends'
keyword. I'm probably biased but I see many JavaScript trainees eager to
simulate classical
On May 23, 2011, at 10:03 AM, Alex Russell wrote:
(A) the boilerplate needed to set up a sub-prototype object with correct
constructor property, and
(B) the pain of doing correct super calls by hand.
I hope we can add the hazards of incorrectly adding mutable state to a
prototype and
On Mon, May 23, 2011 at 2:16 PM, Andreas Rossberg rossb...@google.comwrote:
On 20 May 2011 18:00, David Herman dher...@mozilla.com wrote:
I think modules are a construct that evaluates to an object is the
wrong way to think about them. Syntactic modules are a second-class
construct that is
On Mon, May 23, 2011 at 7:22 AM, Andreas Rossberg rossb...@google.comwrote:
On 20 May 2011 15:42, Mark S. Miller erig...@google.com wrote:
Modules aren't generative.
If you mean that you cannot create several objects from them, then
yes, but see my reply to Dave.
However, I was primarily
On Mon, May 23, 2011 at 10:42 AM, Mark S. Miller erig...@google.com wrote:
On Mon, May 23, 2011 at 2:16 PM, Andreas Rossberg rossb...@google.comwrote:
On 20 May 2011 18:00, David Herman dher...@mozilla.com wrote:
I think modules are a construct that evaluates to an object is the
wrong way
On May 23, 2011, at 10:41 AM, Brendan Eich wrote:
On May 23, 2011, at 10:03 AM, Alex Russell wrote:
(A) the boilerplate needed to set up a sub-prototype object with correct
constructor property, and
(B) the pain of doing correct super calls by hand.
I hope we can add the hazards of
On May 23, 2011, at 10:48 AM, Mark S. Miller wrote:
Static members on classes are generative merely because classes are
generative:
function makeFoo() {
return class Foo {
static x = Math.random();
//...
}
}
Your reply to Dave makes use of
1. More syntax means larger language surface, which adds complexity
more things to remember / learn. More things to consider in ES.next.next
Yup, languages almost always tend to get bigger over time since it's really
hard to remove features.
For me, the goal isn't to make the language as
2011/5/20 Nebojša Ćirić c...@google.com:
Current proposal for NumberFormat specifies style (percent, currency,
decimal...) or a pattern to use to create a formatter.
We could add support for skeleton parameter (like date time formatter has)
to help developers get patterns they want but without
this is going to get a little philosophical and not super technical so i apologize in advance.
i don't agree that expressiveness is necessarily a good thing. expressiveness comes with a cognitive overhead when reading and thinking about code, it's in your head, always. the more feature, the more
On Mon, May 23, 2011 at 8:51 AM, Brendan Eich bren...@mozilla.com wrote:
Class syntax is like a lint brush for such features. If we add it, it will
accrete more semantics (with unambiguous syntax, I hope) over time. This is
just inevitable, in my view. It makes me want to resist classes and
On Mon, May 23, 2011 at 10:41 AM, Brendan Eich bren...@mozilla.com wrote:
On May 23, 2011, at 10:03 AM, Alex Russell wrote:
(A) the boilerplate needed to set up a sub-prototype object with correct
constructor property, and
(B) the pain of doing correct super calls by hand.
I hope we
Using public to refer to an instance property seems totally weird to me.
For what it's worth, I agree. I'd prefer var or instance. I've already seen
at least one example of someone misinterpreting it and doing something like:
class C {
public someMethod() { ... }
}
Their intent was to
there are lots of ES.next features that let us do something that we could
not do at all previously (weak tables and refs are a good example). features
that enable new kinds of applications we couldn't previous build.
+1 on this point. There’s been a lot of discussion of syntactic sugar
If one has a class proposal with the prerequisite examples and grammar
specification, how does one propose this with a possible goal of an alternate
strawman?
On May 23, 2011, at 11:25 AM, Bob Nystrom rnyst...@google.com wrote:
On Mon, May 23, 2011 at 10:41 AM, Brendan Eich
On Sat, May 21, 2011 at 5:11 AM, François REMY
fremycompany_...@yahoo.fr wrote:
this.c:= 1 looks like an error. If the intent was to set the c property to
a constant, it should not be a function' parameter. If, as I understood, you
have set a default value for the c parameter, what if you
I should have used ¤ (\u00A4) instead of $.
So ¤ gets replaced with proper currency symbol/code.
23. мај 2011. 11.08, Mike Samuel mikesam...@gmail.com је написао/ла:
2011/5/20 Nebojša Ćirić c...@google.com:
Current proposal for NumberFormat specifies style (percent, currency,
decimal...)
On Mon, May 23, 2011 at 11:32 AM, Bob Nystrom rnyst...@google.com wrote:
Using public to refer to an instance property seems totally weird to me.
For what it's worth, I agree. I'd prefer var or instance. I've already
seen at least one example of someone misinterpreting it and doing something
I fully agree with your remarks. Infix flags to the = operator causes
issues that are difficult to solve. Let's go for a evertything prefix,
then.
-Message d'origine-
From: Sean Eagan
Sent: Monday, May 23, 2011 8:37 PM
To: François REMY
Cc: es-discuss
Subject: Re: Proposal: Concise
Le 23/05/2011 20:15, Mikeal Rogers a écrit :
this is going to get a little philosophical and not super technical so
i apologize in advance.
i don't agree that expressiveness is necessarily a good thing.
expressiveness comes with a cognitive overhead when reading and
thinking about code, it's
On Mon, May 23, 2011 at 2:50 PM, Nebojša Ćirić c...@google.com wrote:
I should have used ¤ (\u00A4) instead of $.
So ¤ gets replaced with proper currency symbol/code.
Actually, I assume it just marks the format as a currency format, and the
currency symbol gets positioned according to the
This is just a last-minute plea, given that the proposal freeze is
apparently imminent: could the committee please reserve a slot
for solving the readable monadic coding in Javascript issue -
it needs no semantic changes, only syntax, and combining
technical aspects of existing proposal might
This seems too brittle to me. The examples conveniently include only lambda
parameters in their function calls. Suppose you have:
a = f{|| 42}
and want to add a second lambda parameter:
a = f{|| 42}{|x| x*x}
So far so good, ignoring the little bug that || is a different token than two
|'s
On 05/21/11 23:53, Brendan Eich wrote:
That's accurate. But I discounted arrow functions because to be usable, to have
the syntax you show above, requires GLR parsing (if bottom up; top-down may be
easier, haven't proven it yet).
GLR parsing would be wild in ECMAScript due to the fact that
Please excuse me, I'm just looking for clarification - thanks in advance:
Also, the current infix writable mark does not compose with Implicit
property initialization expressions [1] as noted in [2]. Using a
prefix fixes this:
let a = {!b}
This conflicts with the existing:
var foo =
I've been experimenting with PEG/packrat parsers and how well they do on the
ecmascript grammar.
Since these do not use lexers and are LL(n) they may be a better fit.
There are a few implementations out there written in JS - ometa and pegjs come
to mind.
They also are a good fit for transpilers
On May 23, 2011, at 11:25 AM, Bob Nystrom wrote:
One thing I'd like the proposal to support, which it doesn't currently, is
initializers on instance property declarations. Then you could do:
class C {
public _list = [];
}
With that, you'll correctly get a new _list on each instance
On May 23, 2011, at 11:33 AM, Luke Hoban wrote:
there are lots of ES.next features that let us do something that we could
not do at all previously (weak tables and refs are a good example).
features that enable new kinds of applications we couldn't previous build.
+1 on this point.
On May 23, 2011, at 2:09 PM, Waldemar Horwat wrote:
On 05/21/11 23:53, Brendan Eich wrote:
That's accurate. But I discounted arrow functions because to be usable, to
have the syntax you show above, requires GLR parsing (if bottom up; top-down
may be easier, haven't proven it yet).
GLR
On May 23, 2011, at 2:55 PM, Kam Kasravi wrote:
I've been experimenting with PEG/packrat parsers and how well they do on the
ecmascript grammar.
Since these do not use lexers and are LL(n) they may be a better fit.
There are a few implementations out there written in JS - ometa and pegjs
On May 23, 2011, at 1:44 PM, Waldemar Horwat wrote:
This seems too brittle to me. The examples conveniently include only lambda
parameters in their function calls. Suppose you have:
a = f{|| 42}
and want to add a second lambda parameter:
a = f{|| 42}{|x| x*x}
So far so good,
On May 23, 2011, at 4:08 PM, Brendan Eich bren...@mozilla.com wrote:
On May 23, 2011, at 2:55 PM, Kam Kasravi wrote:
I've been experimenting with PEG/packrat parsers and how well they do on the
ecmascript grammar.
Since these do not use lexers and are LL(n) they may be a better fit.
On 05/23/11 16:20, Brendan Eich wrote:
On May 23, 2011, at 1:44 PM, Waldemar Horwat wrote:
(we've yet to have a coherent discussion about what really can go into these
parameter lists).
I gave the grammar with semantics -- did you read it?
Yes. However I don't think it'd be tenable to not
On May 23, 2011, at 5:12 PM, Waldemar Horwat wrote:
On 05/23/11 16:20, Brendan Eich wrote:
On May 23, 2011, at 1:44 PM, Waldemar Horwat wrote:
(we've yet to have a coherent discussion about what really can go into
these parameter lists).
I gave the grammar with semantics -- did you read
On May 23, 2011, at 5:26 PM, Brendan Eich wrote:
I see what you mean, but is it really a problem without user testing? I could
try to make it an error but that seems unnecessary at this stage. Unless you
have a simple fix in mind?
One possible fix is to revise the grammar to require that
On 05/23/11 17:26, Brendan Eich wrote:
On May 23, 2011, at 5:12 PM, Waldemar Horwat wrote:
On 05/23/11 16:20, Brendan Eich wrote:
On May 23, 2011, at 1:44 PM, Waldemar Horwat wrote:
(we've yet to have a coherent discussion about what really can go into these
parameter lists).
I gave the
Attendees:
Jungshik Shin (Google), Mark Davis (Google), Richard Gillam (lab126 for
Addisson) and Nebojsa Ciric (Google).
Shawn, please take a look and see if there are any pain points with changes
we talked about (skeleton for number format, removal of calendar parameter
in date time format, and
On May 23, 2011, at 5:43 PM, Waldemar Horwat wrote:
I don't have a simple fix in mind. What's making me dubious about this is
that this is a function calling syntax that can supply a bunch of literal
functions as arguments, but they must all be literal functions. As soon as
you want to
On May 23, 2011, at 6:09 PM, Brendan Eich wrote:
2. Parse as proposed but with the restriction that the last block-lambda
argument ends the line,
Where ends the line means either ; or LineTerminator (ignoring spaces
including comments that do not include line terminators), I suppose. Ugh. #1
On 05/23/11 18:09, Brendan Eich wrote:
On May 23, 2011, at 5:43 PM, Waldemar Horwat wrote:
I don't have a simple fix in mind. What's making me dubious about this is that
this is a function calling syntax that can supply a bunch of literal functions
as arguments, but they must all be literal
On May 23, 2011, at 6:27 PM, Waldemar Horwat wrote:
On 05/23/11 18:09, Brendan Eich wrote:
Here are some ideas:
1. Extend the current proposal to allow parenthesized expressions
interleaved with no line terminators, only optional horizontal space
characters, with block-lambda
Mark and Tom used Ometa for http://code.google.com/p/es-lab/ --
slo-o-o-o-w.
Yeah it has no memoization. Pretty cool nevertheless as far as what he was
able to do. Though I really like what Dave is doing on narcissus.
No credit to me on the Narcissus parser; it was originally written
IANA Rubyist, but I *think* the goal was for blocks to be downwards-only, so
that upvars could live on the stack and everything could be nice speedy. So
they had to syntactically restrict blocks to enforce that they couldn't outlive
the frame in which they were created.
As Brendan says,
On May 23, 2011, at 6:51 PM, Brendan Eich wrote:
Done, at http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
-- this was easy, but it made me wonder whether parentheses for the plain
Expression arguments that may occur after the leading BlockLambda ought not
better be
65 matches
Mail list logo
