I haven't replied to this thread yet, because I feel that I already
made all the same arguments repeatedly to no avail. ;) However, let
me reiterate one particular observation, which is that IMHO much of
the discussion (and decision making) around 1JS, modes, and opt-ins is
just mistargeted.
On 29 December 2012 14:51, Axel Rauschmayer a...@rauschma.de wrote:
I’m sympathetic to both sides of this argument. How would you handle things?
Ideally? Backing out of the whole 1JS marketing maneuver? In the long
run, I see it as more harmful than helpful, as it inevitably leads to
complexity
On 28 December 2012 05:38, Brendan Eich bren...@mozilla.com wrote:
No point whinging about it in appendices that either no one reads, or else
people read and think less of the spec on that account.
The fewer read about it the better, no? :)
Why would people think less about the spec?
I
On 28 December 2012 07:10, David Herman dher...@mozilla.com wrote:
On Dec 27, 2012, at 2:13 PM, Andreas Rossberg rossb...@google.com wrote:
It's true that with TDZ, there is a difference between the two forms
above, but that is irrelevant, because that difference can only be observed
On 28 December 2012 11:22, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
As for TDZ precedent, ES6 will have plenty of precedent of other
lexical declaration forms that uniformly have TDZ and would not allow an
example like the above.
Can these plenty be enumerated
On 28 December 2012 11:51, David Bruant bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto standards?
It would indicate that it's part of the standard, but is a scar from
history rather than a
On 28 December 2012 13:34, Herby Vojčík he...@mailbox.sk wrote:
Andreas Rossberg wrote:
That's a good point, actually. I, for one, do not understand the
criteria by which we chose to include __proto__ but not __defineGetter__
and friends.
__defineGetter__ and friends have sane
On 28 December 2012 16:20, Domenic Denicola dome...@domenicdenicola.comwrote:
Now that I have fully digested Andreas's points from the earlier thread
on modules [1], I am a bit concerned about the implications of `import`
introducing aliasing bindings. To recap, the situation is:
module foo
On 28 December 2012 17:54, David Herman dher...@mozilla.com wrote:
Another one is that I've been thinking we should add getter/setter exports
to make it possible to create lazily initialized exports:
We haven't had the opportunity to discuss that one, but now that you
mention it, I should say
On 28 December 2012 19:55, Mark S. Miller erig...@google.com wrote:
That is exactly the issue. As long as it was not expected in IE, it
could not be assumed by the cross-browser web. However, mobile changed
MS's tradeoffs. Mobile is currently a separate enough ecosystem, with
IE a
On 27 December 2012 01:50, David Herman dher...@mozilla.com wrote:
On Dec 11, 2012, at 2:45 AM, Andreas Rossberg rossb...@google.com wrote:
The question, then, boils down to what the observation should be: a
runtime error (aka temporal dead zone) or 'undefined'. Given that
choice
On 27 December 2012 06:38, David Herman dher...@mozilla.com wrote:
On Dec 24, 2012, at 1:48 AM, Anne van Kesteren ann...@annevk.nl wrote:
It seems ES6 has __proto__ which also allows modifying [[Prototype]]
so presumably this is nothing particularly bad, although it is very
ugly :-(
It
On 27 December 2012 05:53, Brendan Eich bren...@mozilla.com wrote:
I have a theory: hashes and lookup tables (arrays or vectors) have
displaced most other data structures because most of the time, for most
programs (horrible generalizations I know), you don't need ordered entries,
or other
On 27 December 2012 21:08, David Herman dher...@mozilla.com wrote:
On Dec 27, 2012, at 1:23 AM, Andreas Rossberg rossb...@google.com wrote:
var x;
if (...) { x = ... }
if (x === undefined) { ... }
If you want to use let instead, the === if-condition will throw. You
would
On 27 December 2012 21:23, David Herman dher...@mozilla.com wrote:
On Dec 27, 2012, at 1:51 AM, Andreas Rossberg rossb...@google.com wrote:
I think hoisting can mean different things, which kind of makes this
debate a bit confused.
Yep. Sometimes people mean the scope extends to a region
On 27 December 2012 23:38, Andreas Rossberg rossb...@google.com wrote:
I don't feel qualified to talk for Scheme, but all Ocaml I've ever
seen (SML uses more verbose 'let' syntax anyway) formatted the above as
let sq = x * x in
print (sq: ^ toString sq ^ \n);
let y = sq / 2
On 27 December 2012 18:25, Brendan Eich bren...@mozilla.com wrote:
That is, if having it at all, I'd still think it much wiser to ban it to
some Appendix.
What earthly good would that do?
Marketing and psychology (as I said, being important). It would send a
clear message that it is just
On 21 December 2012 03:00, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Dec 20, 2012, at 12:07 PM, Tom Van Cutsem wrote:
I'm not sure I follow. In my understanding, the original Receiver is only
needed for traps that involve prototype-chain walking and are thus
|this|-sensitive. That
On 19 December 2012 23:05, David Herman dher...@mozilla.com wrote:
On Dec 19, 2012, at 12:59 PM, Andreas Rossberg rossb...@google.com
wrote:
It's also worth noting that Dave's comparison is somewhat inaccurate.
The convention is used to name the _primary_ abstract type defined by a
module
On 20 December 2012 05:24, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
IMO this is undesirable. In such a situation, modules can no longer be
abstraction boundaries. Instead you must peek inside each module and see
which form it exported itself using.
You have to know
On 20 December 2012 11:09, Tom Van Cutsem tomvc...@gmail.com wrote:
Currently, that test is performed in step 5.b. by testing whether the
current object we are visiting in the proto chain O is the Receiver
object. At first sight, this is a rather weird way of deciding between
update vs.
On 20 December 2012 14:17, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
We want to support *both* a syntax for 'import a module, and bind a
particular identifier to the single anonymous export' and a syntax for
'import a module, and bind an identifier to the module instance
object'. We
On 20 December 2012 19:39, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
More importantly, though, convention is one thing, baking it into the
language another. I've become deeply skeptical of shoe-horning orthogonal
concerns into one unified concept at the language level
On 18 December 2012 22:56, Tom Van Cutsem tomvc...@gmail.com wrote:
Option B:
Address point 2) directly by changing the test that determines property
addition versus property update inside Reflect.set (i.e. the [[SetP]]
internal method of objects) so that the algorithm no longer tests whether
On 18 December 2012 20:24, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
To me, as a application programmer or even a library programmer,
enforcement of these invariants are generally unnecessary. If enforcement
impacts performance or expressibility they have a negative impact on my
ability
On 19 December 2012 16:24, Kevin Smith khs4...@gmail.com wrote:
I've worked up a concrete variation on the modules syntax:
https://gist.github.com/4337062
I believe that it presents a clean, simple model and coding experience.
Comments welcome!
Thank you! I agree with almost everything
On 19 December 2012 20:18, James Burke jrbu...@gmail.com wrote:
exports assignment is not about backcompat specifically, although it
helps. Exports assignment is more about keeping the anonymous natures
of modules preserved. In ES modules, modules do not name themselves if
it is a single
On 19 December 2012 21:29, James Burke jrbu...@gmail.com wrote:
This is illustrated by an example from Dave Herman, for a language
(sorry I do not recall which), where developers ended up using _t,
or some convention like that, to indicate a single export value that
they did not want to name.
On 15 December 2012 22:52, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
So, to me, it sounds like that to continue down this path we should really
add new non-reflected properties attributes that are the real control points
for the ES semantics. Eg, we may need [[RealReadOnly]],
On 17 December 2012 13:01, Mark S. Miller erig...@google.com wrote:
On Mon, Dec 17, 2012 at 2:03 AM, Andreas Rossberg rossb...@google.com wrote:
I see the following preferable solutions to deal with DOM features violating
ES:
1. Lobby to fix the DOM and make it conform to ES instead
On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote:
On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote:
As you say, to remain viable, it
must be done quickly. From previous experience, I suggest that there's
exactly one way to get quick universal deployment:
rather have a structure like (modulo details of naming):
estests/
test262/
ch*/
intl402/
platforms/
/Andreas
On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell slightly...@google.com
wrote:
+1. What Andreas said.
On Friday, December 14, 2012, Andreas Rossberg wrote:
On 13 December 2012
On 14 December 2012 06:46, John-David Dalton
john.david.dal...@gmail.com wrote:
Axel Rauschmayer:
Honest question: I have yet to see boxed values in practice. Are there any
real use cases?
See Modernizr:
https://github.com/Modernizr/Modernizr/blob/master/feature-detects/video.js#L23
I think
On 10 December 2012 21:59, Claus Reinke claus.rei...@talk21.com wrote:
Second, it doesn't eliminate the need for temporal dead zones at all.
You could well be right, and I might have been misinterpreting what
temporal dead zone (tdz) means.
For a letrec, I expect
On 10 December 2012 05:30, Kevin Smith khs4...@gmail.com wrote:
OK, then suppose we have these two separate forms:
import x from url; // Bind x to the anonymous export, if defined,
otherwise error
and
import module x from url; // Bind x to the module instance
In the vast majority
On 9 December 2012 02:10, Kevin Smith khs4...@gmail.com wrote:
So if you didn't set the anonymous binding in some module x.js, what would
this do:
import x from x.js;
Would x be bound to the module instance or would we get a binding error?
Since it is just sugar, and supposed to be
On 9 December 2012 03:51, Domenic Denicola dome...@domenicdenicola.com wrote:
From: Andreas Rossberg [mailto:rossb...@google.com]
On 6 December 2012 16:44, Domenic Denicola
dome...@domenicdenicola.com wrote:
For the record, here's the idea Yehuda and I worked out:
https://gist.github.com
On 9 December 2012 15:04, Nathan Wall nathan.w...@live.com wrote:
The problem is that imports are not normal variable assignments. They
do not copy values, like normal destructuring, they are aliasing
bindings! If you were to allow arbitrary expressions and patterns,
then this would imply
On 6 December 2012 22:26, Claus Reinke claus.rei...@talk21.com wrote:
I was hoping for something roughly like
let lhs = rhs; statements
// non-recursive, scope is statements
let { declarations }; statements// recursive, scope is
declarations and statements
Problem is
On 6 December 2012 18:38, Rick Waldron waldron.r...@gmail.com wrote:
I agree with other voices in this thread that in general, returning
'this' rather is an anti pattern.
The evidence I've brought to this discussion shows that the most widely used
and depended upon libraries heavily favor the
On 6 December 2012 17:54, Kevin Smith khs4...@gmail.com wrote:
Note, however, that you still assume some hack in the semantics with
the if it exists part. To avoid that, you need to divorce the import
syntax from the naming-an-external-module syntax -- which I'd actually
prefer anyway, and
On 6 December 2012 05:05, Rick Waldron waldron.r...@gmail.com wrote:
Again, I reject the notion that someone might screw up is a valid argument
for this, or any, discussion. It's one thing to be aware of the potential
for misuse, but entirely another to succumb to fear driven design.
Fear
On 5 December 2012 19:19, Claus Reinke claus.rei...@talk21.com wrote:
their operational generativity perhaps being a mismatch with their
seemingly static meaning in certain syntactic forms,
This appears to be ungrounded. See below.
Personally, I also consider that a non-issue, but it was
On 6 December 2012 15:42, Kevin Smith khs4...@gmail.com wrote:
5) Dynamic exports via `export = ?` could make interop with existing
module systems easier. But how does that work?
Dave gave an outline. I'm liking this. What are the downsides, if any?
The downside is that it introduces a
On 6 December 2012 16:44, Domenic Denicola dome...@domenicdenicola.com wrote:
For the record, here's the idea Yehuda and I worked out:
https://gist.github.com/1ab3f0daa7b37859ce43
I would *really* appreciate if people read it (it's easy reading, I
promise!) and incorporated some of our
On 6 December 2012 17:25, Claus Reinke claus.rei...@talk21.com wrote:
I was hoping for something roughly like
let lhs = rhs; statements
// non-recursive, scope is statements
let { declarations }; statements// recursive, scope is
declarations and statements
Problem is
On 6 December 2012 17:33, Kevin Smith khs4...@gmail.com wrote:
The downside is that it introduces a severe anomaly into the module
semantics (a module which actually has no instance). I could live with
this feature if we were to find a way to explain it in terms of simple
syntactic sugar on
On 6 December 2012 17:46, Matthew Robb matthewwr...@gmail.com wrote:
What about trying it the other way, flip everything.
import foo as bar;
import foo as { baz }
Hm, I don't understand. What would that solve?
/Andreas
___
es-discuss mailing list
On 5 December 2012 02:46, Brendan Eich bren...@mozilla.org wrote:
Also, good luck getting SunSpider or V8/Octane to enable use strict!
Paging Dr. Rossberg on the latter :-P.
Octane actually contains two benchmarks running in strict mode, namely
PDF/JS and GameBoy. (Unfortunately, I just
On 4 December 2012 14:28, Claus Reinke claus.rei...@talk21.com wrote:
Could you please document the current state of concerns, pros and
cons that have emerged from your discussions so far? You don't
want to have to search for these useful clarifications when this topic
comes up again (be it in
Or to null, which is exactly what the new semantics decided to do. ;)
/Andreas
On 29 November 2012 17:11, Dave Fugate dave.fug...@gmail.com wrote:
Should be: 'caller' to false :)
On Thu, Nov 29, 2012 at 9:10 AM, Dave Fugate dave.fug...@gmail.com wrote:
'caller' to true
On 28 November 2012 12:50, Marius Gundersen gunder...@gmail.com wrote:
Has there been any work done on pure functions in EcmaScript? The way I
imagine it, there would be a way to indicate that a function should be pure
(by using a symbol or a new keyword, although I understand new keywords
On 28 November 2012 14:39, Marius Gundersen gunder...@gmail.com wrote:
On Wed, Nov 28, 2012 at 1:20 PM, Andreas Rossberg rossb...@google.com
wrote:
First, your definition of pure is not quite correct. Any function
that even _returns_ locally created state in some form (i.e., a new
object
On 29 November 2012 00:16, Dave Fugate dave.fug...@gmail.com wrote:
Believe you're correct on the former, but perhaps not the latter=)
E.g.:
6 /**
7* @path ch15/15.3/15.3.5/15.3.5.4/15.3.5.4_2-1gs.js
8* @description Strict mode - checking access to strict function
?
I suppose so, but was that the intention? Either way, there currently
is no test that actually tests step 2.
/Andreas
On Wed, Nov 28, 2012 at 4:43 PM, Andreas Rossberg rossb...@google.com
wrote:
On 29 November 2012 00:16, Dave Fugate dave.fug...@gmail.com wrote:
Believe you're correct
On 20 November 2012 17:26, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Yes, property descriptor records can't act like accessors. They are just
specification internal records that indicate that a set of values is being
passed around. But we can censor the value that goes into the record.
On 21 November 2012 01:06, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Tom Van Cutsem tomvc...@gmail.com wrote:
Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Tom Van Cutsem tomvc...@gmail.com wrote:
c) to ensure the stability of the result.
You can think of a + b as implementing a type
On 20 November 2012 21:30, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 20, 2012 at 10:57 AM, Mark S. Miller erig...@google.com wrote:
I think adding a MultiMap API to ES7 is a good idea. Neither Map nor
MultiMap should be a subclass of the other, since neither is an LSP
subtype of
On 21 November 2012 17:55, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I'd be more favorably inclined towards freezing than I am towards copying.
But, as you know, ES5 does not currently produce frozen objects in these
situations. I feel uncomfortable about enforcing a frozen invariant
On 21 November 2012 18:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
If you are writing any sort of generic algorithm that does a freeze check on
an arbitrary object you have to explicitly perform all of the internal method
calls because you don't know whether the object is a proxy
On 16 November 2012 22:19, Jeff Walden jwalden...@mit.edu wrote:
On 11/16/2012 07:06 AM, Brendan Eich wrote:
So it seems to me premature to throw on [[GetOwnProperty]] of a strict
function's 'caller'. It would be more precise, and avoid the problem you're
hitting, to return a property
On 16 November 2012 22:01, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
P.S. Alex, just to be as clear as possible, one answer I did not like that
much was that eval('no strict') nonsense ... that was not an answer 'cause
problems are the same with eval('use strict')
No, they are not.
On 19 November 2012 13:04, David Bruant bruan...@gmail.com wrote:
I wish to point out a little thought on the topic of memory management. As
far as I know, all GC algorithms I'm aware of are runtime algorithms,
meaning that the primitives of these algorithms are objects and references
between
Consider the following code:
function f() { use strict; g() }
function g() {
var caller = Object.getOwnPropertyDescriptor(g, caller).value
}
With the current spec, this code would legally give g the strict
function f as its caller. In
On 14 November 2012 20:37, Tom Van Cutsem tomvc...@gmail.com wrote:
I still think futures connote strongly with blocking synchronization. If
we'd add a concept named future to JS on the grounds that the same concept
exists in Java and C++, developers will reasonably expect a blocking
On 15 November 2012 20:58, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I am talking about caller which is NOT a misfeature
Indeed, misfeature is putting it too mildly.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
On 15 November 2012 21:20, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
thanks for your contribution to this thread, appreciated. I'd like a proper
answer now if that is possible.
You already got rather strong answers from two members of TC39. It's
safe to assume that the rest feels
On 14 November 2012 09:30, Tom Van Cutsem tomvc...@gmail.com wrote:
2012/11/13 David Bruant bruan...@gmail.com
For the particular case you've written, when going for hasOwnProperty.call
or the in operator, the JS engine knows it needs to output a boolean, so it
can rewrite (or contextually
On 14 November 2012 18:41, Mark S. Miller erig...@google.com wrote:
Either way, Scala's
unfortunate choice clearly violates this history in a confusing manner, so
I'd classify it as #4. Let's not repeat Scala's mistake.
Just to reiterate, it's not just Scala, but more importantly also C++,
On 12 November 2012 02:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It isn't clear to me why the [[HasOwnProperty]] internal method and the
hasOwn Proxy trap need to exist as object behavior extension points.
Within my current ES6 draft, [[HasOwnProperty]] is only used within the
On 7 November 2012 22:19, Mark S. Miller erig...@google.com wrote:
On Wed, Nov 7, 2012 at 11:12 AM, Andreas Rossberg rossb...@google.com
wrote:
On 7 November 2012 17:57, Tom Van Cutsem tomvc...@gmail.com wrote:
While we're talking nomenclature: the terms promise and future also
appear
On 12 November 2012 16:43, Mark S. Miller erig...@google.com wrote:
The shift back to when clearly failed to achieve consensus.
FWIW, I think then is better, because when sounds as if it should
be passed some kind of predicate or condition. It just doesn't read
very natural when taking
On 6 November 2012 20:55, David Herman dher...@mozilla.com wrote:
- a way to create promises that don't expose their internal resolve me
methods, etc. so they can be delivered to untrusted clients, e.g.:
var [internalView, externalView] = Promise.makePair();
resolve in internalView
On 7 November 2012 17:57, Tom Van Cutsem tomvc...@gmail.com wrote:
While we're talking nomenclature: the terms promise and future also
appear, with roughly the semantics described by Andreas in Scala's API [1]
and Clojure's API [2] (both very recent APIs). I know MarkM dislikes the use
of
On 31 October 2012 10:40, David Bruant bruan...@gmail.com wrote:
My bug was about making the use of objects [for property descriptors]
official in the spec internals... until I realized that ES6 has maps.
Can you motivate why maps would be more adequate? Frankly, I
completely disagree, because
On 11 October 2012 09:32, Brendan Eich bren...@mozilla.org wrote:
Tom Van Cutsem wrote:
- Proxy.revocable returns a tuple {proxy, revoke}. While more cumbersome
to work with (especially in pre-ES6 code without destructuring), this API
gets the authority to revoke a proxy exactly right: at
On 11 October 2012 13:41, Mark S. Miller erig...@google.com wrote:
On Thu, Oct 11, 2012 at 4:25 AM, Andreas Rossberg rossb...@google.com
wrote:
On 11 October 2012 09:32, Brendan Eich bren...@mozilla.org wrote:
Tom Van Cutsem wrote:
- Proxy.revocable returns a tuple {proxy, revoke}. While
On 11 October 2012 17:49, John J Barton johnjbar...@johnjbarton.com wrote:
Script is not neutral but neither is Program plus it's just wrong.
The language needs a name for both the unit of compilation and the
assembly of those units. The latter is a program right? So the former
needs a
On 9 October 2012 01:55, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
Let me try again. How about the following desugaring?
function f(x1 = e1, ~~~, xN = eN) { body }
means
function f(x1, ~~~, xN) {
if (x1 === undefined) x1 = e1;
~~~
if (xN
On 6 October 2012 02:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Bottom line,
I suggest we implement proposal 3, rather than the temporary conclusions
that were discussed at the Sept. meeting.
Of the options you suggest, I also think that #3 is preferable.
However, your examples have
On 8 October 2012 18:24, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
You desugaring would break ES=5.1 compatibility for:
(unction (p) {
var p;
return typeof p
})(test)
ES5.1 returns string, your desugaring returns undefined
I'm probably just being blind, but I'm not seeing it.
On 8 October 2012 19:18, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 8, 2012, at 10:04 AM, Andreas Rossberg wrote:
On 8 October 2012 18:24, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
You desugaring would break ES=5.1 compatibility for:
(function (p) {
var p;
return
On 5 October 2012 14:26, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith khs4...@gmail.com wrote:
Sounds good. As an aside, does the symbol in this case provide any function
other than wrapping the string itself? Does the symbol carry any
information
On 3 October 2012 05:38, Brendan Eich bren...@mozilla.com wrote:
Which is more important, iterating over holes (preserved if possible), or
skipping them and therefore spreading array-likes but not iterables?
I, for one, couldn't care less about holes. We shouldn't compromise
any useful feature
On 1 October 2012 21:17, Dean Landolt d...@deanlandolt.com wrote:
Fair enough. But is there any value in a new typeof result? I surely can't
see any. It's broken beyond repair -- I don't see the use in breaking more
code trying to salvage it :P
There isn't much value in a new typeof result as
On 30 September 2012 02:17, Brendan Eich bren...@mozilla.org wrote:
Failing to consult with implementors will just make editing churn. I don't
remember much discussion on this change, if any -- we did talk about the
general problem of prototype objects being firstborns of their class, and
how
On 29 September 2012 20:14, Rick Waldron waldron.r...@gmail.com wrote:
Offline discussion with Dave that immediately identified a deal-breaker: if
typeof symbol were string, it would break ===.
=== for strings is based on their contents
=== for objects is based on their identity
Well, that's
On 30 September 2012 00:08, Brendan Eich bren...@mozilla.org wrote:
I think this is too philosophical a discussion to result in a strong reason
to risk symbol. Just my gut-check. Other TC39ers should weigh in (Andreas
R. especially).
Type symbol would be my preference, but it is difficult to
On 28 September 2012 18:28, Tom Van Cutsem tomvc...@gmail.com wrote:
I agree that proxying a symbol is of little value, but I didn't say that
symbols are closer to strings than to objects. I think symbols are closer to
objects: they have an unforgeable identity. Strings don't have that, objects
On 28 September 2012 03:30, Bill Frantz fra...@pwpconsult.com wrote:
(BTW -
I know of no completely specified languages, or other computer system
components for that matter, but the closer the specification comes to being
complete, the better).
Off-topic, but I can't resist pointing out here
On 26 September 2012 00:23, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Sep 25, 2012, at 1:30 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I think we should go the all AssignmentExpression route. It avoid
ArrayLiteral-like comma confusion in all three positions. It is also a
On 26 September 2012 15:02, Brendan Eich bren...@mozilla.com wrote:
Let's agree that AssignmentExpression is ok (required for the left-most
comprehension expression). The main nannying objection was to trying to ban
= at top level of if and for heads.
If we can settle on this, I'm ok with it
On 26 September 2012 16:02, Jason Orendorff jason.orendo...@gmail.com wrote:
The main drawback of comprehensions is the temptation to get clever.
It might seem that providing 'let' in comprehensions would exacerbate
that, but on balance I think it actually helps.
I agree on both accounts, and
On 24 September 2012 20:53, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote:
I think it's just the matter of the need. If these optional argument types
are very needed by devs, then it's probably not a big deal to add them to
the standard -- after all it's still in the draft, not published
On 25 September 2012 15:31, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
That's a hell of a question ... shapes speaking I'd say structural, since
AFAIK shapes are those boosted up more, isn't it?
That would solve String VS string and Array VS Arguments which is, I
believe, kinda
On 25 September 2012 17:50, John Lenz concavel...@gmail.com wrote:
The problem with structural types in a dynamic language is that the checks
are potentially costly. I'm not sure this is true for today's VMs or not
(are the hidden classes they use sufficient to make these checks efficient?)
On 25 September 2012 17:57, John Lenz concavel...@gmail.com wrote:
One thing that I have seen specifically, is that supporting non nullable
types, and distinguishing between undefined and null in the type
signature creates a fair amount of busy work (type casts to remove
nullability) for
On 17 September 2012 18:37, Luke Hoban lu...@microsoft.com wrote:
'let' is certainly not going to be faster than 'var' in any case
There is at least one very important counterexample to that claim: the
global scope. Assuming lexical global scope (as we tentatively agreed
upon at the last
On 18 September 2012 13:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Yes but but there are fairly simple heuristics that approximate that result,
for example:
if no function calls dominate the initialization of x then TDZ checks will
never need to be made for x
Yes, except that in
On 29 August 2012 18:39, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
There are been various previous runs at defining syntactic support for using
unique/private names. They all run into either real or hypothetical
usability issues that blocked adoption. One consistent area of concern has
401 - 500 of 778 matches
Mail list logo
