Nabble - Mozilla - ECMAScript 4 discussion

Re: ES5 left-to-right evaluation order issues

2009-11-20T20:41:08Z

Allen Wirfs-Brock wrote:
> This is good...Perhaps we should have a "design rules" section of the Wiki
to capture stuff like this?

I don't have edit rights to the wiki (the former ES4 wiki, that is, not
the Trac wiki), and AFAIK neither does anyone else who is not a member
of TC39.

> -----Original Message-----
> From: es5-discuss-bounces@... [mailto:es5-discuss-bounces@...] On Behalf Of David-Sarah Hopwood
> Sent: Friday, November 20, 2009 7:18 PM
> To: es5-discuss@...
> Subject: Re: ES5 left-to-right evaluation order issues
>
> Allen Wirfs-Brock wrote:
>> So, the main point is that a belief that ECMAScript has or is supposed
>> to have a strict left-to-right evaluation order (as the concept is
>> likely to be understood by typical users of the language) is wrong.
>
> I'm going to have to insist that the understanding attributed to "typical users" here is an improper understanding of evaluation and coercion in general, and that ECMAScript *does* have left-to-right evaluation order.
>
> In most languages, the issue we're discussing here doesn't arise because if there are implicit coercions, these coercions don't have side effects, and therefore they don't have an observable ordering.
>
> However, in an imperative call-by-value language with left-to-right evaluation where *individual operators* perform coercions with observable side effects, the ECMAScript behaviour is precisely what should be expected.
> That's because the coercions are not part of the definition of evaluation; they are specific to the computations performed by each operator.
>
> For example, the ECMAScript * operator behaves as though it were defined something like the following function:
>
> function "*"(a, b) {
> return primitive_multiply(ToNumber(a), ToNumber(b));
> }
>
> Exactly as for a function application, the argument subexpressions are evaluated, and then some computation is applied to the argument values.
> The coercions are performed, in order, as part of that computation.
> In fact, the coercions are different for each operator, so it is almost essential that they be defined as part of the computation.
>
> If the change to coercion order that Allen originally suggested were made, then it would be necessary to understand the evaluation of operator argument subexpressions as being influenced by the operator and by the argument position (for example, the shift operators coerce their left subexpression with ToInt32 and their right subexpression with ToUint32), as opposed to being uniform for all subexpressions. This is in some ways even weirder that what ECMAScript currently does.
>
> It would also mean that if any future version of ECMAScript included operator overloading, then either it would not be possible to precisely emulate the semantics of the built-in versions of operators, or else the coercions would have to be "baked in" and not overloadable (i.e. the overloading function would have to receive its arguments pre-coerced, rather than being responsible for coercing them). Either of these options are undesirable -- the former would be inconsistent, and the latter less flexible and less efficient, since it wouldn't be possible to drop the coercions.
>
>> For consistency,
>> Dave-Sarah's observation that we first "evaluate" and then "coerce"
>> the operands is probably the guideline we should continue to follow if
>> we ever define any additional operators where the distinction is relevant.
>
> Yes, also for the reasons above.
>
> --
> David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com

--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (300 bytes) Download Attachment

RE: ES5 left-to-right evaluation order issues

2009-11-20T17:47:16Z

Since I talked about valueOf in my original message I'm going to interpret Oliver's comment as saying that even in ES3, without getter/setter extensions, you can still observed the separation of "evaluation" from "coercion". That's correct. In general, the way the ES3 (and 5) spec is written for binary operators of the form expr1 op expr2 any coercion of the value of expr1 types place after the evaluation of expr2. Since expr2 can potentially be an arbitrary expression that includes function calls, side-effects can be generated whi8le evaluating expr2 that are observed to occur before any side-effects from coercion (side-effects of valueOf, etc.) of expr1.

"Fixing" this would require substantial changes to the specification and to existing implementations that I doubt anyone wants to make.

So, the main point is that a belief that ECMAScript has or is supposed to have a strict left-to-right evaluation order (as the concept is likely to be understood by typical users of the language) is wrong. For consistency, Dave-Sarah's observation that we first "evaluate" and then "coerce" the operands is probably the guideline we should continue to follow if we ever define any additional operators where the distinction is relevant.

allen

-----Original Message-----
From: es5-discuss-bounces@... [mailto:es5-discuss-bounces@...] On Behalf Of Oliver Hunt
Sent: Friday, November 20, 2009 5:07 PM
To: David-Sarah Hopwood
Cc: es5-discuss@...
Subject: Re: ES5 left-to-right evaluation order issues

It was also observable through valueOf, toString, etc

--Oliver

On Nov 20, 2009, at 4:40 PM, David-Sarah Hopwood wrote:

> Allen Wirfs-Brock wrote:
>> var o={get a() {alert("get a");return a}, get b() {alert ("get b");return b}};
>> o.a*o.b;
>>
>> GetValue calls the accessor get functions, so based upon the above algorithm,
>> you would expect to see the alert sequence: "get a", "get b", "a valueOf",
>> "b valueOf". This is exactly what happens for existing getter/setter
>> implementations in at least FF and Chrome.
>
> I don't see a significant problem here. The arguments are still *evaluated*
> in left-to-right order. They're just not *coerced* at the same time as they
> are evaluated. But that was always the case in ES3; it hasn't changed in
> ES5. It's just a little bit more easily observable in ES5 because of
> getters.
>
> --
> David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
>
> _______________________________________________
> es5-discuss mailing list
> es5-discuss@...
> https://mail.mozilla.org/listinfo/es5-discuss

_______________________________________________
es5-discuss mailing list
es5-discuss@...
https://mail.mozilla.org/listinfo/es5-discuss
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

RE: Clauses or Sections?

2009-11-20T13:06:52Z

“clause” is ISO (and hence ECMA) required terminology for what most of us would prefer to call a “section” or “chapter”. There is also the term “subclause” but it usually can be avoided. Hopefully, all the referencing terminology is consistent with the ISO rules (if not, no doubt we will hear about it during the fast track process). Generally you have to explicitly say “clause” in front of a “whole number reference (eg, “clause 7” or “see clause 7”) but you can leave out “subclass from such references, eg “(7.2)” or “see 7.2”. If anybody would like to read the whole 68 pages of such rules the document you want to see is ISO/IEC-016 “Rules for the structure and drafting of International Standards” :-)

Allen

From: es-discuss-bounces@... [mailto:es-discuss-bounces@...] On Behalf Of Thomas L. Shinnick
Sent: Monday, November 16, 2009 12:47 PM
To: Brendan Eich
Cc: es-discuss
Subject: Re: Clauses or Sections?

