On Mon, Oct 28, 2013 at 4:03 PM, Brendan Eich bren...@mozilla.com wrote:
Tristan Zajonc wrote:
Having === be reference equality is fine if that's a hard JS requirement.
For a matrix API, there is some flexibility on comparison operators, but
transient value comparison returning a single
On 10/28/13 7:54 PM, Jonas Sicking wrote:
Lets just return a frozen Array.
That works for .ports, I think, but not for the gamepad API case: in
that case the array can change as gamepads are connected or disconnected...
-Boris
___
es-discuss
On 10/28/13 8:08 PM, Jonas Sicking wrote:
Return a frozen (and thus immutable) Array.
When you need to change the contents of the array, create a new frozen
Array which contains the new Array contents.
Ah, hmm. I could probably live with that.
-Boris
On 10/28/13 8:50 PM, Allen Wirfs-Brock wrote:
So what's so onerous about returning a fresh array from the getter each time it
was called. If it was implemented in Es6, it would just be:
return Array.from(internal_compy);
Implementing this is pretty easy, for sure.
The questions are:
On 28 October 2013 21:20, Boris Zbarsky bzbar...@mit.edu wrote:
As far as I can tell, the two places in ES5 that test [[Class]] being equal
to Array are Array.isArray() and Array.prototype.concat.
In ES6, the former does some sort of brand check, but the latter calls
IsConcatSpreadable, which
* Allen Wirfs-Brock wrote:
On Oct 28, 2013, at 5:52 PM, Domenic Denicola wrote:
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
So what's so onerous about returning a fresh array from the getter each
time it was called.
The fact that `api.property !== api.property`.
You mean
It looks like ES6 draft rev 20 has dropped:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
I don't have time to update the HTML right now, so it'll be a few
days. You'll be the first to know when it's fixed.
-j
___
es-discuss
Following up on the discussion about operator overloading, what are viable
options for introducing novel infix operators or a class of
extended/prefixed operators?
For motivation, I along with some others have implemented a MATLAB/R like
environment for JS. We've written a compile-to-js language
Tristan Zajonc wrote:
if (mutMatA == mutMatB) {
accidentallyMutate(mutMatA);
assumeStillEqual(mutMatA, mutMatB, data);
}
Is this bug related to operator overloading? It seems just the nature
of the beast with mutable reference types. Pretty much all JS matrix
Tristan Zajonc wrote:
It's true that in JS today, comparing an object to a non-object,
valueOf or toString on the object can be used to make == results vary.
However, I'm proposing value objects with declarative syntax to
solve several problems:
1. Backward compatibility,
On Tue, Oct 29, 2013 at 10:01 AM, Tristan Zajonc
tris...@senseplatform.com wrote:
Following up on the discussion about operator overloading, what are viable
options for introducing novel infix operators or a class of
extended/prefixed operators?
For motivation, I along with some others have
On Tue, Oct 29, 2013 at 10:04 AM, Brendan Eich bren...@mozilla.com wrote:
Tristan Zajonc wrote:
if (mutMatA == mutMatB) {
accidentallyMutate(mutMatA);
assumeStillEqual(mutMatA, mutMatB, data);
}
Is this bug related to operator overloading? It seems just the
On Tue, Oct 29, 2013 at 10:08 AM, Brendan Eich bren...@mozilla.com wrote:
Tristan Zajonc wrote:
It's true that in JS today, comparing an object to a non-object,
valueOf or toString on the object can be used to make == results vary.
However, I'm proposing value objects with
On Tue, Oct 29, 2013 at 10:37 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Oct 29, 2013 at 10:01 AM, Tristan Zajonc
tris...@senseplatform.com wrote:
Following up on the discussion about operator overloading, what are
viable
options for introducing novel infix operators or a class
Tristan Zajonc wrote:
Sorry, at most I'm only proposing every *existing* operator prefixed
by ., not new operators. So things like
.+, ./, .*, .-., .%, .==, .!=, ., ., etc. These would be called dot
operators. This is all that's required by the
technical computing use case.
Why is the dot
One clarification on the value objects proposal... The JSConf slides say
that immutability is implemented as an implicit Object.freeze(this) on
return in the constructor. Is this meant as shorthand for a deep freeze?
On Tue, Oct 29, 2013 at 11:13 AM, Tristan Zajonc
The PEP Tristan posted offers a pretty compelling case for distinguishing
elementwise operators from objectwise ones (although not for this dot
syntax per se, they went with a ~-prefix):
http://www.python.org/dev/peps/pep-0225/
On Tue, Oct 29, 2013 at 2:25 PM, Brendan Eich bren...@mozilla.com
Tristan Zajonc wrote:
One clarification on the value objects proposal... The JSConf slides
say that immutability is implemented as an implicit
Object.freeze(this) on return in the constructor. Is this meant as
shorthand for a deep freeze?
Yes, although depth may be hard to generalize. A
Dean Landolt wrote:
The PEP Tristan posted offers a pretty compelling case for
distinguishing elementwise operators from objectwise ones (although
not for this dot syntax per se, they went with a ~-prefix):
http://www.python.org/dev/peps/pep-0225/
Got it, thanks. We could indeed do .+, .*,
Got it, thanks. We could indeed do .+, .*, etc. without ambiguity.
(Ignore E4X's wildcards: xml.* etc.!)
/be
No. ;-)
js 1.*2
2
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Right you are. That was the same issue with Python. Are there any blockers
to ~*?
On Tue, Oct 29, 2013 at 11:46 AM, André Bargull andre.barg...@udo.eduwrote:
Got it, thanks. We could indeed do .+, .*, etc. without ambiguity.
(Ignore E4X's wildcards: xml.* etc.!)
/be
No. ;-)
js 1.*2
André Bargull mailto:andre.barg...@udo.edu
October 29, 2013 11:46 AM
No. ;-)
What's wrong with me? Have I become a Rubyist, LOL?
Thanks, clearly under-caffeinated today.
/be
js 1.*2
2
- André
Brendan Eich mailto:bren...@mozilla.com
October 29, 2013 11:39 AM
Got it, thanks. We could
On 10/29/2013 7:51 PM, Tristan Zajonc wrote:
Right you are. That was the same issue with Python. Are there any
blockers to ~*?
There are the usual ASI problems. For example this is currently valid:
```
a
~+ b
```
It is parsed as:
```
a;
~+ b;
```
On Tue, Oct 29, 2013 at 11:46 AM, André
André Bargull wrote:
There are the usual ASI problems. For example this is currently valid:
```
a
~+ b
```
It is parsed as:
```
a;
~+ b;
```
The fix we entertained for 'is' and 'isnt' was restricted productions:
AdditiveExpression [no LineTerminator here] '~+' MultiplicativeExpression
What about +:? This actually has some visual appeal if primary motivation
is elementwise operations and is a syntax error with that ASI example. The
downside is that it can end up pretty close to existing syntax like {a+:1}
vs. {a:+1}, although I don't expect that to be a common use.
On Tue,
Tristan Zajonc wrote:
What about +:? This actually has some visual appeal if primary
motivation is elementwise operations and is a syntax error with that
ASI example. The downside is that it can end up pretty close to
existing syntax like {a+:1} vs. {a:+1}, although I don't expect that
to
I would love to have a way to write function calls infix. That may cover your
use case as well. That is (strawman syntax):
arg1 #func arg2
would be syntactic sugar for
func(arg1, arg2)
Advantages: more versatile, less grawlixy. Problem: would make much more sense
with multiple
Axel Rauschmayer wrote:
I would love to have a way to write function calls infix. That may
cover your use case as well. That is (strawman syntax):
arg1 #func arg2
would be syntactic sugar for
func(arg1, arg2)
Advantages: more versatile, less grawlixy.
# is pure grawlix. It's also
Note that these proposed changes are now reflected in the Object.observe
spec text:
http://wiki.ecmascript.org/doku.php?id=harmony:observe
On Thu, Oct 17, 2013 at 3:09 PM, Rafael Weinstein rafa...@google.comwrote:
At the September meeting, the committee discussed Object.observe. Below is
a
Brendan Eich wrote:
Tristan Zajonc wrote:
What about +:? This actually has some visual appeal if primary
motivation is elementwise operations and is a syntax error with that
ASI example. The downside is that it can end up pretty close to
existing syntax like {a+:1} vs. {a:+1}, although I
On Tue, Oct 29, 2013 at 3:03 PM, Brendan Eich bren...@mozilla.com wrote:
Axel Rauschmayer wrote:
I would love to have a way to write function calls infix. That may cover
your use case as well. That is (strawman syntax):
arg1 #func arg2
would be syntactic sugar for
func(arg1,
On Tue, Oct 29, 2013 at 4:51 PM, Tristan Zajonc
tris...@senseplatform.com wrote:
Both operators and element-wise operators really benefit from Brendan's
multiple dispatch proposal. Julia has used this approach to great effect.
I'm not opposed to it, but I don't believe there's a compelling
At: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
The HtML version isn't ready yet, but should be available soon.
Changes include:
Introduced grammar parameters and eliminated NoIn productions
Spread now requires an Iterable rather than an array-like
B.1.4, Web browser
33 matches
Mail list logo
