On Tue, Jun 1, 2010 at 6:29 PM, Sam Ruby ru...@intertwingly.net wrote:
On 06/01/2010 09:15 PM, Waldemar Horwat wrote:
I assume that the proposal is that:
const TA =
Array.newTypedArray(fixed_length,
Object.newStructType({x:u32, y:u32, z:u32,
r:u8, g:u8, b:u8, a:u8}));
let a = new TA(...);
Hello,
Recently I was writing an article about strict mode in ES5
(http://bit.ly/928Jwl).
At the moment, the only implementation for testing is already mentioned
here -- BESEN engine. BESEN still has some bugs (some of them I’ve
reported while was writing the article and glad to see that
On 06/02/2010 03:52 AM, Jason Orendorff wrote:
I'll still maintain that the choice that ECMA 334 takes, namely
that the assignment to b in the example above, makes a mutable
copy is a valid choice.
I would expect
a[0].x = 3;
to modify a[0], not a temporary copy of a[0]. How do you propose
On Wed, Jun 2, 2010 at 7:02 AM, Sam Ruby ru...@intertwingly.net wrote:
On 06/02/2010 03:52 AM, Jason Orendorff wrote:
I'll still maintain that the choice that ECMA 334 takes, namely
that the assignment to b in the example above, makes a mutable
copy is a valid choice.
I would expect
On Jun 2, 2010, at 4:02 AM, Sam Ruby wrote:
On 06/02/2010 03:52 AM, Jason Orendorff wrote:
I'll still maintain that the choice that ECMA 334 takes, namely
that the assignment to b in the example above, makes a mutable
copy is a valid choice.
I would expect
a[0].x = 3;
to modify a[0], not
Sorry for the slow reply -- was sick
No worries-- hope you're feeling better.
Years of PL research and experience have demonstrated that explicit linking
tends to be unwieldy and inconvenient.
That needs to be added to my reading list. Cite away! :)
ML is dead; what more evidence do
On Jun 2, 2010, at 7:50 AM, Brendan Eich wrote:
There's no issue if we separate value types from structs-for-WebGL,
but perhaps that is still premature. What I'd like to get back to is
value types are shallowly frozen, though. Otherwise we are
introducing a new optimization *and*
On Jun 1, 2010, at 6:15 PM, Waldemar Horwat wrote:
b = a[i];
a[i].x += 1;
Now b.x also reflects the new value of a[i].x; i.e. b is an alias,
not a mutable copy. The same thing would happen if one had mutated
b.x.
That leads to a couple plausible meanings of b === a[i]:
1. Pointer
From: Dmitry A. Soshnikov
But he referenced to the conformance test suite --
http://es5conform.codeplex.com/ and in particular for these test cases
-- http://vserver.rosseaux.net/stuff/tests/
where is said that arguments and eval are allowed in such cases:
On 06/02/2010 02:03 PM, Brendan Eich wrote:
On Jun 2, 2010, at 7:50 AM, Brendan Eich wrote:
There's no issue if we separate value types from structs-for-WebGL,
but perhaps that is still premature. What I'd like to get back to is
value types are shallowly frozen, though. Otherwise we are
On 02.06.2010 22:22, Allen Wirfs-Brock wrote:
From: Dmitry A. Soshnikov
But he referenced to the conformance test suite --
http://es5conform.codeplex.com/ and in particular for these test cases
-- http://vserver.rosseaux.net/stuff/tests/
where is said that arguments and eval are allowed in
Hi Dave,
We are having two discussions here:
* Discussion of the relative merits of explicit linking in its various
forms; and
* Discussion of the specifics of the current proposal for implicit linking,
and alternatives *holding fixed* the initial condition that implicit linking
is a
I don't have the time or inclination to provide a full bibliography.
I consider your argument withdrawn, then.
Excuse me? My argument is not withdrawn (are we in court?). If you are
unaware of decades of prior art on modules, that's not my failing but yours.
My argument was and remains that
On Wed, Jun 2, 2010 at 12:14 PM, David Herman dher...@mozilla.com wrote:
but if you have a module graph of N modules, and each needs to be
explicitly linked with N - 1 other modules, then you impose a
quadratic code-size requirement on programmers. Unless, as I said,
you beef up your
On Jun 1, 2010, at 5:23 PM, ihab.a...@gmail.com wrote:
This is extremely common -- see Python and many other languages.
Yes, and Python and these other languages pull modules out of a
centrally curated PATH of some sort wherein 'foo/bar/baz' has an
unambiguous meaning to all other modules
Hi Dave
By explicit linking are we talking about mechanism's to unambiguously reference
modules that may otherwise be ambiguous? For example in java if 'Node' could
refer to a Node class in several different packages, the language allows one to
fully qualify the Node class eg foo.Node. Just
(since this is really off topic, I've retitled this thread).
Here is my understand of the evolution of Smalltalk blocks. I wasn't around
for the first two generations, but I was for the rest. Dan can correct any
early history I got wrong.
1) My understanding is that Smalltalk-72 did in fact
On Wed, Jun 2, 2010 at 12:14 PM, David Herman dher...@mozilla.com wrote:
See e.g. Derek Dreyer's work, starting with his thesis and
continuing to this day.
Aha. Finally, something vaguely resembling a citation. I will look at
this. Thank you.
Ihab
--
Ihab A.B. Awad, Palo Alto, CA
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 =
On Jun 2, 2010, at 11:14 AM, Brendan Eich wrote:
On Jun 1, 2010, at 6:15 PM, Waldemar Horwat wrote:
b = a[i];
a[i].x += 1;
Now b.x also reflects the new value of a[i].x; i.e. b is an alias, not a
mutable copy. The same thing would happen if one had mutated b.x.
That leads to a
On Jun 2, 2010, at 4:43 PM, Oliver Hunt wrote:
I cannot think of a case where b should not be an alias to a[i] if b is not
an alias to a[i] then the code
Should be:
I cannot think of a case where b should not be an alias to a[i]. If b is not
an alias to a[i] then the code:
...
Hooray for
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
On Jun 2, 2010, at 3:50 PM, Waldemar Horwat wrote:
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
On Jun 2, 2010, at 10:26 PM, Brendan Eich wrote:
For an expression a[i]j.x,
Sorry, obvious typo adding a 'j' there (keyboard malfunction, and hard
to see in the font I'm looking at!). No confusion in the rest:
the ES specs all evaluate a[i], call GetValue on it if a Reference,
then make
25 matches
Mail list logo
