breakage? I will
probably look into at least adding a warning for this in Firefox very soon.
-Tom
On Sun, Sep 28, 2014 at 10:09 PM, Oliver Hunt oli...@apple.com
mailto:oli...@apple.com wrote:
As MarkM said it break on recursion, but we’re also only killing
function.arguments, not (alas
JSC does lazy parsing of nested functions and we have no problem reporting
static errors, so i’m not sure what you believe is the problem here.
—Oliver
On Oct 1, 2014, at 7:09 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
The static error is problematic. I'm pretty sure that engines
The problem is not people actively developing it, or creating new content with
it. The problem is _existing_ content that might break. All libraries have
periods where they are in vogue, and then fade out leaving detritus that hangs
around for years/decades on major sites.
--Oliver
On Sep
Hi all, as a heads up we’re going to be doing an experiment in our tree to see
if we can kill off the function.arguments property entirely.
We’re super hopeful we can make it go away safely, and we’ll post a follow up
when we have some actual information about what happens.
If you’re
JavaScriptCore has never allowed octal sequences (anything other than a . or x
after 0) in strict mode, and we haven't had any problems with it.
--Oliver
On Aug 5, 2014, at 11:13 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 5, 2014, at 8:38 AM, Mathias Bynens wrote:
On 5
On Jul 29, 2014, at 12:02 PM, Christoph Martens cmarten...@gmail.com wrote:
Hey all,
I just read a bit about the ParallelJS project, Typed Objects (StructType)
and was curious if I could implement bindings for v8 today.
Link to wiki document:
On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote:
Hi,
Will it makes sense to standardize a trailing comma for function arguments,
and call parameters?
We have it for Array and Object initialisers, and people like using them for
long lists with prediction
It turns out there are a number of sites (such as mobile.twitter.com) that are
property detecting .entries on objects, and that means that they're breaking
when Array.prototype.entries is provided.
We're removing it from JSC now, until we can find a way to expose it without
causing site
hits the entries property on Array.prototype
--Oliver
On Jun 16, 2014, at 4:10 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
That is why you need to implement @unscopables too.
On Jun 16, 2014 7:08 PM, Oliver Hunt oli...@apple.com wrote:
It turns out there are a number of sites
All these bugs can be filed at bugs.webkit.org (which is a much better place
than a mailing list), anyway:
On Jun 4, 2014, at 1:08 PM, C. Scott Ananian ecmascr...@cscott.net wrote:
So... Safari 8's betas were just released. It contains a partial ES6
implementation -- but one which fails
On May 28, 2014, at 11:10 AM, cowwoc cow...@bbs.darktech.org wrote:
I would like the specification to also allow the following syntax:
return
{
key: value
};
This is currently valid syntax, and has an entirely different behaviour (and
side effects) from returning an object
On May 28, 2014, at 11:39 AM, cowwoc cow...@bbs.darktech.org wrote:
Don't we use a semicolon to denote the end of an expression context? Perhaps
I'm missing something, but I see no ambiguity in the example you gave. I
expect:
return {};
and
return
{};
to return an
On May 28, 2014, at 11:48 AM, cowwoc cow...@bbs.darktech.org wrote:
That's an unfortunate side-effect. I think that developers should be able to
pick their own code styles. After all, most of these choices are subjective.
Anyway, thanks for the head's up.
They can choose their own
On May 15, 2014, at 10:24 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
but you mentioned very old one I think nobody cares much anymore ;-)
People may not “care” about them today, but that doesn’t mean that no one uses
them - there are many millions of webpages that use these
On Apr 25, 2014, at 4:24 AM, Andreas Rossberg rossb...@google.com wrote:
The way destructuring assignment currently is specified leads to
rather inconsistent evaluation order. Consider:
let o = {}
function f() { print(1); return o }
function g() { print(2); return 5 }
f().x = g()
On Apr 25, 2014, at 10:42 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Apr 25, 2014, at 10:25 AM, Oliver Hunt wrote:
On Apr 25, 2014, at 4:24 AM, Andreas Rossberg rossb...@google.com wrote:
The way destructuring assignment currently is specified leads to
rather inconsistent
I’ve landed the change to JSC to silently ignore the assignment in the
non-strict “var ident =“ case, everything else is still an error so
deconstruction and |of| enumeration will trigger a syntax error.
—Oliver
On Mar 15, 2014, at 2:01 PM, Brendan Eich bren...@mozilla.com wrote:
Brendan
JSC has been trying to kill off the initialiser expression in the for(in)
statement, but we've encountered a bunch of reasonably significant content that
breaks with it disallowed (a particularly prominent one currently is
http://battlelog.battlefield.com/bf4/), so we will be bringing back
On Feb 5, 2014, at 12:05 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 4, 2014 at 9:49 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Allen
Wirfs-Brock al...@wirfs-brock.com
I've designed exception handling
On Jan 30, 2014, at 8:07 AM, Dean Landolt d...@deanlandolt.com wrote:
On Thu, Jan 30, 2014 at 10:59 AM, John Barton johnjbar...@google.com wrote:
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x)
On Jan 30, 2014, at 11:27 AM, John Lenz concavel...@gmail.com wrote:
I don't argue that it isn't a useless let. I do point out that in sloppy
mode, that other declaration are allow in practices by browsers. Chrome
allows function, const, and var in the body of an if without block.
I believe the conclusion with |let| was to identify let syntax:
let foo(=*) is syntactically unambiguous, just a bit more work to identify.
yield is only valid in generators (function*) so that gets reserved the moment
you enter a generator definition
—Oliver
On Jan 24, 2014, at 9:11 AM, John
The problem i have with SideTable as a name is that it’s implying a very
specific use case (one that could equally be served by private names), it’s
also not an obvious name to developers who are not aware of terms of art.
I said a long time ago that the name WeakMap did not match the expected
(I know Anne knows this argument, but i’m emailing this logic for people who
aren’t aware of it)
The reason for prefixing APIs is to allow a feature to be shipped and used by
developers before the final api semantics are settled on. In the event the
spec doesn’t change then they simply alias,
new Function is simply calling a constructor - the fact that it creates a
callable object is irrelevant as there is nothing magical about the constructor
itself.
The new function object itself is also scoped to the root lexical environment,
not the strict mode function it is being called from,
The only formatting requirement for the stack property is that if it is
present, it must be a string.
—Oliver
On Nov 12, 2013, at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
When I started investigating this I had the hope that stack could be
standardized. However, the format of
the same view
in our .stack string)
—Oliver
On Nov 12, 2013, at 11:17 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
On Tue, Nov 12, 2013 at 12:35 PM, Oliver Hunt oli...@apple.com wrote:
The only formatting requirement for the stack property is that if it is
present, it must be a string
important part of the answer is the parsed form provided by getCWStack.
On Tue, Nov 12, 2013 at 12:20 PM, Oliver Hunt oli...@apple.com wrote:
Righto, do we know whether Carakan/V8’s text or SM’s text is preferred?
Currently it seems like JSC’s is a little bit weird compare to others
Alas in addition to assuming that the Arguments object does not have the Array
prototype, ExtJS also relies on the Array prototype not containing a property
named values.
So, it seems that we’ll need to remove .values from the Array prototype.
—Oliver
using with(), despite the years of being told not to.
—Oliver
On Nov 11, 2013, at 11:59 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/11/13 2:47 PM, Oliver Hunt wrote:
Alas in addition to assuming that the Arguments object does not have the
Array prototype, ExtJS also relies on the Array
/13 2:47 PM, Oliver Hunt wrote:
Alas in addition to assuming that the Arguments object does not have the
Array prototype, ExtJS also relies on the Array prototype not containing a
property named values.
So, it seems that we’ll need to remove .values from the Array prototype.
Oliver,
Just
, Nov 11, 2013 at 2:59 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/11/13 2:47 PM, Oliver Hunt wrote:
Alas in addition to assuming that the Arguments object does not have the
Array prototype, ExtJS also relies on the Array prototype not containing a
property named values.
So, it seems
I don’t fully understand this — what is the reason for needing to know actual
argument count? The historical reason was that if i have a var arg function
with a few required parameters i don’t have any nice way of iterating the
optional args.
Default and rest parameters seem to solve this use
On Nov 10, 2013, at 12:52 PM, Oliver Hunt oli...@apple.com wrote:
I don’t fully understand this — what is the reason for needing to know actual
argument count? The historical reason was that if i have a var arg function
with a few required parameters i don’t have any nice way of iterating
The mere fact the this discussion is coming up, is a good argument (to me
anyway) that default parameter behaviour should have been in terms of argument
count, not |undefined|. Again, sentinel values that are regular valid values
are a bad thing.
I still cannot recall what the usage scenario
On Nov 10, 2013, at 2:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
I think I've completely missed the `undefined === absent` conversation ... so
if I have an object, and `obj.key = void 0` why `key` would be considered
absent, exactly? `undefined` is a very well described
I think there’s a comment on that page to the effect of “it has to be a
string”, i think amazon was one of the sites that interpret the existence of
.stack as implying it’s a string.
All things being equal i think that i prefer the current Carakan/V8 string
format, and would be happy to change
Allen asked me a real case to show, and I've done it. Now you please
show me a real case when you pass a revival function to `JSON.parse` that is
from another realm, explaining why, as I've done for mine, thanks.
Best Regards
On Thu, Oct 31, 2013 at 7:41 PM, Oliver Hunt oli...@apple.com
On Nov 1, 2013, at 2:46 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Allen, in which place on current known universe, when you parse a
JSON.string, your reviver function receives objects from another realm,
exactly?
Please try to keep the discourse polite.
That said this is
On Oct 26, 2013, at 4:59 PM, Lucio Tato luciot...@gmail.com wrote:
Rick: I understand. But it is always a trade-off.
If the reason to introduce a new construct is because there may already be
code that defines a function called `yield`, it seems to me as a bad
trade-off. (advantages vs
I know we would like people to stop using the Arguments object, but just to be
sure, is it intentional that the Arguments Object does not have an @@iterator ?
—Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
On Oct 9, 2013, at 1:35 AM, Claude Pache claude.pa...@gmail.com wrote:
Le 8 oct. 2013 à 23:43, Andrew Fedoniouk n...@terrainformatica.com a écrit :
Quite often Date values are used in data exchanges in form of JS
literals or JSON.
It would be beneficial if JS (and JSON as derivative)
Shipping JSC supports Symbols (although by the old name, Name, alas)
—Oliver
On Sep 30, 2013, at 12:49 PM, David Bruant bruan...@gmail.com wrote:
Le 30/09/2013 19:30, Rick Waldron a écrit :
On Mon, Sep 30, 2013 at 12:54 PM, Kevin Smith zenpars...@gmail.com wrote:
I think all we want here
I am reading the spec and it looks (to me at least) like we expect [a,b,c] +=
[1,2,3] to be equivalent to a+=1; b+=2; c+=3 — is that correct or have i
misread something?
—Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
I'll try to rephrase:
As I read the spec this is not a syntax error, and so gets delayed to runtime.
Given that we're already doing work to determine whether we should be
destructuring (which results in different runtime semantics), it seems we
should promote (demote?) deconstructing lhs rwm
twitter: twitter.com/rauschma http://twitter.com/rauschma
blog: 2ality.com http://2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Oliver Hunt mailto:oli...@apple.com
September 13, 2013 5:39
Okay so we were discussing among ourselves, and we thought that a sane
desugaring for
function f(x=expr) {
...
}
would be
function f(x) {
if (arguments.length 1) x=expr;
...
}
This would produce a consistent and easy to follow semantic for default
evaluation, it doesn't introduce any
On Sep 13, 2013, at 9:18 AM, Brendan Eich bren...@mozilla.com wrote:
Oliver Hunt mailto:oli...@apple.com
September 13, 2013 6:11 PM
Okay so we were discussing among ourselves, and we thought that a sane
desugaring for
function f(x=expr) {
...
}
would be
function f(x
On Sep 13, 2013, at 9:58 AM, Andreas Rossberg rossb...@google.com wrote:
On 13 September 2013 18:39, Oliver Hunt oli...@apple.com wrote:
The problem with temporal dead zones is that they lead to weird behaviour in
edge cases, and almost all of them should be syntactically identifiable
On Sep 13, 2013, at 11:09 AM, Andreas Rossberg rossb...@google.com wrote:
OK, I assumed you were talking about TDZ in general, and not just for
the specific case of parameter lists. For parameter lists, I agree
that there is no reason to treat them as mutually recursive. However,
if scoping
On Sep 12, 2013, at 7:51 AM, Andreas Rossberg rossb...@google.com wrote:
On 12 September 2013 01:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
For now, I'm going to try giving each semantic routine in a subsection, a
section number. Note this may include multiple algorithms
On Sep 12, 2013, at 12:40 PM, Jason Orendorff jason.orendo...@gmail.com wrote:
Just as a worked example, answering Oliver's question about default
expressions took me the better part of an hour.
The default-expression h() in code like
function f(x=h(), y) {
function h() { ...
Okay, I'm having a really hard time navigating and following the current spec
layout. The many different places that behavior is specified for the same
productions, and the absence of direct links between makes extraordinarily hard
to read and understand.
In my current reading I was
On Sep 4, 2013, at 4:15 PM, Filip Pizlo fpi...@apple.com wrote:
On Sep 4, 2013, at 3:09 PM, Brendan Eich bren...@mozilla.com wrote:
snip solo much text :D
But with ES5 Object.preventExtensions, etc., the horse is out of the barn.
It's there and we have to support it, and the fact that
On Aug 31, 2013, at 12:15 PM, Yuichi Nishiwaki yuichi.nishiw...@gmail.com
wrote:
Hi all, I just found a post that the current generator syntax
(function *) seems have decided in:
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
According to the post, the biggest
On Aug 30, 2013, at 10:13 AM, David Herman dher...@mozilla.com wrote:
On Aug 30, 2013, at 9:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I think the right-way to think about structs is as an record structure with
no properties fixed behavior provided by a wrapper. Very similar to
On Aug 29, 2013, at 1:13 AM, Brendan Eich bren...@mozilla.com wrote:
Axel Rauschmayer wrote:
* /g flag must be set
* lastIndex must be 0
* can’t inline the regex, because it is needed as a pseudo-iterator (more of
an anti-pattern, anyway, but still)
* side effects via lastIndex may be a
, at 9:04 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
see meeting notes
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-24.md#54-are-typedarray-insances-born-non-extensible
On Aug 26, 2013, at 5:34 PM, Oliver Hunt wrote:
So I noticed in the last revision to the TA
Existing types with magic index properties (other than Array) just drop numeric
expandos on the floor so it's logically a no-op. Unless there was a numeric
accessor on the prototype (which non-extensibility does not save you from).
My complaint is that this appears to be removing functionality
On Aug 27, 2013, at 3:49 PM, David Herman dher...@mozilla.com wrote:
On Aug 27, 2013, at 9:47 AM, Filip Pizlo fpi...@apple.com wrote:
I do. Placing named properties on arrays makes sense. Consider a matrix
implemented as a Float32Array, with named properties telling you the numRows
and
So I noticed in the last revision to the TA spec that a decision was made to
prevent extensibility of them. Can someone say why that decision was made? It
makes TAs somewhat unique vs. all other builtin types and doesn't match the
behavior of Blink or WebKit implementations.
While I am
On Jul 26, 2013, at 8:50 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Why do arrow functions require a parameter list and a body? That is, none of
the following are allowed:
- `= foo`
I guess this could be lexically unambiguous, but i'm unconvinced that the win
of losing two
On Jul 25, 2013, at 12:11 PM, Waldemar Horwat walde...@google.com wrote:
On Thu, Jul 25, 2013 at 12:00 PM, Brendan Eich bren...@mozilla.com wrote:
Michael Haufe wrote:
In 2008 I first proposed the addition of an integer division operator to the
language. At the time Brendan noted his
On Jul 15, 2013, at 8:15 AM, Mark S. Miller erig...@google.com wrote:
No wrapping object type -- those are legacy, to be avoided. See
http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing
is value not reference semantics.
On that page: It’s forwards-compatible
On Jul 12, 2013, at 8:58 AM, Luke Hoban lu...@microsoft.com wrote:
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
On Jul 11, 2013, at 9:01 PM, Luke Hoban wrote:
Two questions on new Number APIs:
1) Is it intentional that clz is on Number.prototype instead of Number?
Why?
think
isInteger(-0) should be true and isInteger(NaN) should be false.
Oh i agree with that, i was making an observation that the behaviour (i think)
will confuse people just on the basis of people equating Int32 with Integer
--Oliver
On Fri, Jul 12, 2013 at 10:16 AM, Oliver Hunt oli
Just to clarify, JSRegress is not a benchmark in the sunspider/kraken/etc
sense, as the tests tend far more towards microbenchmarks than full real
programme tests. As the name suggests its main purpose is to help us make sure
we're not regressing core language primitives.
--Oliver
On Jul 12,
Python isn't use to run arbitrary untrusted code, from untrusted websites.
The reality is that we thinking about features you want in ES, it's not enough
for another language to have the feature, you have to ask yourself whether the
other language is primarily used for untrusted code.
--Oliver
I would be pro-killing this particular misfeature. I know we have tests that
verify that we accept the syntax, but i'm not sure if there's still *real*
content the depends on it.
Does strict mode disallow it? IIRC strict mode has a blanket ban on
non-reference lhs in assignment expressions
Hmmm, my initial thought was against this (and for this specific case i'm not
sure i've been sold on it), but I do kind of like the concept. Alas this is me
we're talking about so I do have a few issues with it
* I'm a little concerned that this could make for easily misread code, even for
JSC switched to an always stable sort years ago due to compatibility problems
with content targeting firefox and IE depending on it.
We also had issues with inconsistent comparison functions, but i can't recall
exactly what the reasoning behind it was (nor the exact behavior we felt was
I landed support for Math.imul in JSC yesterday as well.
Can't find actual documentation on the expected behavior so just copied what
mozilla does.
--Oliver
On Apr 26, 2013, at 10:58 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Apr 26, 2013 8:42 AM, Tom Schuster t...@schuster.me
On Fri, Mar 29, 2013 at 3:47 AM, Oliver Hunt oli...@apple.com wrote:
On Mar 29, 2013, at 7:36 AM, David Herman dher...@mozilla.com wrote:
On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt oli...@apple.com wrote
On Apr 1, 2013, at 3:12 PM, Hudson, Rick rick.hud...@intel.com wrote:
If the compiler can prove x does not escape the block and it is not used
again then it is dead and the compiler is free to reuse the stack slot
holding the last reference.
So I am arguing that x = null; is not required
On Mar 29, 2013, at 7:36 AM, David Herman dher...@mozilla.com wrote:
On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt oli...@apple.com wrote:
That said I believe that this does kill any dreams i may have had w.r.t
On Mar 27, 2013, at 7:53 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com
wrote:
Given that we can't guarantee that the bit pattern will remain unchanged the
spec should mandate normalizing to the non-signalling NaN.
--Oliver
It's not trivially exploitable, at least not in SM or V8.
On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com
wrote:
That's just because ES has had no notion of bits for floating points before.
Other than that, ES NaN works like IEEE NaN, e.g.
0/0 === NaN // false
isNaN(0/0) // true
That's true in any language -
On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
Right, thanks for the reminder. It all comes back now, including the how to
write correct ending-independent typed array code bit.
Ok, so looping back to my
On Mar 3, 2013, at 12:05 PM, Brendan Eich bren...@mozilla.com wrote:
(a) not a compatible change for engines already prototyping StopIteration.
(b) wrong hammer for this nail.
Are the some and every names confusing? Would any and all be better?
I think the naming boat has sailed, and i'm
On Feb 11, 2013, at 8:54 AM, Jason Orendorff jason.orendo...@gmail.com wrote:
On Sun, Feb 10, 2013 at 4:05 PM, Oliver Hunt oli...@apple.com wrote:
It turns out (at least in Python) that while you rarely have to directly
implement the raw iterator protocol, you seriously almost *never
On Feb 11, 2013, at 10:35 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on
behalf of Oliver Hunt [oli...@apple.com]
For now I would say that we shouldn't expose the internal implementation
behaviour of yield
On Feb 11, 2013, at 1:29 PM, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on
behalf of Oliver Hunt [oli...@apple.com]
For now I would say that we shouldn't expose the internal implementation
On Feb 11, 2013, at 1:33 PM, Jason Orendorff jason.orendo...@gmail.com wrote:
On Mon, Feb 11, 2013 at 12:30 PM, Oliver Hunt oli...@apple.com wrote:
For now I would say that we shouldn't expose the internal implementation
behaviour of yield (which is what being able to explicitly create
On Feb 11, 2013, at 1:58 PM, Brendan Eich bren...@mozilla.com wrote:
Oliver Hunt wrote:
So what you're saying is that people who attend in person meetings are able
to veto proposals,
No, I didn't say that. You are good at logic, I've seen your code. I know you
grok P - Q does
Just a couple of questions on this wonderous topic:
* how is 'e instanceof StopIteration' intended to work across multiple global
objects?
* how firmly are we wedded to this? I can't imagine there is too much code that
currently depends on manually catching StopIteration given ES6 is not
On Feb 10, 2013, at 1:01 PM, David Bruant bruan...@gmail.com wrote:
Le 10/02/2013 20:55, Oliver Hunt a écrit :
Just a couple of questions on this wonderous topic:
* how is 'e instanceof StopIteration' intended to work across multiple
global objects?
StopIteration has a special
On Feb 10, 2013, at 1:55 PM, Jason Orendorff jason.orendo...@gmail.com wrote:
On Sun, Feb 10, 2013 at 1:55 PM, Oliver Hunt oli...@apple.com wrote:
I do dislike the exception based termination, I _think_ i'd prefer next() and
hasNext() style iteration over exceptions, especially given
On Feb 5, 2013, at 11:00 PM, Brendan Eich bren...@mozilla.com wrote:
Sorry if I was a thread-killer, posting four times in a row.
On balance we have:
prefix-? pros:
* LR(1) grammar without ambiguity or lookahead restriction.
What's the production that takes this out of LL(1)?
10 has it?)
and i'm not sure what V8/SM do.
--Oliver
I think there's other differences.
On Wed, Jan 16, 2013 at 2:00 PM, Oliver Hunt oli...@apple.com wrote:
let can't be used as an opt in (unfortunately :-( ) as it turns out let is
used as a variable name in real world code.
Gavin
Even 10? If that's the case anything using const is inherently tied to
jsc,v8,moz,opera behaviour.
Presumably the strictest of those _works_, but maybe i'm wrong?
We should probably just enumerate all the differences and see which can be
coalesced and which make sense in sloppy mode.
Obvious
...@mozilla.org] on
behalf of Oliver Hunt [oli...@apple.com]
Sent: Wednesday, January 16, 2013 14:40
To: Brendan Eich
Cc: Mark S. Miller; Mark Miller; es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Even 10? If that's the case anything using const is inherently tied
Just adding an implementers point of view:
Adding a new keyword/annotation is risky and/or complicates language semantics
-- we don't want to break existing code, so new keywords are hard, likewise
context dependent keywords can be tricksy: f = function pure(){} means what?
Assuming that there
On Nov 28, 2012, at 12:25 PM, Waldemar Horwat walde...@google.com wrote:
On Wed, Nov 28, 2012 at 5:39 AM, Marius Gundersen gunder...@gmail.com wrote:
On Wed, Nov 28, 2012 at 1:20 PM, Andreas Rossberg rossb...@google.com wrote:
Second, due to the extremely impure nature of JavaScript, there
On Nov 28, 2012, at 1:11 PM, David Bruant bruan...@gmail.com wrote:
Le 28/11/2012 21:35, Oliver Hunt a écrit :
On Nov 28, 2012, at 12:25 PM, Waldemar Horwat walde...@google.com wrote:
On Wed, Nov 28, 2012 at 5:39 AM, Marius Gundersen gunder...@gmail.com
wrote:
On Wed, Nov 28, 2012 at 1
the risk of it having been
changed to something different, globally)?
On Nov 28, 2012, at 21:35 , Oliver Hunt oli...@apple.com wrote:
On Nov 28, 2012, at 12:25 PM, Waldemar Horwat walde...@google.com wrote:
On Wed, Nov 28, 2012 at 5:39 AM, Marius Gundersen gunder...@gmail.com
wrote
On Nov 18, 2012, at 6:17 PM, Matt Calhoun calhoun...@gmail.com wrote:
I believe that having a concise notation for linear algebra is an important
feature of a programming language that can dramatically improve code
readability, and furthermore that linear algebra is a powerful tool that has
On Nov 16, 2012, at 2:11 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
but I don't see caller being any better/worse than arguments and I believe
arguments will stick around forever in any case ... so will caller, unless
there's not some specific personal reason but the code
I don't think you understand the semantics here -- the Function constructor is
defined as taking a string (ignoring the parameters for now) and returning a
function as though the function was defined in the global scope. No functions
change behaviour based on the strictness of their caller.
code itself. To meaningfully discuss the behaviour
and semantics of these things (and their interactions with strict mode) you
need to understand all of these concepts and how they relate.
--Oliver
On Fri, Nov 16, 2012 at 3:32 PM, Oliver Hunt oli...@apple.com wrote:
I don't think you
strict about since
there were already linters to tell us what's good and what's not on code
level, I am sorry if I don't understand.
br
On Fri, Nov 16, 2012 at 3:52 PM, Oliver Hunt oli...@apple.com wrote:
On Nov 16, 2012, at 3:38 PM, Andrea Giammarchi andrea.giammar...@gmail.com
1 - 100 of 253 matches
Mail list logo