At 01:35 PM 11/16/2009, Brendan Eich wrote:

On Nov 16, 2009, at 11:25 AM, Garrett Smith wrote:

The ES5 Specification mentions "clauses" in many places (e.g. "Clause
10."). This seems unclear. Is a "clause" the same thing as a
"section"? Why the double terminology?

I don't know -- I should have noticed these, since ES3 lacks such
solecisms. "Clause" occurs in ES3 only as part of CatchClause(s).

It's odd to use clause, which has a specific meaning in natural
language grammars, and a different but irrelevant meaning for legal
documents, to mean something as big as an ES5 section.

Allen no doubt knows the history. I hope this isn't an Ecma thing.

I'm sure it is, and the style is consistent with 'clause' === 'chapter-level', e.g.
    "The syntactic grammar for ECMAScript is given in clauses 11, 12, 13 and 14."

This bit of strangeness was mentioned by me back in January, saying
    Sometimes there will be a bare "clause 7" or "See clause 14", but elsewhere it will be stated "See 7.2" or "See clause 14.1"
    Is it just custom not to say 'chapter' or 'section'? Or is it a carry-over from some style guide?
                    :              <examples>                 :
    In fact, it seems the uses of 'section' outnumber those of 'clause'...
    It does conflict a bit with needed terminology "case clause"
and by others since.

Gotta be a style thing, as in 'irritating' but thus not actionable?

--
I'm a pessimist about probabilities; I'm an optimist about possibilities.
Lewis Mumford (1895-1990)

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

ES5 left-to-right evaluation order issues

2009-11-20T12:05:29Z

We generally claim that ECMAScript uses a left-to-right evaluation order and in ES5 we even fixed what was consider a bug in the ES3 spec (second item ES5 Annex D) regarding evaluation order of relational operators. Consider:

var a={valueOf: function () {alert(" a valueOf");return 1}};

var b={valueOf: function () {alert(" b valueOf");return 2}};

a<=b;

A strict implementation of the ES3 spec. would alert: “b valueOf” followed by “a valueOf” indicating what appears to be a right-to-left evaluation order. Chrome actually does this while at least IE and FF alert “a valueOf” followed by “b valueOf”. The ES5 changes say that “a valueOf” should occur first as this is consistent with the general left-to-right rule.

However, when accessor properties were added to the specification we did not consider the observable ordering interaction between accessor get functions with side-effects and ToPrimitive operations (ie valueOf) with side-effects. A typical binary operator algorithm from section 11 looks like:

1. Let left be the result of evaluating MultiplicativeExpression.

2. Let leftValue be GetValue(left).

3. Let right be the result of evaluating UnaryExpression.

4. Let rightValue be GetValue(right).

5. Let leftNum be ToNumber(leftValue).

6. Let rightNum be ToNumber(rightValue).

7. Return the result of applying the specified operation (*, /, or %) to leftNum and rightNum. See the Notes below 11.5.1, 11.5.2, 11.5.3.

Note that the two calls to GetValue precede the two calls to ToNumber. Generally in ES3 GetValue doesn’t have side-effects so left-to-right order is maintained (however the ordering is observable if the right argument throws a ReferenceError). The interweaved evaluation order is much easier to observe if accessor properties are implemented. Consider executing the following in the context of the declarations of a and b above:

var o={get a() {alert("get a");return a}, get b() {alert ("get b");return b}};

o.a*o.b;

GetValue calls the accessor get functions, so based upon the above algorithm, you would expect to see the alert sequence: “get a”, “get b”, “a valueOf”, “b valueOf”. This is exactly what happens for existing getter/setter implementations in at least FF and Chrome.

So, the ES5 specification of operators is consistent with existing implementations of accessor properties. However, this is not a strict left-to-right order of evaluation order. We don’t have many options at this point. Here are the alternatives I see:

1. Abandon the idea that ECMAScript does strict left-to-right evaluation (it never really did, anyway) and be content with the story that it generally evaluates left to right with assorted special case exceptions to this rule.

2. Consider all existing violation of strict left-to-right evaluation as specification bugs and make a big note of that in the errata. Maybe they can be fixed in the ISO version of the ES5 spec.

It would take substantial work to fix this throughout the specification and actual implementation of the strict left-to-right rule would introduce numerous potentially observable changes to existing implementations. Based upon this, I suspect that we have to choose alternative #1 although I would personally be open to considering alternative #2.

Thoughts?

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Conflicts between W3C specs and ES5?

2009-11-18T19:20:12Z

On Wed, Nov 18, 2009 at 4:16 PM, Brendan Eich <brendan@...> wrote:

> On Nov 18, 2009, at 3:25 PM, David-Sarah Hopwood wrote:
>
>> Brendan Eich wrote:
>>>
>>> On Nov 17, 2009, at 6:41 PM, Maciej Stachowiak wrote:
>>>
>>>>>> otherWindow.copyOfEvalFromYetAnotherWindow("...") throws
>>
>> [...]
>>>>>
>>>>> What is the rationale for throwing in this last case, rather than
>>>>> using the explicit base object (otherWindow) as |this|?
>>
>> [...]
>>>
>>> The standard ECMA-262 semantics want otherWindow -- "bound method"
>>> exceptions prove the rule.
>>
>> There are bound methods in ES implementations? I'm all ears.
>

IE's famous appendChild "performance trick":

var bodyAppendChild = document.body.appendChild;
bodyAppendChild(document.createTextNode("hello"));

http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx

The results in an error in other browsers; not IE (to be expected).

DOes that fit the definition of "bound method"?
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Conflicts between W3C specs and ES5?

2009-11-18T16:39:29Z

On Nov 18, 2009, at 3:25 PM, David-Sarah Hopwood wrote:

> Brendan Eich wrote:
>> On Nov 17, 2009, at 6:41 PM, Maciej Stachowiak wrote:
>>
>>>>> otherWindow.copyOfEvalFromYetAnotherWindow("...") throws
> [...]
>>>>
>>>> What is the rationale for throwing in this last case, rather than
>>>> using the explicit base object (otherWindow) as |this|?
> [...]
>> The standard ECMA-262 semantics want otherWindow -- "bound method"
>> exceptions prove the rule.
>
> There are bound methods in ES implementations? I'm all ears.
>
>
> (One thing I've never understood is why ES implementors add features
> or exceptional behaviour that users of the language could only find,
> or even know to look for, by reverse engineering or guesswork. What's
> the point? Doesn't it take more work to add all this stuff?)

In the case of the original topic (eval), in JavaScriptCore it is only
"bound" enough to reject being called with the wrong "this" object; it
does not do anything else with its stored original global object. We
did this solely to match the ES4 "reformed eval" proposal at the time,
as I mentioned on the public-script-coord list.

Regards,
Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Conflicts between W3C specs and ES5?

2009-11-18T16:16:28Z

On Nov 18, 2009, at 3:25 PM, David-Sarah Hopwood wrote:

There certainly are. First, I was not referring to any built-in magic.
Function.prototype.bind and similar such APIs were developed first by
Ajax libraries and used to force |this| to a preset value, instead of
using a base object in the callee reference pair (base object,
property name).

But, of course, host objects in various implementations sport bound
methods. The original ones I know of came from the Java/JS bridge,
"LiveConnect", because Java method reflections in JS seemed not
usefully extractable as first-class functions. Instead, extraction
binds method to receiver, so application coerces |this|.

(E4X (ECMA-357) has methods that can't be extracted at all, they are
invoke-only; this is even worse than auto-bound methods!)

> (One thing I've never understood is why ES implementors add features
> or exceptional behaviour that users of the language could only find,
> or even know to look for, by reverse engineering or guesswork. What's
> the point? Doesn't it take more work to add all this stuff?)

No, it takes less work to hack "privileged" C++ than to figure out how
to host the magic in-language. The proof is in the proliferation of
bad host object magic.

If JS had time to be bootstrapped a la Smalltalk, with small native-
method "area" and API surface, then it would be a better world. But
like Java, JS was and is native-code-heavy in its popular
implementations, and this means host magic.

/be
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Conflicts between W3C specs and ES5?

2009-11-18T15:25:20Z

Brendan Eich wrote:
> On Nov 17, 2009, at 6:41 PM, Maciej Stachowiak wrote:
>
>>>> otherWindow.copyOfEvalFromYetAnotherWindow("...") throws
[...]
>>>
>>> What is the rationale for throwing in this last case, rather than
>>> using the explicit base object (otherWindow) as |this|?
[...]
> The standard ECMA-262 semantics want otherWindow -- "bound method"
> exceptions prove the rule.

There are bound methods in ES implementations? I'm all ears.

(One thing I've never understood is why ES implementors add features
or exceptional behaviour that users of the language could only find,
or even know to look for, by reverse engineering or guesswork. What's
the point? Doesn't it take more work to add all this stuff?)

--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (300 bytes) Download Attachment

Re: AST in JSON format

2009-11-16T16:58:51Z

The previous example was pretty printed. A production version would
offer a minified alternative without newlines and indentation. e.g:

["Program",["ExprStmt",["Assign",{"op":"="},["Id",{"name":"x"}], ...

Perhaps there could be in addition an alternative compact format where
the element strings are replaced with integers:

[44,[20,[21,{"op":"="},[25,{"name":"x"}], ...

And the attribute name string with an integer or maybe the first letter:

[44,[20,[21,{1:"="},[25,{3:"x"}], ...
[44,[20,[21,{"o":"="},[25,{n:"x"}], ...

It's compact and as the integers match the underlying enum no hash
lookup for the element/attribute string names is required. Kind of a
half way house between the AST and bytecode. e.g:

var ast = JSON.AST.parse(source, true); // true for compact mode
var result = JSON.AST.evaluate(ast); // No special mode required

The evaluate() function would simply test if the element value was a
string or integer and hash lookup or atoi.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: AST in JSON format

2009-11-16T16:49:43Z

I have tweaked the JsonML AST format (shorter element names and
operator tokens not names eg ">=" instead of "GTE") and added an
evaluate() function which can execute the JsonML string. Example:

> more example.js
var source = "x = 2; if (x > 1) print(x + 3);";

print("--- js source ---");
print(source);
print("");

print("--- ast ---");
var ast = JSON.AST.parse(source);
print(ast);
print("");

print("--- evaluate(ast) ---");
JSON.AST.evaluate(ast);

> ./shell_g example.js
--- js source ---
x = 2; if (x > 1) print(x + 3);

--- ast ---
["Program",
["ExprStmt",
["Assign",
{"op":"="},
["Id",
{"name":"x"}
],
["Literal",
{"handle":2}
]
]
],
["If",
["CompareOp",
{"op":">"},
["Id",
{"name":"x"}
],
["Literal",
{"handle":1}
]
],
["ExprStmt",
["Call",
["Id",
{"name":"print"}
],
["BinOp",
{"op":"+"},
["Id",
{"name":"x"}
],
["Literal",
{"handle":3}
]
]
]
],
["EmptyStmt"]
]
]

--- evaluate(ast) ---
5
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Clauses or Sections?

2009-11-16T13:05:13Z

It is a style thing related to common ECMA and ISO style guides. "Clause 14" is a correct reference to major heading "14", and references to "sub-clauses" such as "14.1" are referenced directly without mention of "clause", "section", "paragraph" "etc".

Section, such as "Section 1" is a division of the document higher than Clause. For example "Section 1" may have one or more "clauses" such as "clause 14" of "Section 2". The rules are spelled out in the ISO Style Guide and the Ecma Style Guide. If in doubt, contact Patrick at patrick@... who will be able to give you specific guidance.

In a message dated 11/16/2009 3:47:37 P.M. Eastern Standard Time, tshinnic@... writes:

At 01:35 PM 11/16/2009, Brendan Eich wrote:

On Nov 16, 2009, at 11:25 AM, Garrett Smith wrote:

The ES5 Specification mentions "clauses" in many places (e.g. "Clause
10."). This seems unclear. Is a "clause" the same thing as a
"section"? Why the double terminology?

I don't know -- I should have noticed these, since ES3 lacks such
solecisms. "Clause" occurs in ES3 only as part of CatchClause(s).

It's odd to use clause, which has a specific meaning in natural
language grammars, and a different but irrelevant meaning for legal
documents, to mean something as big as an ES5 section.

Allen no doubt knows the history. I hope this isn't an Ecma thing.

I'm sure it is, and the style is consistent with 'clause' === 'chapter-level', e.g.
    "The syntactic grammar for ECMAScript is given in clauses 11, 12, 13 and 14."

This bit of strangeness was mentioned by me back in January, saying
    Sometimes there will be a bare "clause 7" or "See clause 14", but elsewhere it will be stated "See 7.2" or "See clause 14.1"
    Is it just custom not to say 'chapter' or 'section'? Or is it a carry-over from some style guide?
                    :              <examples>                 :
    In fact, it seems the uses of 'section' outnumber those of 'clause'...
    It does conflict a bit with needed terminology "case clause"
and by others since.

Gotta be a style thing, as in 'irritating' but thus not actionable?

--
I'm a pessimist about probabilities; I'm an optimist about possibilities.
    Lewis Mumford (1895-1990)

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Clauses or Sections?

2009-11-16T12:47:11Z

At 01:35 PM 11/16/2009, Brendan Eich wrote:

On Nov 16, 2009, at 11:25 AM, Garrett Smith wrote:

The ES5 Specification mentions "clauses" in many places (e.g. "Clause
10."). This seems unclear. Is a "clause" the same thing as a
"section"? Why the double terminology?

I don't know -- I should have noticed these, since ES3 lacks such
solecisms. "Clause" occurs in ES3 only as part of CatchClause(s).

It's odd to use clause, which has a specific meaning in natural
language grammars, and a different but irrelevant meaning for legal
documents, to mean something as big as an ES5 section.

Allen no doubt knows the history. I hope this isn't an Ecma thing.

--
I'm a pessimist about probabilities; I'm an optimist about possibilities.
Lewis Mumford (1895-1990)

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Clauses or Sections?

2009-11-16T11:35:04Z

On Nov 16, 2009, at 11:25 AM, Garrett Smith wrote:

> The ES5 Specification mentions "clauses" in many places (e.g. "Clause
> 10."). This seems unclear. Is a "clause" the same thing as a
> "section"? Why the double terminology?

I don't know -- I should have noticed these, since ES3 lacks such
solecisms. "Clause" occurs in ES3 only as part of CatchClause(s).

It's odd to use clause, which has a specific meaning in natural
language grammars, and a different but irrelevant meaning for legal
documents, to mean something as big as an ES5 section.

Allen no doubt knows the history. I hope this isn't an Ecma thing.

Non-random link:

http://en.wikipedia.org/wiki/There_Ain%27t_No_Sanity_Clause

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Clauses or Sections?

2009-11-16T11:25:25Z

The ES5 Specification mentions "clauses" in many places (e.g. "Clause
10."). This seems unclear. Is a "clause" the same thing as a
"section"? Why the double terminology?
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Typo in Annex E

2009-11-14T13:50:44Z

The last paragraph of Annex E notes that "getPropertyName" is among
the divergences from ES3. I presume this is intended to be
"getPropertyNames" with plural infection.

Kris Kowal
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-14T13:34:34Z

[+ commonjs]

On Sat, Nov 7, 2009 at 6:21 PM, Maciej Stachowiak <mjs@...> wrote:
> If nothing else there's quite a bit of prior art collected which should
> inform the conversation. I know the Binary/B proposal has the implementation
> momentum, but I don't know exactly what the status is. I haven't been
> closely following the evolution of these binary specs too closely but since
> it seems that nearly everyone else from the group is off to jsconf.eu I
> figured I ought to toss this out there.

Thanks, we're back, and convergence on binary data API's are our next
big thrust. I spoke with Brian Mitchell at jsconf.eu who has a
significant interest in our binary proposals. Particularly there was
a lot of interest in bit quantized data types, which in my opinion
would complement but not replace byte quantized data types. At this
point, I imagine that we will eventually have ByteString, ByteArray,
ByteStream, BitString, BitArray, and BitStream types, between our
"binary" and "io" module specifications.

> Binary/B feels largely right, but it has a few too many methods from Array
> simply because Array had them for my taste, specifically things like sort,
> reduce, shift, unshift etc.

In retrospect, I agree. I think our ByteArray could survive with a
very small subset of the Array API. Would anyone miss any of: push,
pop, shift, unshift, sort, reverse, splice, indexOf, lastIndexOf,
split, filter, forEach, every, some, map, reduce, reduceRight,
displace, extendLeft, extendRight. I imagine that the primary use
cases for ByteArray would be fixed-width, but explicitly growable with
length assignment, pipes and buffers, for which the most common
operations would copy(target, start, stop, targetStart) and conversion
to other types.

> (1) Binary/B does not have a cheap way to convert from the immutable
> representation (ByteString) to the mutable representation (ByteArray)

Apart from .toByteArray()? I imagine that implementations would be
able to track whether underlying buffer blocks are shared by multiple
ByteString or ByteArray data instances and support copy-on-write for
ByteArrays. I'm probably missing something. Perhaps you envision
something lower-level?

> (2) In Binary/B, Array-like index access to ByteString gives back one-byte
> ByteStrings instead of bytes, likely an over-literal copying of String

This has been mentioned, but there are certain values to over-literal
copying; the notion is that certain algorithms written for Strings,
albeit algorithms written for byte strings but suffering to do so with
Strings, should continue to function with ByteString. To that end, it
may be desirable for certain idioms to continue to function properly:

string[0].concat(string[1])

> (3) There are some seemingly needless differences in the interfaces to
> ByteString and ByteArray that follow from modeling on String and Array

I am not sure.

> (4) Binary/B has many more operations available in the base proposal
> (including charset transcoding and a generous selection of String and Array
> methods)

I think it will be desirable to trim down the ByteArray proposal.

I don't recall where, but there's also some hint that it would be good
to support conversion to various radix string representations,
certainly 16 and 64, but possibly also 2, 8, and 32 (either to the RFC
or Doug Crockford's proposal for human-error-resistant license keys).
I think that these ought to be folded into .toString(radix:Number) in
a future draft.

> (5) Different names - Data/DataBuilder vs. ByteString/ByteArray

I like ByteString. ByteArray is tending toward not being as strictly
Array-like, but I think it's also apt, from the perspective of users
implicitly understanding what kinds of operations are permitted on
ByteArrays based on their understanding of Arrays, like mutability and
resizability. I definitely don't like Data and DataBuilder for the
reasons Brendan outlined, but I definitely could see cases for Buffer
and Blob.

> On (1): cheap conversion from mutable to immutable
> (DataBuilder.prototype.release() in my proposal) lets binary data objects be
> built up with a convenient mutation-based idiom, but then passed around as
> immutable objects thereafter.

Ah, sure. That makes sense. My instinct is that under the hood, the
original byte array would not actually disappear but switch to
copy-on-write and transfer ownership of its underlying buffer to the
new ByteString. However, could this behavior not be folded up
transparently by toByteString()?

> On (2): I don't think a one-byte ByteString is
> ever useful, indexing to get the byte value would be much more helpful.

I agree this is debatable. I'm not ready to embark on a case study of
existing uses of Strings for binary data in JavaScript to explore what
methods are used, but there certainly is a corpus. The works of Jacob
Seidelin and Ama Chang come to mind; I've seen and massaged code for
most radix encodings, charset encodings, hashing algorithms, EXIM,
ID3, binary AJAX, ZIP archives, and the itinerant compression
algorithms like LZ77. They all use a combination of Array and String
operations, all operating on the octet invariant. It might be worth
looking into how easily these projects can be ported to these API's.

> On (3), I think it's good for the mutable interface to be
> a strict superset of
> the the immutable interface.

Also, not sure. I'm certain that there should be a body of common
methods so they can be used generically, but I'm not sure that it
should be exhaustive one way or the other. Perhaps in the course of
pruning ByteArray we'll converge on something a step away from
ByteString.

> My initial impression is that (1), (2) and (3) are all points on which my
> proposal is better.
> (4) and (5) are all points where perhaps neither proposal is at the optimum
> yet.

I think we can address (1) under the hood. I'm not sure about (2) and
(3); I've hitherto assumed that String/Array genericity would be
valuable. (4) is also contentious; Binary/B does "entrain" a lot of
necessary specification for charsets and radix encodings, although it
rather deliberately avoids specifying API's for structure packing and
unpacking.

> On (4), I suspect the sweet spot is somewhere between my spartan set of
> built-in operations and the very generous set in Binary/B.

Agreed.

> On (5), I'm not
> sure either set of names is the best possible, and I'm certainly not stuck
> on my own proposed names.

Yes. It might be best to revisit nomenclature after the API's settle.

Thanks,
Kris Kowal
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-14T13:33:27Z

On Sat, 07 Nov 2009 19:17:48 -0800, Maciej Stachowiak
wrote:

> Mutable to immutable. Immutable to mutable has to copy (or at least
> copy-on-write).
>
> My proposal does it like this (where DataBuilder is the mutable
> variant and Data is the immutable):
>
> DataBuilder.prototype.release()
>
> Return a new Data with the same length and the same byte values
> as the DataBuilder passed as the this value. At the same time, the
> DataBuilder is reset to length 0.
>
> Because the DataBuilder is reset to empty, the implementation can
> "steal" its underlying buffer for the new Data object, thus converting
> to immutable without a full copy. This matches the common pattern of
> assembling a new piece of binary data with mutation, then handing it
> out to possibly multiple other pieces of code as immutable.
>

Seems like a good idea, but is this a case of baking too much
implementation detail in the spec?

> Yes, Brendan made this point and presented some good evidence in that
> direction. I think 'Data' doesn't work but 'Binary' or 'BinData' might.

Yay naming bike-shedding. Perhaps postponing the naming until later on in
the process once the rest of the API is more concrete?

>> Something worth bearing in mind is that Binary/B is implemented in 2
>> or 3 CommonJS platforms already, but I don't think any one is
>> particularly attached to the behaviour so long as what comes out
>> isn't wildly different.
>
> What kind of differences do you think they would tolerate? Renaming
> the classes? Dropping/changing some methods?

I haven't checked with anyone, but so long as there is a clear migration
path I can't see anyone complaining too vocally.

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-14T12:34:38Z

On Fri, Nov 6, 2009 at 11:24 AM, Brendan Eich <brendan@...> wrote:
> Kris did a good job with Binary/B (although I do not see the point of the
> .get method additions) -- I didn't look at the other proposals yet.

Thanks. The .get method is certainly not relevant for an ECMAScript
spec, where you have the luxury of specifying [[Get]] and [[Put]].
The .get method in the CommonJS proposal is intended to serve as a
stop-gap for implementations that cannot provide properties.

Kris Kowal
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: getter & setter for private objects

2009-11-14T05:30:33Z

manager = function(object) {
this.init.apply(this, arguments);
}
manager.prototype = new function() {
/* Private Properties */
var gui;
var obj;

/* Constructor */
this.init = function(object) {
gui = new Gui();
obj = object;
}

/* Property with both accessor and mutator */
this.__defineGetter__("modus", function() {
[..]
});
this.__defineSetter__("modus", function(modus) {
[..]
});

/* Privileged public method which affords access to private properties */
this.getGui = function() {
return gui;
}
}

Currently I'm able to set accessor and mutator for properties of "this", but not
on the lexical scope chain. I want e.g. "modus" to be private.

Anyway I hope you get what I mean. It's an
evolutionary step to class support. Other programming languages
support

private int foo {
get { [..] }
set { [..] }
}
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Function.prototype, [[Call]] and [[Construct]]

2009-11-09T21:17:21Z

On Nov 10, 2009, at 12:10 AM, Garrett Smith wrote:

> On Mon, Nov 9, 2009 at 8:05 PM, Juriy Zaytsev <kangax.dev@...>
> wrote:
>> On Nov 9, 2009, at 6:50 PM, Garrett Smith wrote:
>>
>>> [[Construct]] of Function.prototype is not standardized.
>>>
>
> [...]
>
>>
>> If you look into Section 15 — Native ECMAScript Objects, you'll see
>> this
>> rather clear explanation:
>>
>> "[...] None of the built-in functions described in this section shall
>> implement the internal [[Construct]] method unless otherwise
>> specified in
>> the description of a particular function. None of the built-in
>> functions
>> described in this section shall initially have a prototype property
>> unless
>> otherwise specified in the description of a particular function.
>> [...]"

[...]

>
> So Function.prototype should not implement [[Construct]].

As far as I can see, no, it shouldn't.

WebKit (nightly) and Opera (10) conform here, throwing TypeError on
`new Function.prototype`, but Firefox (at least 3.5) erroneously
creates an object.

>
> Garrett

--
kangax
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Function.prototype, [[Call]] and [[Construct]]

2009-11-09T21:10:22Z

On Mon, Nov 9, 2009 at 8:05 PM, Juriy Zaytsev <kangax.dev@...> wrote:
> On Nov 9, 2009, at 6:50 PM, Garrett Smith wrote:
>
>> [[Construct]] of Function.prototype is not standardized.
>>

[...]

>
> If you look into Section 15 — Native ECMAScript Objects, you'll see this
> rather clear explanation:
>
> "[...] None of the built-in functions described in this section shall
> implement the internal [[Construct]] method unless otherwise specified in
> the description of a particular function. None of the built-in functions
> described in this section shall initially have a prototype property unless
> otherwise specified in the description of a particular function. [...]"
>

That's pretty clear. I had interpreted that as meaning the global
functions (eval, parseInt), but now I see that that text applies to
the whole section 15, not just the function properties (as I had
misread it).

> In fact, I mentioned this exact phrase when writing about bugs in various
> browsers, revealed through Sputniktests web runner
> (http://thinkweb2.com/projects/prototype/sputniktests-web-runner/#construct-and-prototype-of-builtins).
>
> And as I said in a post, Firefox and Chrome, for example, fail a whole bunch
> of tests due to most of built-in methods (like `Array.prototype.toString`,
> `parseInt` or `String.prototype.slice`) implementing [[Construct]] and
> having .prototype properties.
>

So Function.prototype should not implement [[Construct]].

Garrett
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Function.prototype, [[Call]] and [[Construct]]

2009-11-09T20:05:11Z

On Nov 9, 2009, at 6:50 PM, Garrett Smith wrote:

> [[Construct]] of Function.prototype is not standardized.
>
> The definition of Function.prototype does not define the expected
> behavior for [[Call]] or [[Construct]]. Instead, there is a
> description of what happens when it is invoked:
>
> | 15.3.4 Properties of the Function Prototype Object
> | The Function prototype object is itself a Function
> | object (its [[Class]] is "Function") that, when
> | invoked, accepts any arguments and returns undefined.
>
> Should Function.prototype implement [[Construct]]? Either way, the
> specification should state the outcome.

Yes, it's a slightly tricky one :) I was wading through Sputniktests
suite couple of days ago (when finishing web runner — http://thinkweb2.com/projects/prototype/sputniktests-web-runner/
) and noticed that there were assertions for exactly this kind of
compliance.

I even filed a bug with Sputniktests, thinking that they make
incorrect assumptions — http://code.google.com/p/sputniktests/issues/detail?id=11

However, then I realized that specs do in fact mention this
explicitly, although not directly under these specific sections.

If you look into Section 15 — Native ECMAScript Objects, you'll see
this rather clear explanation:

"[...] None of the built-in functions described in this section shall
implement the internal [[Construct]] method unless otherwise specified
in the description of a particular function. None of the built-in
functions described in this section shall initially have a prototype
property unless otherwise specified in the description of a particular
function. [...]"

In fact, I mentioned this exact phrase when writing about bugs in
various browsers, revealed through Sputniktests web runner (http://thinkweb2.com/projects/prototype/sputniktests-web-runner/#construct-and-prototype-of-builtins
).

And as I said in a post, Firefox and Chrome, for example, fail a whole
bunch of tests due to most of built-in methods (like
`Array.prototype.toString`, `parseInt` or `String.prototype.slice`)
implementing [[Construct]] and having .prototype properties.

[...]

--
kangax
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Function.prototype, [[Call]] and [[Construct]]

2009-11-09T15:50:24Z

[[Construct]] of Function.prototype is not standardized.

The definition of Function.prototype does not define the expected
behavior for [[Call]] or [[Construct]]. Instead, there is a
description of what happens when it is invoked:

| 15.3.4 Properties of the Function Prototype Object
| The Function prototype object is itself a Function
| object (its [[Class]] is "Function") that, when
| invoked, accepts any arguments and returns undefined.

Should Function.prototype implement [[Construct]]? Either way, the
specification should state the outcome.

Trying it out:

javascript: alert( new Function.prototype );

IE 6-8:
Error: Object doesn't support this action

Other browsers tested return an Object, indicating the [[Construct]]
is implemented.

The specification should state whether or not Function.prototype
implements [[Construct]], to clarify expected outcome, and to
encourage consistent implementations.

Garrett
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-08T18:54:29Z

Maciej Stachowiak wrote:

>
> On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:
>
>>
>> On 6 Nov 2009, at 19:24, Brendan Eich wrote:
>>
>>> On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:
>>>
>>>> Just in case some of you weren't aware, the CommonJS group has done
>>>> quite a bit of work and (bikeshedding) on this topic. Here's a link
>>>> to the wiki:
>>>>
>>>> http://wiki.commonjs.org/wiki/Binary
>>>>
>>>> ...
>
> Binary/B is the closest of the three proposals to mine, in that it has
> both mutable and immutable binary data containers. Here are a few key
> differences:
> ...
> Regards,
> Maciej

One note, Binary/C also originally had a mutable and an immutable type.
The mutable type was moved to IO/B/Buffer
(http://wiki.commonjs.org/wiki/IO/B/Buffer), when comparing to Binary/B,
Binary/C together with IO/B/Buffer is more equivalent a comparison.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-07T19:17:48Z

On Nov 7, 2009, at 6:53 PM, Ash Berlin wrote:

On 8 Nov 2009, at 02:21, Maciej Stachowiak wrote:

On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:

On 6 Nov 2009, at 19:24, Brendan Eich wrote:

On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:

http://wiki.commonjs.org/wiki/Binary

[snip]

[snip]
As a community (CommonJS) we'd be more than happy to go forward with a binary spec that came from (or at least has the blessing of) the ES groups

Binary/B is the closest of the three proposals to mine, in that it has both mutable and immutable binary data containers. Here are a few key differences:

(1) Binary/B does not have a cheap way to convert from the immutable representation (ByteString) to the mutable representation (ByteArray)
(2) In Binary/B, Array-like index access to ByteString gives back one-byte ByteStrings instead of bytes, likely an over-literal copying of String
(3) There are some seemingly needless differences in the interfaces to ByteString and ByteArray that follow from modeling on String and Array
(4) Binary/B has many more operations available in the base proposal (including charset transcoding and a generous selection of String and Array methods)
(5) Different names - Data/DataBuilder vs. ByteString/ByteArray

On (1): cheap conversion from mutable to immutable (DataBuilder.prototype.release() in my proposal) lets binary data objects be built up with a convenient mutation-based idiom, but then passed around as immutable objects thereafter.

Mutable to immutable or immutable to mutable? Assuming the former, how do you handle the differences in API/behaviour? each function checks wether it is now immutable?

Mutable to immutable. Immutable to mutable has to copy (or at least copy-on-write).

My proposal does it like this (where DataBuilder is the mutable variant and Data is the immutable):

DataBuilder.prototype.release()

Return a new Data with the same length and the same byte values as the DataBuilder passed as the this value. At the same time, the DataBuilder is reset to length 0.

Because the DataBuilder is reset to empty, the implementation can "steal" its underlying buffer for the new Data object, thus converting to immutable without a full copy. This matches the common pattern of assembling a new piece of binary data with mutation, then handing it out to possibly multiple other pieces of code as immutable.

On (2): I don't think a one-byte ByteString is ever useful, indexing to get the byte value would be much more helpful.

Couldn't agree more with you here - if for whatever reason you do want a one-byte ByteString, there is always substr/substring. This is something that came up recently in IRC and prompted me to start looking at making changes to the proposal - I was going to do that next week, so this coming up now is very good timing.

On (3), I think it's good for the mutable interface to be a strict superset of the the immutable interface.

Seems like a reasonable thing to do.

I'm glad we agree on these two points.

(4) and (5) are all points where perhaps neither proposal is at the optimum yet. On (4), I suspect the sweet spot is somewhere between my spartan set of built-in operations and the very generous set in Binary/B.

Agreed - this was the other thing i noticed - e.g. sorting a ByteArray isn't really an operation that makes a whole lot of sense to my mind.

Yep. I'm not even sure things like map(), filter() or reduce() are likely to work well. My own preference is to start the API very small, and add incrementally based on demonstrated need and clearly articulated use cases.

On (5), I'm not sure either set of names is the best possible, and I'm certainly not stuck on my own proposed names.

I'm not really bothered either way on this front, although 'Data' is much more likely to clash with existing code.

Yes, Brendan made this point and presented some good evidence in that direction. I think 'Data' doesn't work but 'Binary' or 'BinData' might.

Something worth bearing in mind is that Binary/B is implemented in 2 or 3 CommonJS platforms already, but I don't think any one is particularly attached to the behaviour so long as what comes out isn't wildly different.

What kind of differences do you think they would tolerate? Renaming the classes? Dropping/changing some methods?

Regards,

Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-07T18:53:59Z

On 8 Nov 2009, at 02:21, Maciej Stachowiak wrote:

On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:

On 6 Nov 2009, at 19:24, Brendan Eich wrote:

On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:

http://wiki.commonjs.org/wiki/Binary

[snip]

[snip]
As a community (CommonJS) we'd be more than happy to go forward with a binary spec that came from (or at least has the blessing of) the ES groups

Binary/B is the closest of the three proposals to mine, in that it has both mutable and immutable binary data containers. Here are a few key differences:

(1) Binary/B does not have a cheap way to convert from the immutable representation (ByteString) to the mutable representation (ByteArray)
(2) In Binary/B, Array-like index access to ByteString gives back one-byte ByteStrings instead of bytes, likely an over-literal copying of String
(3) There are some seemingly needless differences in the interfaces to ByteString and ByteArray that follow from modeling on String and Array
(4) Binary/B has many more operations available in the base proposal (including charset transcoding and a generous selection of String and Array methods)
(5) Different names - Data/DataBuilder vs. ByteString/ByteArray

On (1): cheap conversion from mutable to immutable (DataBuilder.prototype.release() in my proposal) lets binary data objects be built up with a convenient mutation-based idiom, but then passed around as immutable objects thereafter.

Mutable to immutable or immutable to mutable? Assuming the former, how do you handle the differences in API/behaviour? each function checks wether it is now immutable?

On (2): I don't think a one-byte ByteString is ever useful, indexing to get the byte value would be much more helpful.

Couldn't agree more with you here - if for whatever reason you do want a one-byte ByteString, there is always substr/substring. This is something that came up recently in IRC and prompted me to start looking at making changes to the proposal - I was going to do that next week, so this coming up now is very good timing.

On (3), I think it's good for the mutable interface to be a strict superset of the the immutable interface.

Seems like a reasonable thing to do.

(4) and (5) are all points where perhaps neither proposal is at the optimum yet. On (4), I suspect the sweet spot is somewhere between my spartan set of built-in operations and the very generous set in Binary/B.

Agreed - this was the other thing i noticed - e.g. sorting a ByteArray isn't really an operation that makes a whole lot of sense to my mind.

On (5), I'm not sure either set of names is the best possible, and I'm certainly not stuck on my own proposed names.

I'm not really bothered either way on this front, although 'Data' is much more likely to clash with existing code.

Regards,
Maciej

Something worth bearing in mind is that Binary/B is implemented in 2 or 3 CommonJS platforms already, but I don't think any one is particularly attached to the behaviour so long as what comes out isn't wildly different.

-ash

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-07T18:21:17Z

On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:

On 6 Nov 2009, at 19:24, Brendan Eich wrote:

On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:

Just in case some of you weren't aware, the CommonJS group has done quite a bit of work and (bikeshedding) on this topic. Here's a link to the wiki:

http://wiki.commonjs.org/wiki/Binary

If nothing else there's quite a bit of prior art collected which should inform the conversation. I know the Binary/B proposal has the implementation momentum, but I don't know exactly what the status is. I haven't been closely following the evolution of these binary specs too closely but since it seems that nearly everyone else from the group is off to jsconf.eu I figured I ought to toss this out there.

Thanks, I had forgotten about commonjs.org, having once paid better attention.

Kris did a good job with Binary/B (although I do not see the point of the .get method additions) -- I didn't look at the other proposals yet.

/be

Binary/B feels largely right, but it has a few too many methods from Array simply because Array had them for my taste, specifically things like sort, reduce, shift, unshift etc.

Conceptually: why would you want to sort an array of bytes? There are certainly classes of operations that I think should just be done via b.toArray().X rather than directly on the blob.

As a community (CommonJS) we'd be more than happy to go forward with a binary spec that came from (or at least has the blessing of) the ES groups

Binary/B is the closest of the three proposals to mine, in that it has both mutable and immutable binary data containers. Here are a few key differences:

(1) Binary/B does not have a cheap way to convert from the immutable representation (ByteString) to the mutable representation (ByteArray)

(2) In Binary/B, Array-like index access to ByteString gives back one-byte ByteStrings instead of bytes, likely an over-literal copying of String

(3) There are some seemingly needless differences in the interfaces to ByteString and ByteArray that follow from modeling on String and Array

(4) Binary/B has many more operations available in the base proposal (including charset transcoding and a generous selection of String and Array methods)

(5) Different names - Data/DataBuilder vs. ByteString/ByteArray

My initial impression is that (1), (2) and (3) are all points on which my proposal is better. On (1): cheap conversion from mutable to immutable (DataBuilder.prototype.release() in my proposal) lets binary data objects be built up with a convenient mutation-based idiom, but then passed around as immutable objects thereafter. On (2): I don't think a one-byte ByteString is ever useful, indexing to get the byte value would be much more helpful. On (3), I think it's good for the mutable interface to be a strict superset of the the immutable interface.

(4) and (5) are all points where perhaps neither proposal is at the optimum yet. On (4), I suspect the sweet spot is somewhere between my spartan set of built-in operations and the very generous set in Binary/B. On (5), I'm not sure either set of names is the best possible, and I'm certainly not stuck on my own proposed names.

Regards,

Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Presentation on modules

2009-11-07T11:27:19Z

On Sat, Nov 7, 2009 at 11:10 AM, Brendan Eich <brendan@...> wrote:
> The alternative for Harmony is a syntactic special form, an import directive
> for example, that can be analyzed when the program is parsed ...

+1. In Caja, we were loath to introduce new syntax _per se_, and we
are already compiling, so ours is a bit of a special case. Were there
some standard syntax the semantics of which we could implement, our
lives would be far easier.

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Presentation on modules

2009-11-07T11:10:21Z

So (as was clarified at the meeting) the Caja work is quite informative, but we are not looking at any Harmony module system that requires ahead-of-time code analysis and transformation before code reaches the browser.

The alternative for Harmony is a syntactic special form, an import directive for example, that can be analyzed when the program is parsed (not executed), so the implementation can preload all dependencies before execution to avoid blocking on an import (or a later data dependency), or else an awkward non-blocking import to preserve JS's run-to-completion execution model.

Async (non-blocking) import functionality (a runtime API) is good too but it should not be the only way, or the common way.

There's more to say about modules but I'll let others speak up.

/be

On Nov 7, 2009, at 9:03 AM, ihab.awad@... wrote:

On Sat, Nov 7, 2009 at 8:34 AM, Ash Berlin <ash_js@...> wrote:
Slide 10 says "Sync, arg must be a string literal". 1) why a string
*literal*, ...

It's the simplest form of statically determinable identifier. We could
say, "arg must be an expression that statically evaluates to a
string", like:

'f' + 'oo'

but we chose the simplest interpretation.

Essentially, we are making 'load' a special form.

... and 2) how can that be enforced?

The Caja system is a compiler. :)

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Presentation on modules

2009-11-07T09:03:58Z

On Sat, Nov 7, 2009 at 8:34 AM, Ash Berlin <ash_js@...> wrote:
> Slide 10 says "Sync, arg must be a string literal". 1) why a string
> *literal*, ...

It's the simplest form of statically determinable identifier. We could
say, "arg must be an expression that statically evaluates to a
string", like:

'f' + 'oo'

but we chose the simplest interpretation.

Essentially, we are making 'load' a special form.

> ... and 2) how can that be enforced?

The Caja system is a compiler. :)

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Presentation on modules

2009-11-07T08:34:47Z

On 7 Nov 2009, at 16:28, ihab.awad@... wrote:

> Hi folks,
>
> Here is a link to the presentation on modules I gave during the TC39
> meeting in Santa Clara, CA yesterday.
>
> http://sites.google.com/site/ihabawad/Home/es5Modules-2009-11-06.pdf
>
> Cheers and regards,
>
> Ihab

Slide 10 says "Sync, arg must be a string literal". 1) why a string
*literal*, and 2) how can that be enforced?
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Presentation on modules

2009-11-07T08:28:32Z

Hi folks,

Here is a link to the presentation on modules I gave during the TC39
meeting in Santa Clara, CA yesterday.

http://sites.google.com/site/ihabawad/Home/es5Modules-2009-11-06.pdf

Cheers and regards,

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-07T05:39:35Z

On 6 Nov 2009, at 19:24, Brendan Eich wrote:

On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:

Just in case some of you weren't aware, the CommonJS group has done quite a bit of work and (bikeshedding) on this topic. Here's a link to the wiki:

http://wiki.commonjs.org/wiki/Binary

If nothing else there's quite a bit of prior art collected which should inform the conversation. I know the Binary/B proposal has the implementation momentum, but I don't know exactly what the status is. I haven't been closely following the evolution of these binary specs too closely but since it seems that nearly everyone else from the group is off to jsconf.eu I figured I ought to toss this out there.

Thanks, I had forgotten about commonjs.org, having once paid better attention.

Kris did a good job with Binary/B (although I do not see the point of the .get method additions) -- I didn't look at the other proposals yet.

/be

Binary/B feels largely right, but it has a few too many methods from Array simply because Array had them for my taste, specifically things like sort, reduce, shift, unshift etc.

Conceptually: why would you want to sort an array of bytes? There are certainly classes of operations that I think should just be done via b.toArray().X rather than directly on the blob.

As a community (CommonJS) we'd be more than happy to go forward with a binary spec that came from (or at least has the blessing of) the ES groups

-ash

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T15:39:37Z

On Nov 6, 2009, at 1:39 PM, Alex Russell wrote:

> On Nov 6, 2009, at 11:30 AM, Maciej Stachowiak wrote:
>
>>
>> On Nov 6, 2009, at 5:43 AM, P T Withington wrote:
>>
>>> On 2009-11-05, at 19:42, Maciej Stachowiak wrote:
>>>
>>>> My claim is that Data is not much like these things. I believe it
>>>> is more like String. It happens to be a sequence (of a very
>>>> specific type), but it's specialized enough to be worth treating
>>>> differently. Do people often regret that String is not an Array?
>>>
>>> Data is like an 8-bit "null encoded" String. Which makes me
>>> wonder if you really just want to extend String to allow different
>>> encodings. But I also regret String not being and Array. Others
>>> must have too, because at one point I'm sure there was a proposal
>>> to make [] on string mean charAt?
>>
>> ES5 does have bracket index access to the individual characters.
>> But it does not make String inherit from Array.prototype, or add
>> all of the Array methods. To make it more concrete, have you ever
>> wished you could use methods like map(), filter(), reduce() or
>> join() on a String?
>
> join's an oddball since it's effectively a no-op, but map() and
> filter(), absolutely.

Can you give specific use cases for these, maybe with hypothetical
code examples?

Join would not be a no-op, and indeed you can use Array.prototype.join
on a String today:

javascript:alert(Array.prototype.join.call("abcde", "123")) ==>
"a123b123c123d123e"

Not a no-op but I'm not sure it's useful.

Regards,
Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T13:43:37Z

On Fri, Nov 6, 2009 at 4:39 PM, Alex Russell <alex@...> wrote:
> On Nov 6, 2009, at 11:30 AM, Maciej Stachowiak wrote:
>> ES5 does have bracket index access to the individual characters. But it
>> does not make String inherit from Array.prototype, or add all of the Array
>> methods. To make it more concrete, have you ever wished you could use
>> methods like map(), filter(), reduce() or join() on a String?
>
> join's an oddball since it's effectively a no-op, but map() and filter(),
> absolutely.

I've used join too (though not with an empty separator, indeed), and
map/filter for various string pack and encode operations, but I don't
think that I would mind too much having to say

Array.join(strOrDataThing, "\n");

instead of

strOrData.filter(function (v) { return v.charCodeAt(0) < 128; });

Mike
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss