Brendan Eich wrote:
On Aug 21, 2008, at 8:21 AM, Peter Michaux wrote:
I think that the let statement
let (x = 2, y = x) {
print(y);
}
should desugar to exactly
(function(x, y) {
print(y);
})(2, x)
We've been over this. What if you replace print(y) with return y?
I had
Sam Ruby wrote:
On Fri, Aug 22, 2008 at 4:18 PM, Waldemar Horwat [EMAIL PROTECTED] wrote:
Sam Ruby wrote:
On Fri, Aug 22, 2008 at 3:55 PM, Waldemar Horwat [EMAIL PROTECTED] wrote:
Here's a question for you:
What should the full result of converting 1.1 to a Decimal be in
ECMAScript
Sam Ruby wrote:
On Fri, Aug 22, 2008 at 7:07 PM, Waldemar Horwat [EMAIL PROTECTED] wrote:
Sam Ruby wrote:
I find it easier to talk about real examples than abstractions. I've
done the following quickly, so forgive me if I get some detail wrong.
A binary floating point number has 52 bits
What should compareTotal do when you compare -NaN and NaN?
Waldemar
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
We're going round in circles on a few issues surrounding Decimal. Some of
these have clear resolutions; others have a little wiggle room. Here's my
summary:
- Should decimal values behave as objects (pure library implementation) or as
primitives?
If they behave as objects, then we'd get
Brendan Eich wrote:
- Should decimal values behave as objects (pure library
implementation) or as primitives?
If they behave as objects, then we'd get into situations such as 3m !=
3m in some cases and 3m == 3m in other cases. Also, -0m != 0m would
be necessary. This is clearly
Mark S. Miller wrote:
In both cases, it would seem that new numeric types must still be added
by the language's providers rather than the language's users. This is
the tragic constraint that none of the present proposals have been able
to escape. I would much rather see us work on that
I might change my mind when I see it, but this sounds really scary. There are
all kinds of places where dependencies on identifier names, global objects not
having changed, etc. can sneak in.
Waldemar
Mark S. Miller wrote:
The Redmond mtg is fast approaching. We'd like to put out an
Mike Cowlishaw wrote:
There is still a blocking issue that's been discussed a lot but left
off the issues here:
- Treatment of cohorts in the default conversion of decimal to
string. Despite objections, I still get the following results:
1/3m - 1/3m produces 0e-34
1e12m - 1e12m produces
What parts should I look at? The decimal stuff in the document is inconsistent
and looks like it's not ready for review yet.
Waldemar
Pratap Lakshman (VJ#SDK) wrote:
I have uploaded to the wiki (link
http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft)
the 22
Since no one else has posted notes, I will. This is not meant to be a complete
summary; it's just the notable items that I happened to write down. These are
*not* minutes of the meeting.
- The current plan is to submit ES3.1 to a vote at the June 2009 ECMA General
Assembly. The successor
Igor Bukanov wrote:
2008/10/3 Waldemar Horwat [EMAIL PROTECTED]:
An open issue is whether const violations should be compile or run-time
errors. Clearly some of them are undecidable and can only be reported at
run-time, but what about the clear-cut cases?
{
a = x;
const x = 2
Brendan Eich wrote:
After some experiments, we decided for ES4 to make let and var the
same at top level in a function or global code.
This helped avoid implementation pain: very long scripts on the web,
consisting of many statements in a row, motivate statement-wise
parsing and
Brendan Eich wrote:
The agreement from the May TC39 meeting was that the declarations
implicit (:*) and explicit annotations must normalize to the same
type, or there's an error.
That was back when the language had lots of requirements for compile-time
expressions, including on all types.
Brendan Eich wrote:
If using an uninitialized let binding is an error, then hoisting is
pointless except to make the statements between start of block and the
let declaration a dead zone for the binding name. This fits the
ancient, weak but not entirely worthless post-hoc rationale for
Brendan Eich wrote:
On Oct 13, 2008, at 3:56 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
The agreement from the May TC39 meeting was that the declarations
implicit (:*) and explicit annotations must normalize to the same
type, or there's an error.
That was back when the language had
Mark S. Miller wrote:
On Sat, Oct 11, 2008 at 9:11 AM, Peter Michaux [EMAIL PROTECTED] wrote:
I think it would be ok to have only unnamed lambdas. (It would be ok
to have named lambdas too.)
I think we should not introduce named lambdas because then we'd need
to decide whether the scoping
Brendan Eich wrote:
On Oct 13, 2008, at 4:01 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
If using an uninitialized let binding is an error, then hoisting is
pointless except to make the statements between start of block and the
let declaration a dead zone for the binding name. This fits
David Herman wrote:
Also, I wonder why lambda in it's block-less form is restricted to
expressions.
I'm with you... but I'd want to check with the experts on the ES grammar to
see whether this introduces any nasty ambiguities.
Please specify what you are proposing. The one proposal I've
Brendan Eich wrote:
On Oct 13, 2008, at 5:29 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
On Oct 13, 2008, at 3:51 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
After some experiments, we decided for ES4 to make let and var the
same at top level in a function or global code.
...
You
Brendan Eich wrote:
What did you mean by had better fail to compile? Other than the
type annotation, there is nothing about
function f() {
x = 15;
...
var t = some_runtime_expression;
...
var x:t = ...
}
that ought to fail to compile.
The assignment to x in that temporal dead
David-Sarah Hopwood wrote:
David-Sarah Hopwood wrote:
Waldemar Horwat wrote:
I am talking about let bindings. Lars brought up at that meeting. I did
not find the use cases particularly convincing, but the dead zone is
compelling. There are four ways to do this:
A1. Lexical dead zone
Jon Zeppieri wrote:
On Mon, Oct 13, 2008 at 10:48 PM, Mark S. Miller [EMAIL PROTECTED] wrote:
You're right. However, the desugaring is more complex than I expected.
Thanks for asking me to write it down.
for (keyword varName = initExpr; testExpr; updateExpr) { body }
desugars to (hygienic
Dave Herman wrote:
Please specify what you are proposing. The one proposal I've seen is:
Expression ::= ... | lambda Formals Statement
Yes, that's what I meant, or at least what I thought Yuh-Ruey meant.
This is not particularly useful because then even assign a lambda to a
variable
Brendan Eich wrote:
On Oct 15, 2008, at 2:36 PM, Waldemar Horwat wrote:
There is no such thing as a let expression.
Let expressions
http://developer.mozilla.org/en/New_in_JavaScript_1.7#let_expressions in
JS1.7 (Firefox 2+), based on the ES4 proposal
http://wiki.ecmascript.org
Brendan Eich wrote:
On Oct 16, 2008, at 11:38 AM, Waldemar Horwat wrote:
Brendan Eich wrote:
That's not a valid grammar.
It is unambiguous. How do you define valid?
You can't have an AssignmentExpression terminating a
PrimaryExpression. It leads to trouble such as:
let a = b + c
Dave Herman wrote:
I don't see enough of a benefit to warrant inclusion of a new lambda
concept. It's just another way of doing what local functions can do.
As I see it, the major benefits of `lambda' are
a) introducing a low-level and compositional primitive that is useful
for code
Brendan Eich wrote:
On Oct 16, 2008, at 1:55 PM, Waldemar Horwat wrote:
var: Not an issue if you're not using var inside the lambda. Code
generation that wants to use lambda would use var why?
arguments: Again, not an issue if you're not using the arguments
array. If a code generator
Dave Herman wrote:
b) creating a clearer place in the language syntax to enforce tail
calling by eliminating `return'
I don't understand what you mean in point b.
Consider two different syntaxes for a function performing a tail call:
lambda(x) { f(x) }
function(x) { return f(x)
Brendan Eich wrote:
On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote:
I don't think you can come up with a consistent shift or greedy
notion.
Funny, yacc has had one for decades, used to resolve dangling-else.
The one you may be thinking of will happily accept code such as
let
Brendan Eich wrote:
On Oct 16, 2008, at 7:04 PM, Waldemar Horwat wrote:
The parser is required to backtrack until it either finds an expansion
of the grammar that doesn't generate a syntax error or until it
discovers that they all do. You can choose to make additional syntax
errors
Maciej Stachowiak wrote:
I think it might be better to write the official ES3.1 grammar in this
way, even though it is a little annoying and repetitive, so it can more
readily be verified that the language grammar has no ambiguities by
running through a parser-generator like yacc or bison
Here's a clearer case that Firefox gets wrong (or your grammar gets wrong,
depending on your point of view):
function f() {return f}
var x = 3;
let (a = 1) a ? f : x++();
The grammar states that the last statement must evaluate to f. Firefox gives
a syntax error. This is incorrect because
Dave Herman wrote:
What is your point? To write a recursive factorial I'd write either:
lambda f(x) {
if (x == 0)
1;
else
f(x - 1);
}
or:
function f(x) {
if (x == 0)
return 1;
else
return f(x - 1);
}
Right, good, so far we're on the same page.
Either one is subject
Brendan Eich wrote:
On Oct 17, 2008, at 3:47 PM, Brendan Eich wrote:
On Oct 17, 2008, at 3:39 PM, Brendan Eich wrote:
Er, you are right, I should have acknowedged this point. The rest of
my post is about x++() not being a valid sentence, which supports your
argument.
While we don't have
Eric Suen wrote:
I think top-down parser has no issue to parse following code:
function() {
}();
but this is not a valid statement because:
ExpressionStatement ::= [lookahead ! {{, function}] Expression ;
There is a good reason for that. It's because of semicolon insertion. You'd
Dave Herman wrote:
Do you see where I'm going with this? It's a pretty natural idea. The
branches of an if-statement can be in tail position because they are the
last thing produced by the if-statement. Some things like loop forms and
switch won't be able to contain tail positions because
Brendan Eich wrote:
Followup to discuss some open issues from the thread, evident in the
message cited below:
1. Unifying var scope and let scope at top level of a function could be
done, with tolerable restrictions: given let x at top level in a
function body, existence of formal
Mark S. Miller wrote:
The indexOf and lastIndexOf methods are new in ES3.1, and are the only
methods in the entire spec that depend on ===.
Strictly speaking that's true, but only because the switch statement is not a
method. switch statements depend on ===.
Waldemar
Mark S. Miller wrote:
11. If the [[Class]] property of /G/ is *Function*, then
1. Get the *length* property of /G/.
2. Let /L/ be Result(11a) minus the length of /A/.
What does minus mean here? Result(11a) could be anything.
Waldemar
As you noted, we can't break existing usages of var:
if (foo)
var x = 3;
As such, var statements should be considered to be substatements and allowed
anywhere. The declaration scope syntax rules would only apply to const and
function declarations (and, in the future, let).
I don't see any
Here are my preliminary comments. I haven't reviewed the entire draft yet.
Waldemar
Overall: With const missing, the changes to chapter 8 for attribute description become premature
standardization and should be cut. The problem is that these changes are likely to be incompatible with
More comments.
Waldemar
11.1.5: This means that I can override a getter with a value property or
specify two getters for the same property even in strict mode. We had agreed
that strict mode disallowed such things.
11.2.1: where identifier-name-string is a string literal containing
Waldemar Horwat ([EMAIL PROTECTED]
650-253-5868).
Waldemar
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
7: Should we replace the two instances of LineTerminator in the grammar at the
beginning of the chapter to LineTerminatorSequence? It doesn't make any
difference as far as the grammar is concerned, other than implying unwritten
expectations for counting line numbers. The downside is that
Here are my notes on today's TC39 ES3.1 discussions. We resolved a lot of
issues, which I hope I recorded all below.
Waldemar
John and Allen want a flag date to issue s press release about a candidate
spec. Change control may be locked down after that?
Waldemar: ECMA should not be the
Here are my meeting notes from all three days of the meeting.
Waldemar
SES meeting Jan 27 2009:
ES3.1 opens up the possibility of exposing protected objects to unprotected
code and have the protected objects stay safe. Maybe not: toSource, watch (to
set watchpoints on properties),
There is some confusion between section 7.8.5 and chapter 16 in the latest
ES3.1 draft. Section 7.8.5 states that an implementation may extend the
regular expression constructor grammar, which presumably implies that it does
not have to report all syntax errors in the ES3.1 regular expression
Brendan Eich wrote:
I’ve tried various formulation of a simple statement about host
objects but I keep finding potential holes and coming back to the
conclusion that the only meaningful thing to do is to explicitly
enumerable the invariants associated with each predefined [[Class]]
value.
Are there implementations that throw it? I thought there was at least one.
Waldemar
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
If we no longer throw EvalError, we should take the class out of the body of
the spec too. It just clutters things up.
The obvious place for such obsolete things is Annex B. It contains such gems
as Date.getYear and octal digits in literals.
Waldemar
Allen Wirfs-Brock wrote:
Now that we have decided that all declarations of the identifier “eval”
are banned from strict code a related question has come up from one of
the implementers of our strict mode prototype implementation.Why
does Es3.1 still allow assignment to the identifier
What are you trying to do? Exclude all scripts that use the operator?
Waldemar
David-Sarah Hopwood wrote:
Suppose that S is a Unicode string in which each character matches
ValidChar below, not containing the subsequences !, / or ]], and
not containing ( followed by a character not
David-Sarah Hopwood wrote:
I'll repeat my argument here for convenience:
A DivisionPunctuator must be preceded by an expression.
A RegularExpressionLiteral is itself an expression.
(This assumes that the omission of RegularExpressionLiteral from
Literal is a bug.)
Therefore, for there
Allen Wirfs-Brock wrote:
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sorry, I meant the issue James raised: the property is bound and then
RangeError is thrown. Seems like error-checking should happen before
any effects are committed.
In general, it's probably
This whole thing is another nail in the coffin of generators. Generators are
the root of the troublesome longjmp's which don't play well with others.
Waldemar
Brendan Eich wrote:
To make this clear with an example (thanks to Jason for some IRC
interaction):
function gen(arg) {
Brendan Eich wrote:
On May 14, 2009, at 6:04 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
On May 14, 2009, at 1:47 PM, Waldemar Horwat wrote:
This whole thing is another nail in the coffin of generators.
Generators are the root of the troublesome longjmp's which don't
play well
Douglas Crockford wrote:
Waldemar Horwat wrote:
2) Do we want to permit conforming implementations to extend the JSON
grammar that they recognize? This probably could be done by
extending the syntax error extension allowance in section 16 to
include the JSON grammar. If we allow
Douglas Crockford wrote:
Waldemar Horwat wrote:
OK, so we need not discuss any new numeric types any further in
committee because it would be impossible to round-trip them through
JSON. Do we have agreement on that?
Not necessarily. What we can agree on is that new numeric types cannot
are
available in Mountain View, Sunnyvale, Palo Alto, or, if you rent a car and
prefer a more urban but faraway environment, San Francisco. There are no
hotels within walking distance of the Google campus.
For questions, please email the hosts Waldemar Horwat (walde...@google.com
650-253-5868
Brendan Eich wrote:
I will stop the over-citing madness here and now :-P.
The struggle to formalize ArrayLike, which seems like a common goal for
ES the core language and for WebIDL's ES bindings, makes me want to give
an exception to the catchalls considered harmful for new interfaces
Maciej Stachowiak wrote:
Perhaps when catchalls are considered for ECMAScript, there could b a
way to encapsulate the specific pattern of index access, so you can have
magical getters and setters for all index properties (integer numbers in
range to be an array index) without having to install
Brian Kardell wrote:
Uh oh... Patrick looking at the same parts as me reacting the same way
(I believe older pre-5 docs also said something similar)...
When Oliver said All ES implementations are required to... I assumed
that I missed something in the new 5 docs - not that everyone just
seems to
Brian Kardell wrote:
It sounds to me like there is wide agreement in the sense that at
least the basics rules and only disagreement on the fringes...
Otherwise no one on this list in particular would be suggesting that
there is anything remotely like a de facto implementation... It
seems that at
This proliferation of little function objects is one of the things that the
various class proposals are addressing.
Waldemar
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Congratulations!
ES5 was officially approved as an ECMA standard at the ECMA General Assembly
held at Google yesterday. The vote, with 2/3 required to pass, was 19 yes and
2 no, with IBM voting no due to the lack of decimal and Intel voting no because
they didn't have enough time to study
Mike Samuel wrote:
That's the case right now, except that to escape a backtick one does
$\` instead of \`.
Having `\`` not do what I'd expect escaping to do truly surprised me. I
thought that this was just a bug in the grammar when I read the wiki page.
The grammar has other bugs having to
David Herman wrote:
Your answers keep leaving out the definition of the function that you're calling
via `-', which is supposed to be the part that creates the requisite object
with `continueWith' etc. Examples don't do much good if they skip the part they
were supposed to illustrate!
I
David Herman wrote:
We've given this quite a bit of time, and I don't know how far we're going to
get in understanding all the details of your proposal. But I think I can
address some of my disagreements.
1) I'm skeptical whether the requirement you stated of future-proofing code for
async
David Herman wrote:
Thinking about continuations
http://calculist.blogspot.com/2010/04/thinking-about-continuations.html
Your attempted fix for evaluating finally blocks just moved the problem
elsewhere. Since in the final expression you have A(... A(x)), you'll just end
up
Having unspecified endianness in the specification of TypedArrays seems like a
show-stopper to me. There are two alternatives here:
- If you do any I/O, you want the endianness to be specified. Sending data
from one process to another with a different endianness would get you into
trouble.
Here are my notes for today's meeting.
Waldemar
Khronos: standard-setting consortium
Khronos standards are royalty-free (any essential patents must also be
royalty-free).
We'll have a joint meeting with them on Tuesday 3PM.
Khronos categories of members: adopters and implementors.
Brendan Eich wrote:
There's an issue with float32 -- IIRC it does not project into float64
(AKA double). All the other types (uint32, what I schematically named
u32 above, etc.) do.
What? The set of all float32's is a proper subset of the set of all float64's.
When devising scalar types for
Brendan:
To clear up something that misled me when reading the first few messages of
this struct thread:
I assume that the proposal is that:
const TA =
Array.newTypedArray(fixed_length,
Object.newStructType({x:u32, y:u32, z:u32,
ihab.a...@gmail.com wrote:
// one.js:
import jQuery.ajax;
module Two = load 'two.js';
// two.js:
import jQuery.ajax;
At the time that one.js was written, two.js did not contain a
reference to Drawing. Now, unbeknownst to the author of one.js,
two.js changed and now refers to
ihab.a...@gmail.com wrote:
On Tue, Jun 1, 2010 at 6:26 PM, Waldemar Horwat walde...@google.com
mailto:walde...@google.com wrote:
I don't understand your example of how this is supposed to work in
the regular (non-accidental-aliasing) case. As you wrote in your
example, two.js
Brendan Eich wrote:
So either we lose this refactoring equivalence:
b = a[i];
b.x = 42;
assert(a[i].x === 42);
This assertion botches with Sam's proposed semantics.
Or else we lose the other equivalence, if we reify a struct-view-object
on element extraction (rvalue):
a[j] = a[i];
a[j].x =
Oliver Hunt wrote:
If b is not an alias to /a[i]/ then the code
a[i].x += 1;
Could not modify /a[i]/ itself, effectively we've created an immutable type.
That does not logically follow. See my previous message for why.
Waldemar
___
es-discuss
Peter van der Zee wrote:
My vote would go to leave function as it is, if not then to use lambda or florin
and otherwise something like the above. Reserve # and @ for new syntax.
I second that.
Waldemar
___
es-discuss mailing list
Maciej Stachowiak wrote:
On Jul 25, 2010, at 5:06 PM, Brendan Eich wrote:
Mark's restricted production idea is on target, if we think it's worth doing.
At least in C or C++, I've seen code like this:
veryLongObjectName.someOtherVeryVeryLongObjectName.ridiculouslyLongFunctionName
Erik Arvidsson wrote:
3. Why isn't there a way to iterate over the keys?
Because then it would be a regular map, not a weak map. This is something that
only a debugger should be able to do.
Waldemar
___
es-discuss mailing list
Here are my raw notes for today's meeting.
Waldemar
Excellent Japanese ISO comments!
Discussion of the comment on 7.9.1:
BreakStatement:
break [no LineTerminator here] Identifier-opt ;
means:
BreakStatement:
break [no LineTerminator here] ;
break [no LineTerminator here]
Here are my raw notes from our second day.
Waldemar
Catch guard proposal, resurrected from 1998. Well-liked all around.
Proposed to move into Harmony if there are no objections by the next
meeting.
MarkM speculating: Could the if syntax be extended to pattern
matching? Not easily.
On 10/01/10 18:49, Brendan Eich wrote:
It's not clear what private names are trying to do well. If they want
to provide privacy, they can't be visible to proxies. If they want to
provide extension without collision (i.e. namespacing), they should be
visible to Object.keys, enumeration, etc.
On 10/14/10 08:11, Brendan Eich wrote:
On Oct 13, 2010, at 11:56 PM, Erik Corry wrote:
The semantics for const in Harmony are likely to be silently different
in Harmony from the semantics it has in non-strict current
implementations. (In particular the current const is hoisted to the
On 11/12/10 15:04, Brendan Eich wrote:
On Nov 12, 2010, at 2:52 PM, Marc Harter wrote:
After considering all the breadth this discussion could take maybe it
would be wise to just focus on one issue at a time. For me, the biggest
missing feature is lookbehind. Its common to most languages
Here are my very rough notes for today's IDL discussions. In many
cases I couldn't tell what was actually decided rather than merely
discussed.
Waldemar
IDL day: Lots of discussions, exploring various points and making
suggestions. Mostly exploratory -- not in the proper frame
Here are my meeting notes for today.
Waldemar
WebIDL: Can abstract interfaces have static members? Don't see why
not -- they'd just be spec sugar for adding the same static member to
concrete classes that derive from those abstract interfaces. As
usual, it would be a spec error to have a
Third day rough meeting notes.
Waldemar
instanceof trap for proxies: Withdrawn. Agreed to drop it for now.
Proxy default forwarding handler. Agreed that there should be an easy
way to delegate to a default forwarding handler.
Waldemar: Why not use prototypes to do this?
MarkM, others:
On 11/22/10 10:13, Brendan Eich wrote:
{ foo : G : 33 }
0. let typedObj = { foo : 33 } : { foo : G }; // a la ES4
1. let typedObj = { foo :: G : 33 }; // the guards strawman
2. let typedObj = { (foo : G) : 33 }; // the ML-ish way
3. let typedObj = { foo @ G : 33 };
On 11/22/10 15:16, Brendan Eich wrote:
{name: type = value} // Adding a type annotation
Isn't the last ambiguous with legal JS today (well, with const, but that's not
important AFAICT):
Yeah, you're right. This won't work.
Waldemar
___
On 11/23/10 11:12, Brendan Eich wrote:
for (k in keys(o)) ...
for (v in values(o)) ...
for ([k, v] in properties(o)) ...
What are keys, values, and properties here? Global functions? How would
a new object abstraction T customize them just for instances of T?
Waldemar
On 11/22/10 20:18, Bga wrote:
// es3 way
(function()
{
var x = 1;
return function()
{
return ++x;
}
})();
// current es6/SM1.8 way
let(x = 1) function()
{
return ++x;
}
// new more readable sugar
function()
{
static x = 1; // hello c/c++
return ++x;
}
On 11/23/10 13:05, David Herman wrote:
How would a new object abstraction T customize them just for instances of T?
By writing its own custom iteration protocol via proxies with the iterate()
trap implemented appropriately. E.g.:
function MyCollection() { }
MyCollection.prototype = {
On 11/23/10 15:18, Allen Wirfs-Brock wrote:
- How far does static hoist? One let-scope? One block-scope? One
function-scope? One class-scope?
AWB: the simple answer would be one block-scope (isn't that the same as
a let-scope??). It probably will take some experimentation to verify
that the
Here are my rough notes for today's meeting.
Waldemar
--
Internationalization standard: Part of E262 or separate track? Pros
and cons to each one, and either would be workable. There is a
substantial area of interaction (ES5 locale methods, normalization,
and such) between
Once again, here are my raw meeting notes.
Waldemar
--
Discussion of isNaN and isFinite.
Can/should we fix these in place rather than creating more functions?
Allen: Existing usage is consistent with normal numeric coercions
done by other operators such as -.
Doug: Would it
On 02/25/11 13:26, Brendan Eich wrote:
On Feb 25, 2011, at 1:12 PM, Boris Zbarsky wrote:
On 2/25/11 4:08 PM, David Bruant wrote:
I would tend to be more in favor of disallowing Harmony features in
non-strict code (without explicit use strict directive) to avoid
surprises (I'm nuancing below).
On 02/20/11 21:16, Mark S. Miller wrote:
The specification of Math.LOG10E says:
15.8.1.5 LOG10E
The Number value for the base-10 logarithm of e, the base of the natural
logarithms; this value is approximately 0.4342944819032518.
This property has the attributes { [[Writable]]:
On 03/21/11 13:13, Erik Arvidsson wrote:
The thread about using private names is getting a bit unwieldy but I'd
like to focus on the use case that I have been thinking of as
Lexically scoped monkey patching or Lexically scoped object
extensions instead of focusing on how to use private names to
1 - 100 of 235 matches
Mail list logo
