Re: Iteration of the Arguments object
The minutes from the November 29, 2012 meeting http://esdiscuss.org/notes/2012-11-29 say: Conclusion/Resolution Add iterator protocol to arguments object (should exist on all things. Array.from: 1. Iterator protocol 2. Array-Like for-of spread: 1. Iterator protocol -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Working with grapheme clusters
The internationalization working group is planning to support grapheme clusters
through its text segmentation API - the strawman:
http://wiki.ecmascript.org/doku.php?id=globalization:text_segmentation
Note that Unicode Standard Annex #29 allows for tailored (language sensitive)
grapheme clusters, which makes ECMA-402 a better fit than ECMA-262.
Norbert
On Oct 24, 2013, at 7:02 , Claude Pache claude.pa...@gmail.com wrote:
Hello,
You might know that the following ES expressions are broken:
text.charAt(0) // get the first character of the text
text.length 100 ? text.substring(0,100) + '...' : text // cut the
text after 100 characters
The reason is *not* because ES works with UTF-16 code units instead of
Unicode code points (it's just a red herring!), but
because _graphemes_ (that is, what a human perceives as a character) may
span multiple code units and/or code points.
For example, the letter n̈ (n with diaeresis) is coded using two code
points, namely
U+006E (LATIN SMALL LETTER N) and U+0308 (COMBINING DIAERESIS), and two
UTF-16 code units,
and it should be avoided to cut a string between these two codes in order to
keep the resulting text meaningful for humans.
(Nota bene: I have carefully chosen a grapheme that exists in a current
written language and does not exist
as precomposed Unicode character.)
The correct technical notion to use here, is the notion of grapheme
cluster, that is
a sequence of Unicode code points that represents a grapheme.
See [UAX29] (Unicode Standard Annex #29: Unicode text segmentation), section
3, for more info.
Therefore, I propose the following basic operations to operate on grapheme
clusters:
(1) String.prototype.graphemeAt(pos)
This method is similar to `String.prototype.charAt()`, but it returns a
grapheme cluster instead of a string
composed of a single UTF-16 code unit. More precisely, it returns the
shortest substring of `this`
beginning at position `pos` (inclusively) and ending at position `pos2`
(exclusively), where `pos2` is the
smallest position in `this` which is greater than `pos` and which is an
(extended) grapheme cluster boundary,
according to the specification in [UAX29], section 3.1.
If `pos` is out of bounds, an empty string is returned.
(2) String.prototype.graphemes(start = 0)
This method returns an iterator, enumerating the graphemes of `this`,
starting at position `start`.
Given the `String.prototype.graphemeAt` method as above,
it could be approximatively expressed in ES6 as follows (ignoring edge cases):
String.prototype.graphemes = function*(pos = 0) {
pos = Math.floor(pos)
if (pos 0 || Number.isNaN(pos))
pos = 0
while (pos this.length) {
let grapheme = this.graphemeAt(pos)
pos += grapheme.length
yield grapheme
}
}
So, the two examples of the beginning of my message could be correctly
implemented as follows:
text.graphemeAt(0) // get the first grapheme of the text
// shorten a text to its first hundred graphemes
var shortenText = ''
let numGraphemes = 0
for (let grapheme of text) {
numGraphemes += 1
if (numGraphemes 100) {
shortenText += '…'
break
}
shortenText += grapheme
}
As a side note, I ask whether the `String.prototype.symbolAt
`/`String.prototype.at` as proposed in a recent thread,
and the `String.prototype[@@iterator]` as currently specified, are really
what people need,
or if they would mistakenly use them with the intended meaning of
`String.prototype.graphemeAt`
and `String.prototype.graphemes` as discussed in the present message?
Thoughts?
Claude
[UAX29]: http://www.unicode.org/reports/tr29/ Unicode Standard Annex #29:
Unicode text segmentation.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Working with grapheme clusters
On Oct 24, 2013, at 7:38 , Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Oct 24, 2013 at 3:31 PM, Mathias Bynens math...@qiwi.be wrote:
Imagine you’re writing a JavaScript library that escapes a given string as
an HTML character reference, or as a CSS identifier, or anything else. In
those cases, you don’t care about grapheme clusters, you care about code
points, cause those are the units you end up escaping individually.
Is that really a common operation? I would expect formatting,
searching, etc. to dominate. E.g. whenever you do substr/substring you
would want that to be grapheme-cluster aware.
There are cases where you don't care about grapheme clusters, e.g. if you want
to replace any occurrence of { + varname + } in a string with the value of
the variable named varname.
In cases where you do care about grapheme clusters, it's usually more efficient
to search based on code points or code units first, and then check whether the
substring found begins and ends on grapheme cluster boundaries (e.g., if a
search for n finds the first character of Claude's example n̈, then you'll
want to ignore that match).
Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Working with grapheme clusters
On Oct 25, 2013, at 18:35 , Jason Orendorff jason.orendo...@gmail.com wrote: UTF-16 is designed so that you can search based on code units alone, without computing boundaries. RegExp searches fall in this category. Not if the RegExp is case insensitive, or uses a character class, or ., or a quantifier - these all require looking at code points rather than UTF-16 code units in order to support the full Unicode character set. Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Working with grapheme clusters
* Norbert Lindenberg wrote: On Oct 25, 2013, at 18:35 , Jason Orendorff jason.orendo...@gmail.com wrote: UTF-16 is designed so that you can search based on code units alone, without computing boundaries. RegExp searches fall in this category. Not if the RegExp is case insensitive, or uses a character class, or ., or a quantifier - these all require looking at code points rather than UTF-16 code units in order to support the full Unicode character set. If you have a regular expression over an alphabet like Unicode scalar values it is easy to turn it into an equivalent regular expression over an alphabet like UTF-16 code units. I have written a Perl module that does it for UTF-8, http://search.cpan.org/dist/Unicode-SetAutomaton/; Russ Cox's http://swtch.com/~rsc/regexp/regexp3.html#step3 is a popular implementation. In effect it is still as though the implementation used Unicode scalar values, but that would be true of any implementation. It is much harder to implement something like this for other encodings like UTF-7 and Punycode. It is useful to keep in mind features like character classes are just syntactic sugar and can be decomposed into regular expression primitives like a choice listing each member of the character class as literal. The `.` is just a large character class, and flags like //i just transform parts of an expression where /a/i becomes something more like /a|A/. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Generic Bundling
± Because using a ZIP file is a bad practice we certainly should not ± allow. As stated before, it will make the website slow [...] ± ± It seems what you're saying is that there are already superior ways to bundle ± JS modules and we don't need W3C to define another one. ± Perhaps—but this definitely has nothing to do with the ES module loaders ± proposal before TC39, which is bunding-system agnostic. ± ± We'll be working with the HTML standards folks to decide how the browser's ± default loader will work, but basically I expect it'll just fetch URLs. That means ± it'll support HTTP2 out of the box, if the server supports it, and zip urls if ± W3C decides to spec such a thing. Apps can of course customize the loader if ± they need some custom bundling scheme. So your beef is not with us or with ± the HTML WG but with the TAG—or wherever the work on zip urls is taking ± place these days (I really don't know). I agree with you here. I think the word allow is an overstatement I didn't really intend. As I said further in the mail, a platform should always be flexible enough to make sure you can do something if you so want (i.e. with a Domain Controller). What I meant is indeed that the ZIP bundling is a measurably suboptimal practice overall and should not be promoted (i.e. made simpler than the state-of-art approach and/or mentioned as an acceptable solution). If ZIP URLs are found necessary for other use cases and are added to the platform, there's no reason to ban them from the Module Loader spec. But it remains that it's not a good practice in most cases. Bundling in general is not going to be a valid approach for any purpose related to efficiency soon (except maybe archive-level compression where grouping similar files may improve compression rate slightly). My point is that I'm not sure it's worth exploring bundling in the case of new standards that are going to be used in a future that someone can expect to come after HTTP2 birth. My intuition is that by the time every browser supports ES6, they will most likely support HTTP2 too - most of the already support drafts of it. It's not sure that most servers will support HTTP2 at that time, though. Therefore, I don't say this approach isn't worth exploring at all, but it's a temporary solution at best. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Working with grapheme clusters
On Fri, Oct 25, 2013 at 11:42 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Oct 25, 2013, at 18:35 , Jason Orendorff jason.orendo...@gmail.com wrote: UTF-16 is designed so that you can search based on code units alone, without computing boundaries. RegExp searches fall in this category. Not if the RegExp is case insensitive, or uses a character class, or ., or a quantifier - these all require looking at code points rather than UTF-16 code units in order to support the full Unicode character set. Can you explain this more? ISTM case insensitive searches and character classes don't require finding boundaries in the string being searched. Matching /./ does, sometimes. The common use is /.*/ and in that case you don't have to find all boundaries in the text being matched, only at the end or (again, only in certain cases) if you have to backtrack. Of course all those things have code-point-oriented *semantics*, which is great. But the implementation can be faster than that. I'd like to know what you have in mind regarding quantifiers though. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On Sat, Oct 26, 2013 at 9:05 AM, François REMY francois.remy@outlook.com wrote: Bundling in general is not going to be a valid approach for any purpose related to efficiency soon (except maybe archive-level compression where grouping similar files may improve compression rate slightly). My point is that I'm not sure it's worth exploring bundling in the case of new standards that are going to be used in a future that someone can expect to come after HTTP2 birth. This is a very narrow perspective. Bundling may not necessarily serve the use cases that it currently serves once HTTP2 is deployed. However, we should consider why real game engines use sprites, why Java uses JAR files, and why native applications are constantly reconsidering tradeoffs around single vs multiple dynamically-loaded shared libraries -- all on local file systems. I/O isn't free, multiple I/O requests are not free, and there will always be tradeoffs in this space. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Object.create() VS functions
Bonjour à tous,
`Knowing that every function is an object, I am surprised that the
Object.create() method doesn't really allow cloning function.
So I made an implementation as follows:
`Object.create = (function () {
'use strict';
var slice,
curry,
getOwnPropertyNames,
getOwnPropertyDescriptor,
defineProperty,
onProperty,
onDescriptor,
create;
slice = (function () {
var method;
method = [].slice;
return method.call.bind(method);
}());
curry = function curry(fn) {
var args;
args = slice(arguments, 1);
return function() {
return fn.apply(
this,
args.concat(
slice(arguments)
)
);
};
};
getOwnPropertyNames = curry(Object.getOwnPropertyNames);
getOwnPropertyDescriptor = curry(Object.getOwnPropertyDescriptor);
defineProperty = curry(Object.defineProperty);
onProperty = function onProperty(prototype, property) {
var descriptor;
descriptor = getOwnPropertyDescriptor(this, property);
if (descriptor === undefined || descriptor.writable ||
descriptor.configurable) {
defineProperty(this, property,
getOwnPropertyDescriptor(prototype, property));
}
};
onDescriptor = function onDescriptor(propertyDescriptors, property) {
defineProperty(this, property, propertyDescriptors[property]);
};
create = function create(prototype, propertyDescriptors) {
var returnValue, onProtoProperty, onPropertyDescriptor;
returnValue = prototype instanceof Function
? curry(prototype)
: {};
getOwnPropertyNames(prototype)
.forEach(onProperty.bind(returnValue, prototype));
if (typeof propertyDescriptors === 'object') {
getOwnPropertyNames(propertyDescriptors)
.forEach(onDescriptor.bind(returnValue, propertyDescriptors));
}
return returnValue;
};
return create;
}());`
Is there a reason not to do that, please?
Thanks in advance.
Michaël Rouges - https://github.com/Lcfvs - @Lcfvs
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.create() VS functions
On 10/26/2013 7:44 AM, Michaël Rouges wrote: Knowing that every function is an object, I am surprised that the Object.create() method doesn't really allow cloning function. Object.create creates Objects. You run into the same limitation when trying to create Arrays with Object.create (doesn't work correctly). You're looking for Function.create [1], which doesn't yet exist (although you can get pretty close using Proxies for functions). [1] A sample implementation of Function.create can be found on http://wiki.ecmascript.org/doku.php?id=strawman:name_property_of_functions ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Working with grapheme clusters
* Claude Pache wrote: You might know that the following ES expressions are broken: text.charAt(0) // get the first character of the text text.length 100 ? text.substring(0,100) + '...' : text // cut the text after 100 characters The reason is *not* because ES works with UTF-16 code units instead of Unicode code points (it's just a red herring!), but because _graphemes_ (that is, what a human perceives as a character) may span multiple code units and/or code points. The example is deceptively simple. Truncating a string is a hard problem and a high quality implementation would probably be language-specific to avoid problematic truncations like when a suffix changes the meaning of a prefix; it would also take special characters into account, say you do not want the last character before the ... to be an open quote mark, and if the string is 101 characters ending in ... turning that into a string of 103 characters ending in . would also be silly. Another issue that is often ignored is that you might want to use the truncated text in combination with other text, say in a HTML document with a more or permalink or some such link after it. Something like pABC #x202E; DEF #x202C; GHI a href='...'more/a/p pABC #x202E; DEF ... a href='...'more/a/p The second paragraph will render ABC erom ... FED because the control character that restores the bidirectional text state got lost when the string was truncated. These are all issues that counting graphemes in- stead of 16 bit units does not address and it is not clear to me that it would actually be an improvement. User-perceived character is not an intuitive notion especially once you leave the realm of letters from a familiar script. In a string that contains 1 user-perceived character, what is the maximum number of zero- width spaces in that string? The maximum number of scalar values? What is the maximum width and maximum height of such a string when rendered, the maximum number of UTF-8 bytes needed to encode such a string? Should one perceive a horizontal ellipsis as three characters, or is it just one? How many are two thin spaces? My smartphone comes with a News application that displays the latest headlines from various news sources and links to corresponding articles. If you use it for a day or two you will notice that it's not of German design, but one for a language that uses fewer or narrower grapheme clusters per unit of information if you will. Many of the headlines do not convey what the article might be about. A current example is 'Code- name Lustre - Frankreich liefert' which is roughly 'code name lustre - France supplies' ... what? What does France supply? Or Dortmund droht historische Pleite im roughly Dortmund faces historic ... in where Pleite could be bankruptcy, defeat, failure, ... could be sport, could be finance, can't tell. That makes the application rather frustrating to use with german news. I imagine it works better with english headlines which tend to use fewer grapheme clusters. So truncating news headlines after a certain number of grapheme clusters untailored to the specific script and language is not the right design choice. Actually, it might be truncated by pixel measures because there is a visual space to fit, but english and german are very similar in their pixels per grapheme cluster metrics... So it seems rather unlikely for someone to say so we need the first 100 extended grapheme clusters as defined in UAX #29 of the string and then someone responding yes, that is clearly the right solution. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.create() VS functions
Le 26/10/2013 15:44, Michaël Rouges a écrit :
Bonjour à tous,
Bonjour,
`Knowing that every function is an object, I am surprised that the
Object.create() method doesn't really allow cloning function.
I don't follow the logic of this sentence.
In any case, the purpose of Object.create is to create a normal object,
that is an object as commonly understood when it comes to its own
properties (no magic property like array's length), without private
state (like Date objects) and that is not callable.
Also, Object.create does not create a clone, but a new object.
implementation
If you don't care about |this|, f2 = f.bind(undefined) can be considered
as a way to clone a function.
function f2(){
return f.apply(this, arguments);
}
works too.
f2 = new Proxy(f, {})
is a form of function cloning as well.
Very much like object cloning, function cloning does not have one unique
definition.
Is there a reason not to do that, please?
I would ask the opposite question: is there a reason to do that? Usually
features are added because there is a driving use case which you haven't
provided.
Also, usually, changing the semantics of an existing built-in isn't a
good idea given that it may break existing code relying on it.
Last, if you can implement it yourself, why do you need it to be part of
the language? There are hundreds of convenience functions that could be
added. Why this one more than others?
Thanks,
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Object.create() VS functions
Before getting into the exact situation with `Object.create` and functions, the
first thing to understand is that `Object.create(proto)` creates an object with
prototype of `proto`. As others have said, this is different from cloning.
Here's a simple example which should show the differences between the built-in
`Object.create` and your version which creates a clone.
var A = { foo: 1 },
B = Object.create(A);
A.foo = 7;
console.log(B.foo); // = 7
With your version of `Object.create`, the last line would log `1` instead of
`7`. With built-in `Object.create` it's `7` because `A` is the prototype of
`B`, so on property access all own properties of `B` are checked first and if a
match isn't found then the properties of `A` are checked.
To continue the above example:
B.foo = 8;
console.log(B.foo); // = 8
delete B.foo;
console.log(B.foo); // = 7
Make sense?
Nathan
Date: Sat, 26 Oct 2013 16:44:53 +0200
Subject: Object.create() VS functions
From: michael.rou...@gmail.com
To: es-discuss@mozilla.org
Bonjour à tous,
`Knowing that every function is an object, I am surprised that the
Object.create() method doesn't really allow cloning function.
So I made an implementation as follows:
`Object.create = (function () {
'use strict';
var slice,
curry,
getOwnPropertyNames,
getOwnPropertyDescriptor,
defineProperty,
onProperty,
onDescriptor,
create;
slice = (function () {
var method;
method = [].slice;
return method.call.bind(method);
}());
curry = function curry(fn) {
var args;
args = slice(arguments, 1);
return function() {
return fn.apply(
this,
args.concat(
slice(arguments)
)
);
};
};
getOwnPropertyNames = curry(Object.getOwnPropertyNames);
getOwnPropertyDescriptor = curry(Object.getOwnPropertyDescriptor);
defineProperty = curry(Object.defineProperty);
onProperty = function onProperty(prototype, property) {
var descriptor;
descriptor = getOwnPropertyDescriptor(this, property);
if (descriptor === undefined || descriptor.writable ||
descriptor.configurable) {
defineProperty(this, property,
getOwnPropertyDescriptor(prototype, property));
}
};
onDescriptor = function onDescriptor(propertyDescriptors, property) {
defineProperty(this, property, propertyDescriptors[property]);
};
create = function create(prototype, propertyDescriptors) {
var returnValue, onProtoProperty, onPropertyDescriptor;
returnValue = prototype instanceof Function
? curry(prototype)
: {};
getOwnPropertyNames(prototype)
.forEach(onProperty.bind(returnValue, prototype));
if (typeof propertyDescriptors === 'object') {
getOwnPropertyNames(propertyDescriptors)
.forEach(onDescriptor.bind(returnValue, propertyDescriptors));
}
return returnValue;
};
return create;
}());`
Is there a reason not to do that, please?
Thanks in advance.
Michaël Rouges - https://github.com/Lcfvs - @Lcfvs
___ es-discuss mailing list
es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Object.create() VS functions
Thank you for your answers. Sorry for my misnomer, I meant to copy a function, not to clone a function. In fact, it's been a while I do the technical research around the JavaScript , and this research has led me to realize that there is no feature to simply copy a function (or class) , including the properties thereof. Regarding your exremièrement, there is a major difference between fn.bind() and new Proxy(fn), fn.bind() doesn't copy the properties of the initial function. Then, new Proxy(fn) doesn't allow to add properties to the returned function as my Object.create(). @Nathan : Thanks, a little too excited in my mind, I have made a mistake, I will correct it. ;) Michaël Rouges - https://github.com/Lcfvs - @Lcfvs ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Proposal to simplify Generators impact
It's really needed to make js syntax more complex in order to implement
generators?
It's function* really needed?
can you just expose Generator as a core function?
can yield be a function-call-like-construct instead of a new language
construction?
function fibonacci() {
let [prev, curr] = [0, 1];
for (;;) {
[prev, curr] = [curr, prev + curr];
yield(curr);
}}
Generators can be iterated over in loops:
for (n of new Generator(fibonacci) {
// truncate the sequence at 1000
if (n 1000)
break;
print(n);}
Generators are iterators:
let seq = new Generator(fibonacci);print(seq.next()); //
1print(seq.next()); // 2print(seq.next()); // 3print(seq.next()); //
5print(seq.next()); // 8
Advantages: No new syntax, no function* (Cognitive dissonance, every good
C programmer can't stop reading function* as function pointer). No
yield new construction. No added complexity to the language syntax.
By not adding new elements and complexity to the language, you're keeping
it consistent.
By using new Generator(fn) to create a Object-Generator, you can also
expose a done property and other useful info in a standard way.
Note: why yield syntax should be like a function call:
In actual implementations (V8 --harmony) yield will return the value
passed in the call to .next
function giveNext(){ //generator
let actual = 10;
while (actual100){
skip = yield(actual);
actual = actual + skip || 5;
};};
let seq = new Generator(giveNext);print(seq.next()); //
10print(seq.next()); // 15print(seq.next(20)); // 35print(seq.next());
*// 40let* seq = new Generator(giveNext);
while (!seq.done)
print(seq.next());
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal to simplify Generators impact
On Sat, Oct 26, 2013 at 1:01 PM, Lucio Tato luciot...@gmail.com wrote:
It's really needed to make js syntax more complex in order to implement
generators?
It's function* really needed?
Yes, because `yield` is only reserved in strict mode code, which means this
is valid today:
function g() { yield = 1; return yield; }
Since the starred generator function is a new syntactic form, there is no
existing code that it can possibly break by making yield a keyword.
can you just expose Generator as a core function?
can yield be a function-call-like-construct instead of a new language
construction?
No, because there may already be code that defines a function called
`yield`, which would be broken if suddenly yield was a special
language-owned function. Consider this:
// your code defines this...
function yield() { return Number.MAX_VALUE; }
// you then include my library, which exposes this fibonacci():
function fibonacci() {
let [prev, curr] = [0, 1];
for (;;) {
[prev, curr] = [curr, prev + curr];
yield(curr);
}}
What does yield() do? It returns Number.MAX_VALUE every time.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
Is it possible to not put HTTP in the middle of your thoughts? Why is **non HTTP** bundling a no go? Don't you donwload a single blob to install chrome and then eventually have incremental updates? Why that single blob at the beginning should not be possible only in JS since every other programming langauge has one and working without HTTP in the middle? Without servers? Without an internet connection ? Thanks On Fri, Oct 25, 2013 at 8:39 PM, Ilya Grigorik igrigo...@gmail.com wrote: On Fri, Oct 25, 2013 at 12:17 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Ilya ... just to re-clarify what was the discussion about: Generic Bundling ... not HTTP Bundling. I don't know why many keep coupling and confining HTML5 over HTTP and nothing else. Bundling as you do with executables or apps, bundling as you send a single file update for your customer to replace instead of unzipping, overwriting each file, etcetera. Why is in your opinion bundling bad for non HTTP, offline, apps created using these technologies ? Every programming language I know have some bundle support that works as single package/file ... C has the executable, then we have phar, war, jar, python has many ... what about JS ? Won't work without HTTP ? Why ? I'm not saying it won't work. I'm saying there are many downsides to distributing large blobs of data. Case in point, once you start distributing large blobs, you'll soon realize that it sucks that you have to download the entire blob every time a single byte has changed. As a result, you end up developing binary-diff formats.. like Courgette [1] that we use to update Chrome. A much simpler solution for web apps is to do exactly what AppCache did, create a manifest which lists all the resources, and let HTTP do the rest: each file can be downloaded and updated individually, etc. ig [1] http://www.chromium.org/developers/design-documents/software-updates-courgette On Thu, Oct 24, 2013 at 11:17 PM, Ilya Grigorik igrigo...@gmail.comwrote: + 1 to François's comments. You're not saying that gzipping and wise pre-fetching and parallel download of scripts don't improve page load times. Or are you? - We already have transfer-encoding in HTTP, and yes, you should definitely use it! - Prefetching is also an important optimization, but in the context of this discussion (bundling), it's an orthogonal concern. In the equation you paint above something important is missing: the fact that there's a round-trip delay per request (even with http2.0), and that the only way to avoid it is to bundle things, as in .zip bundling, to minimize the (number of requests and thus the) impact of latencies. With HTTP 1.x (and without sharding) you can fetch up to six resources in parallel. With HTTP 2.0, you can fetch as many resources as you wish in parallel. The only reason bundling exists as an optimization is to work around the limit of six parallel requests. The moment you remove that limitation, bundling is unnecessary and only hurts performance. And there's something else I think .zip bundling can provide that http2.0 can't: the guarantee that a set of files are cached by the time your script runs: with such a guarantee you could do synchronous module require()s, à la node.js. This is completely orthogonal... if you need to express dependencies between multiple resources, use a loader script, or better.. look into using upcoming promise API's. As I mentioned previously, bundling breaks streaming / incremental execution / prioritization. ig ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
I can’t help but repeat, what you describe is called an app package format. Windows 8 has one, Chrome has one, Firefox OS has one; others may have one, too. There are discussions about a standardized app package format going on, but they are not happening on es-discuss. Why do you think this discussion belongs to es-discuss? Did I miss something? De : Andrea Giammarchi Envoyé : samedi 26 octobre 2013 22:15 À : 'Ilya Grigorik' Cc : es-discuss Is it possible to not put HTTP in the middle of your thoughts? Why is **non HTTP** bundling a no go? Don't you donwload a single blob to install chrome and then eventually have incremental updates? Why that single blob at the beginning should not be possible only in JS since every other programming langauge has one and working without HTTP in the middle? Without servers? Without an internet connection ? Thanks On Fri, Oct 25, 2013 at 8:39 PM, Ilya Grigorik igrigo...@gmail.com wrote: On Fri, Oct 25, 2013 at 12:17 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Ilya ... just to re-clarify what was the discussion about: Generic Bundling ... not HTTP Bundling. I don't know why many keep coupling and confining HTML5 over HTTP and nothing else. Bundling as you do with executables or apps, bundling as you send a single file update for your customer to replace instead of unzipping, overwriting each file, etcetera. Why is in your opinion bundling bad for non HTTP, offline, apps created using these technologies ? Every programming language I know have some bundle support that works as single package/file ... C has the executable, then we have phar, war, jar, python has many ... what about JS ? Won't work without HTTP ? Why ? I'm not saying it won't work. I'm saying there are many downsides to distributing large blobs of data. Case in point, once you start distributing large blobs, you'll soon realize that it sucks that you have to download the entire blob every time a single byte has changed. As a result, you end up developing binary-diff formats.. like Courgette [1] that we use to update Chrome. A much simpler solution for web apps is to do exactly what AppCache did, create a manifest which lists all the resources, and let HTTP do the rest: each file can be downloaded and updated individually, etc. ig [1] http://www.chromium.org/developers/design-documents/software-updates-courgette On Thu, Oct 24, 2013 at 11:17 PM, Ilya Grigorik igrigo...@gmail.com wrote: + 1 to François's comments. You're not saying that gzipping and wise pre-fetching and parallel download of scripts don't improve page load times. Or are you? - We already have transfer-encoding in HTTP, and yes, you should definitely use it! - Prefetching is also an important optimization, but in the context of this discussion (bundling), it's an orthogonal concern. In the equation you paint above something important is missing: the fact that there's a round-trip delay per request (even with http2.0), and that the only way to avoid it is to bundle things, as in .zip bundling, to minimize the (number of requests and thus the) impact of latencies. With HTTP 1.x (and without sharding) you can fetch up to six resources in parallel. With HTTP 2.0, you can fetch as many resources as you wish in parallel. The only reason bundling exists as an optimization is to work around the limit of six parallel requests. The moment you remove that limitation, bundling is unnecessary and only hurts performance. And there's something else I think .zip bundling can provide that http2.0 can't: the guarantee that a set of files are cached by the time your script runs: with such a guarantee you could do synchronous module require()s, à la node.js. This is completely orthogonal... if you need to express dependencies between multiple resources, use a loader script, or better.. look into using upcoming promise API's. As I mentioned previously, bundling breaks streaming / incremental execution / prioritization. ig ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
Apologies, I just answered what Ilya answered but I'd like to see this discussion ... where is this happening? Thanks a lot and send even off thread if you can. On Sat, Oct 26, 2013 at 2:10 PM, François REMY francois.remy@outlook.com wrote: I can’t help but repeat, what you describe is called an app package format. Windows 8 has one, Chrome has one, Firefox OS has one; others may have one, too. There are discussions about a standardized app package format going on, but they are not happening on es-discuss. Why do you think this discussion belongs to es-discuss? Did I miss something? *De :* Andrea Giammarchi andrea.giammar...@gmail.com *Envoyé :* samedi 26 octobre 2013 22:15 *À :* 'Ilya Grigorik' igrigo...@gmail.com *Cc :* es-discuss es-discuss@mozilla.org Is it possible to not put HTTP in the middle of your thoughts? Why is **non HTTP** bundling a no go? Don't you donwload a single blob to install chrome and then eventually have incremental updates? Why that single blob at the beginning should not be possible only in JS since every other programming langauge has one and working without HTTP in the middle? Without servers? Without an internet connection ? Thanks On Fri, Oct 25, 2013 at 8:39 PM, Ilya Grigorik igrigo...@gmail.comwrote: On Fri, Oct 25, 2013 at 12:17 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Ilya ... just to re-clarify what was the discussion about: Generic Bundling ... not HTTP Bundling. I don't know why many keep coupling and confining HTML5 over HTTP and nothing else. Bundling as you do with executables or apps, bundling as you send a single file update for your customer to replace instead of unzipping, overwriting each file, etcetera. Why is in your opinion bundling bad for non HTTP, offline, apps created using these technologies ? Every programming language I know have some bundle support that works as single package/file ... C has the executable, then we have phar, war, jar, python has many ... what about JS ? Won't work without HTTP ? Why ? I'm not saying it won't work. I'm saying there are many downsides to distributing large blobs of data. Case in point, once you start distributing large blobs, you'll soon realize that it sucks that you have to download the entire blob every time a single byte has changed. As a result, you end up developing binary-diff formats.. like Courgette [1] that we use to update Chrome. A much simpler solution for web apps is to do exactly what AppCache did, create a manifest which lists all the resources, and let HTTP do the rest: each file can be downloaded and updated individually, etc. ig [1] http://www.chromium.org/developers/design-documents/software-updates-courgette On Thu, Oct 24, 2013 at 11:17 PM, Ilya Grigorik igrigo...@gmail.comwrote: + 1 to François's comments. You're not saying that gzipping and wise pre-fetching and parallel download of scripts don't improve page load times. Or are you? - We already have transfer-encoding in HTTP, and yes, you should definitely use it! - Prefetching is also an important optimization, but in the context of this discussion (bundling), it's an orthogonal concern. In the equation you paint above something important is missing: the fact that there's a round-trip delay per request (even with http2.0), and that the only way to avoid it is to bundle things, as in .zip bundling, to minimize the (number of requests and thus the) impact of latencies. With HTTP 1.x (and without sharding) you can fetch up to six resources in parallel. With HTTP 2.0, you can fetch as many resources as you wish in parallel. The only reason bundling exists as an optimization is to work around the limit of six parallel requests. The moment you remove that limitation, bundling is unnecessary and only hurts performance. And there's something else I think .zip bundling can provide that http2.0 can't: the guarantee that a set of files are cached by the time your script runs: with such a guarantee you could do synchronous module require()s, à la node.js. This is completely orthogonal... if you need to express dependencies between multiple resources, use a loader script, or better.. look into using upcoming promise API's. As I mentioned previously, bundling breaks streaming / incremental execution / prioritization. ig ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
I think it was once discussed at public-weba...@w3.org. → http://www.w3.org/TR/2012/PER-widgets-20120925/#zip-archive At some point there was also a community group but I’m not sure it’s still active; it published some interesting format comparisons: → http://www.w3.org/community/webappstore/wiki/Manifest There are a lot of links you can follow from there. De : Andrea Giammarchi Envoyé : samedi 26 octobre 2013 23:29 À : François REMY Cc : 'Ilya Grigorik', es-discuss Apologies, I just answered what Ilya answered but I'd like to see this discussion ... where is this happening? Thanks a lot and send even off thread if you can. On Sat, Oct 26, 2013 at 2:10 PM, François REMY francois.remy@outlook.com wrote: I can’t help but repeat, what you describe is called an app package format. Windows 8 has one, Chrome has one, Firefox OS has one; others may have one, too. There are discussions about a standardized app package format going on, but they are not happening on es-discuss. Why do you think this discussion belongs to es-discuss? Did I miss something? De : Andrea Giammarchi Envoyé : samedi 26 octobre 2013 22:15 À : 'Ilya Grigorik' Cc : es-discuss Is it possible to not put HTTP in the middle of your thoughts? Why is **non HTTP** bundling a no go? Don't you donwload a single blob to install chrome and then eventually have incremental updates? Why that single blob at the beginning should not be possible only in JS since every other programming langauge has one and working without HTTP in the middle? Without servers? Without an internet connection ? Thanks On Fri, Oct 25, 2013 at 8:39 PM, Ilya Grigorik igrigo...@gmail.com wrote: On Fri, Oct 25, 2013 at 12:17 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Ilya ... just to re-clarify what was the discussion about: Generic Bundling ... not HTTP Bundling. I don't know why many keep coupling and confining HTML5 over HTTP and nothing else. Bundling as you do with executables or apps, bundling as you send a single file update for your customer to replace instead of unzipping, overwriting each file, etcetera. Why is in your opinion bundling bad for non HTTP, offline, apps created using these technologies ? Every programming language I know have some bundle support that works as single package/file ... C has the executable, then we have phar, war, jar, python has many ... what about JS ? Won't work without HTTP ? Why ? I'm not saying it won't work. I'm saying there are many downsides to distributing large blobs of data. Case in point, once you start distributing large blobs, you'll soon realize that it sucks that you have to download the entire blob every time a single byte has changed. As a result, you end up developing binary-diff formats.. like Courgette [1] that we use to update Chrome. A much simpler solution for web apps is to do exactly what AppCache did, create a manifest which lists all the resources, and let HTTP do the rest: each file can be downloaded and updated individually, etc. ig [1] http://www.chromium.org/developers/design-documents/software-updates-courgette On Thu, Oct 24, 2013 at 11:17 PM, Ilya Grigorik igrigo...@gmail.com wrote: + 1 to François's comments. You're not saying that gzipping and wise pre-fetching and parallel download of scripts don't improve page load times. Or are you? - We already have transfer-encoding in HTTP, and yes, you should definitely use it! - Prefetching is also an important optimization, but in the context of this discussion (bundling), it's an orthogonal concern. In the equation you paint above something important is missing: the fact that there's a round-trip delay per request (even with http2.0), and that the only way to avoid it is to bundle things, as in .zip bundling, to minimize the (number of requests and thus the) impact of latencies. With HTTP 1.x (and without sharding) you can fetch up to six resources in parallel. With HTTP 2.0, you can fetch as many resources as you wish in parallel. The only reason bundling exists as an optimization is to work around the limit of six parallel requests. The moment you remove that limitation, bundling is unnecessary and only hurts performance. And there's something else I think .zip bundling can provide that http2.0 can't: the guarantee that a set of files are cached by the time your script runs: with such a guarantee you could do synchronous module require()s, à la node.js. This is completely orthogonal... if you need to express dependencies between multiple resources, use a loader script, or better.. look into using upcoming promise API's. As I mentioned previously, bundling breaks streaming / incremental execution / prioritization. ig ___ es-discuss mailing list es-discuss@mozilla.org
Re: Proposal to simplify Generators impact
Rick: I understand. But it is always a trade-off.
If the reason to introduce a new construct is because there may already be
code that defines a function called `yield`, it seems to me as a bad
trade-off. (advantages vs disadvantages)
In your example...
function yield() {... - will raise a parsing error.
Anyway, there are other ways to solve that.
You can put the asterisk in yield instead of the important function.
It's a lot less confusing.
function fibonacci() {
let [prev, curr] = [0, 1];
for (;;) {
[prev, curr] = [curr, prev + curr];
yield*(curr);
}
}
On Sat, Oct 26, 2013 at 4:08 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Sat, Oct 26, 2013 at 1:01 PM, Lucio Tato luciot...@gmail.com wrote:
It's really needed to make js syntax more complex in order to implement
generators?
It's function* really needed?
Yes, because `yield` is only reserved in strict mode code, which means
this is valid today:
function g() { yield = 1; return yield; }
Since the starred generator function is a new syntactic form, there is no
existing code that it can possibly break by making yield a keyword.
can you just expose Generator as a core function?
can yield be a function-call-like-construct instead of a new language
construction?
No, because there may already be code that defines a function called
`yield`, which would be broken if suddenly yield was a special
language-owned function. Consider this:
// your code defines this...
function yield() { return Number.MAX_VALUE; }
// you then include my library, which exposes this fibonacci():
function fibonacci() {
let [prev, curr] = [0, 1];
for (;;) {
[prev, curr] = [curr, prev + curr];
yield(curr);
}}
What does yield() do? It returns Number.MAX_VALUE every time.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal to simplify Generators impact
Another reason: you can’t have empty generators without marking them in some manner. On Sat, Oct 26, 2013 at 1:01 PM, Lucio Tato luciot...@gmail.com wrote: It's really needed to make js syntax more complex in order to implement generators? It's function* really needed? -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal to simplify Generators impact
On Sun, Oct 27, 2013 at 1:59 AM, Lucio Tato luciot...@gmail.com wrote: yield*(curr); Note that, in difference to `function* foo`, that is valid ES5. In fact, I bet there is real code along the lines of `yield*(time - offset)` out there. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal to simplify Generators impact
Yup.
Look (Licio), we've been over this many times, recorded here in
es-discuss (directly in posts and in TC39 meeting notes). We are not
adding generator syntax lightly. It is necessary to preserve backward
compatibility.
/be
Till Schneidereit mailto:t...@tillschneidereit.net
October 26, 2013 8:19 PM
On Sun, Oct 27, 2013 at 1:59 AM, Lucio Tato luciot...@gmail.com
mailto:luciot...@gmail.com wrote:
yield*(curr);
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Lucio Tato mailto:luciot...@gmail.com
October 26, 2013 7:59 PM
Rick: I understand. But it is always a trade-off.
If the reason to introduce a new construct is because there may
already be code that defines a function called `yield`, it seems to me
as a bad trade-off. (advantages vs disadvantages)
In your example...
function yield() {... - will raise a parsing error.
Anyway, there are other ways to solve that.
You can put the asterisk in yield instead of the important
function. It's a lot less confusing.
function fibonacci() {
let [prev, curr] = [0, 1];
for (;;) {
[prev, curr] = [curr, prev + curr];
yield*(curr);
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Rick Waldron mailto:waldron.r...@gmail.com
October 26, 2013 3:08 PM
On Sat, Oct 26, 2013 at 1:01 PM, Lucio Tato luciot...@gmail.com
mailto:luciot...@gmail.com wrote:
It's really needed to make js syntax more complex in order to
implement generators?
It's function* really needed?
Yes, because `yield` is only reserved in strict mode code, which means
this is valid today:
function g() { yield = 1; return yield; }
Since the starred generator function is a new syntactic form, there is
no existing code that it can possibly break by making yield a keyword.
can you just expose Generator as a core function?
can yield be a function-call-like-construct instead of a new
language construction?
No, because there may already be code that defines a function called
`yield`, which would be broken if suddenly yield was a special
language-owned function. Consider this:
// your code defines this...
function yield() { return Number.MAX_VALUE; }
// you then include my library, which exposes this fibonacci():
function fibonacci() {
let [prev, curr] = [0, 1];
for (;;) {
[prev, curr] = [curr, prev + curr];
yield(curr);
}
}
What does yield() do? It returns Number.MAX_VALUE every time.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Lucio Tato mailto:luciot...@gmail.com
October 26, 2013 1:01 PM
It's really needed to make js syntax more complex in order to
implement generators?
It's function* really needed?
can you just expose Generator as a core function?
can yield be a function-call-like-construct instead of a new
language construction?
function fibonacci() {
let [prev, curr] = [0, 1];
for (;;) {
[prev, curr] = [curr, prev + curr];
yield(curr);
}
}
Generators can be iterated over in loops:
for (n of new Generator(fibonacci) {
// truncate the sequence at 1000
if (n 1000)
break;
print(n);
}
Generators are iterators:
let seq = new Generator(fibonacci);
print(seq.next()); // 1
print(seq.next()); // 2
print(seq.next()); // 3
print(seq.next()); // 5
print(seq.next()); // 8
Advantages: No new syntax, no function* (Cognitive dissonance, every
good C programmer can't stop reading function* as function pointer).
No yield new construction. No added complexity to the language syntax.
By not adding new elements and complexity to the language, you're
keeping it consistent.
By using new Generator(fn) to create a Object-Generator, you can
also expose a done property and other useful info in a standard way.
Note: why yield syntax should be like a function call:
In actual implementations (V8 --harmony) yield will return the
value passed in the call to .next
functiongiveNext(){//generator
letactual=10;
while(actual100){
skip=yield(actual);
actual=actual+skip||5;
};
};
letseq=newGenerator(giveNext);
print(seq.next());// 10
print(seq.next());// 15
print(seq.next(20));// 35
print(seq.next());/// 40
//
/*let*seq=newGenerator(giveNext);
while (!seq.done)
print(seq.next());
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Proposal for new floating point and integer data types
I've seen posts asking for optional strong typing (often relating to
typescript), but not many asking for data types. I think since the process
takes a while it would be a good idea to consider adding extra data types on
top of the already existing dynamic ones. I'll keep each comment short since
everyone here is probably familiar with how Actionscript did their type specs.
I'd like to discuss proposing these data types to start:
int,int8/16/32/64
uint,uint8/16/32/64
single (32-bit IEEE 754)
double (64-bit IEEE 754 as an alias for Number)
These correspond to most computer hardware and have fairly standard instruction
set operations on them. The goal here is mostly to bring ECMAScript closer to a
generic bit based computer. These types are fairly standard across hardware and
are well understood in other languages.
var foo: uint16 = 100;
var bar: uint64 = foo;
var baz = bar 58;
This would in turn expand things that JavaScript was never able to do, which is
to work with 64-bit types. (The idea being this could be expanded later for
higher bit types).
This would translate to functions:
function Foo(a: int32, b: int32): int32
{
return a + b;
}
var foo = new function(): void { }
Then expanding more, users would be allowed to type functions making function
parameters easy to understand:
function Foo(a: function(a: int32, b: int32): int32): void
{
}
Other type specifications allowed would be bool, string, and object with the
concept that classes would fit seamlessly into the typing when added later.
Some specific rules would be applied. Integer data types would not throw
exceptions when overflowing keeping them simple. Any binary operation would
immediately convert a single and double type to corresponding uint32 and uint64
data types.
The untyped Number data type would convert to any of the other types if
possible. It would be up to the programmer to ensure a Number variable fits
into the required data type.
var foo = 1000;
var bar: uint8 = foo; // 232
However a programmer could explicitly convert the type with the following
syntax:
var foo = (10 * 100): uint8;
This proposal would also include changes to Array, Map, and Set with a generic
type syntax found in C#:
var foo = new Arrayint8(100); // Identical to Int8Array
var foo = new Arraystring, int8();
var foo = new Mapint32,object();
var foo = new Setobject();
It would work as one would expect only accepting a specifically defined type.
int and uint would correspond to big integer data types which would remove any
current limitation with integer based math. they would support syntax for typed
array like views.
var foo: uint = 9;
var bar: Arrayuint8 = foo;
var baz: uint8 = bar[0];
These views would also work with the non-big integer types. So:
var foo: uint32 = 42;
var bar: Arrayuint16 = foo;
var baz: uint16 = foo[0];
They would also be the only way to go from an uint32/64 and int32/64 to a
single or double like:
var foo: uint32 = 42;
var bar: single = (foo: Arraysingle)[0];
While more verbose than other possible proposals it keeps with one syntax for
all bitwise conversions.
The last edge case I'd like to cover is making the changes work with Math:
var foo: uint32 = 42;
var bar: single = Math.cos((foo * 42):double);
By default the return type would be inferred by the input type or storage type
(in this case single) and the function would be overloaded for different
inputs. As another example Math.min and Math.max would return their input data
type rather than Number when the types are specified.
Benefits to this proposal would be easier optimization to map to hardware and
operators. It would also help to alleviate the issues that caused the need for
the TypeArray spec. That is allowing the user to work with types that map to
native hardware on the CPU and GPU.
For developers who work with binary formats this simplifies the usage of
integer and floats along with their respective binary operators.
The main issue I see is that big integers are niche so it might be a bit naive
to include them, but it's something I'd prefer was included as it makes the
language flexible for the future. The other issue is defining any type of
generic syntax using would need serious discussion if there are any issues
making the system compatible.
Future additions this would allow would be function overloading, but I left
that out as it complicates the proposal.
I've been looking through the archive for similar discussions as I assume
something like this has been proposed before. If anyone has any related links
that would be appreciated along with a discussion of issues or compatibility
conflicts. (Or general feelings toward adding types in general as ECMAscript
has been fairly unchanged over the years with regards to types).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Working with grapheme clusters
On Oct 26, 2013, at 5:39 , Bjoern Hoehrmann derhoe...@gmx.net wrote: * Norbert Lindenberg wrote: On Oct 25, 2013, at 18:35 , Jason Orendorff jason.orendo...@gmail.com wrote: UTF-16 is designed so that you can search based on code units alone, without computing boundaries. RegExp searches fall in this category. Not if the RegExp is case insensitive, or uses a character class, or ., or a quantifier - these all require looking at code points rather than UTF-16 code units in order to support the full Unicode character set. If you have a regular expression over an alphabet like Unicode scalar values it is easy to turn it into an equivalent regular expression over an alphabet like UTF-16 code units. I have written a Perl module that does it for UTF-8, http://search.cpan.org/dist/Unicode-SetAutomaton/; Russ Cox's http://swtch.com/~rsc/regexp/regexp3.html#step3 is a popular implementation. In effect it is still as though the implementation used Unicode scalar values, but that would be true of any implementation. It is much harder to implement something like this for other encodings like UTF-7 and Punycode. It is useful to keep in mind features like character classes are just syntactic sugar and can be decomposed into regular expression primitives like a choice listing each member of the character class as literal. The `.` is just a large character class, and flags like //i just transform parts of an expression where /a/i becomes something more like /a|A/. OK, if Jason's comment was meant to say that RegExp searches specified based on code points can be implemented through an equivalent search based on code units, then that's correct. I was assuming that we're discussing API design, and requiring developers to provide those equivalent UTF-16 based regular expressions (as the current RegExp design does) is a recipe for breakage whenever supplementary characters are involved. Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal to simplify Generators impact
On Oct 26, 2013, at 4:59 PM, Lucio Tato luciot...@gmail.com wrote:
Rick: I understand. But it is always a trade-off.
If the reason to introduce a new construct is because there may already be
code that defines a function called `yield`, it seems to me as a bad
trade-off. (advantages vs disadvantages)
In your example...
function yield() {... - will raise a parsing error.
You can’t make yield a reserved word — which is what you’re asking for here.
This isn’t a matter of whether or not you use generators, it’s a matter of
whether other code in the same environment ever uses a property named yield.
All of the options necessarily require breaking yield in existing code
Anyway, there are other ways to solve that.
You can put the asterisk in yield instead of the important function. It's
a lot less confusing.
function fibonacci() {
let [prev, curr] = [0, 1];
for (;;) {
[prev, curr] = [curr, prev + curr];
yield*(curr);
This already parses a (yield)*(curr)
Please stop trying to get rid of the *, there isn’t any other viable option,
and this has been covered ad nauseum on es-discuss
—Oliver___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Working with grapheme clusters
On Oct 26, 2013, at 6:58 , Jason Orendorff jason.orendo...@gmail.com wrote:
On Fri, Oct 25, 2013 at 11:42 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Oct 25, 2013, at 18:35 , Jason Orendorff jason.orendo...@gmail.com
wrote:
UTF-16 is designed so that you can search based on code units
alone, without computing boundaries. RegExp searches fall in this
category.
Not if the RegExp is case insensitive, or uses a character class, or ., or
a quantifier - these all require looking at code points rather than UTF-16
code units in order to support the full Unicode character set.
I'd like to know what you have in mind regarding quantifiers though.
When I write /{2}/, I mean //, but the current code unit based RegExp will
interpret it as /\uDCA9/, which can't match any well-formed UTF-16 string.
Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for new floating point and integer data types
Sorry for the top post, but I recommend reading this:
http://wiki.ecmascript.org/doku.php?id=strawman:value_types
Rick
On Saturday, October 26, 2013, Brandon Andrews wrote:
I've seen posts asking for optional strong typing (often relating to
typescript), but not many asking for data types. I think since the process
takes a while it would be a good idea to consider adding extra data types
on top of the already existing dynamic ones. I'll keep each comment short
since everyone here is probably familiar with how Actionscript did their
type specs. I'd like to discuss proposing these data types to start:
int,int8/16/32/64
uint,uint8/16/32/64
single (32-bit IEEE 754)
double (64-bit IEEE 754 as an alias for Number)
These correspond to most computer hardware and have fairly standard
instruction set operations on them. The goal here is mostly to bring
ECMAScript closer to a generic bit based computer. These types are fairly
standard across hardware and are well understood in other languages.
var foo: uint16 = 100;
var bar: uint64 = foo;
var baz = bar 58;
This would in turn expand things that JavaScript was never able to do,
which is to work with 64-bit types. (The idea being this could be expanded
later for higher bit types).
This would translate to functions:
function Foo(a: int32, b: int32): int32
{
return a + b;
}
var foo = new function(): void { }
Then expanding more, users would be allowed to type functions making
function parameters easy to understand:
function Foo(a: function(a: int32, b: int32): int32): void
{
}
Other type specifications allowed would be bool, string, and object with
the concept that classes would fit seamlessly into the typing when added
later.
Some specific rules would be applied. Integer data types would not throw
exceptions when overflowing keeping them simple. Any binary operation would
immediately convert a single and double type to corresponding uint32 and
uint64 data types.
The untyped Number data type would convert to any of the other types if
possible. It would be up to the programmer to ensure a Number variable fits
into the required data type.
var foo = 1000;
var bar: uint8 = foo; // 232
However a programmer could explicitly convert the type with the following
syntax:
var foo = (10 * 100): uint8;
This proposal would also include changes to Array, Map, and Set with a
generic type syntax found in C#:
var foo = new Arrayint8(100); // Identical to Int8Array
var foo = new Arraystring, int8();
var foo = new Mapint32,object();
var foo = new Setobject();
It would work as one would expect only accepting a specifically defined
type.
int and uint would correspond to big integer data types which would remove
any current limitation with integer based math. they would support syntax
for typed array like views.
var foo: uint = 9;
var bar: Arrayuint8 = foo;
var baz: uint8 = bar[0];
These views would also work with the non-big integer types. So:
var foo: uint32 = 42;
var bar: Arrayuint16 = foo;
var baz: uint16 = foo[0];
They would also be the only way to go from an uint32/64 and int32/64 to a
single or double like:
var foo: uint32 = 42;
var bar: single = (foo: Arraysingle)[0];
While more verbose than other possible proposals it keeps with one syntax
for all bitwise conversions.
The last edge case I'd like to cover is making the changes work with Math:
var foo: uint32 = 42;
var bar: single = Math.cos((foo * 42):double);
By default the return type would be inferred by the input type or storage
type (in this case single) and the function would be overloaded for
different inputs. As another example Math.min and Math.max would return
their input data type rather than Number when the types are specified.
Benefits to this proposal would be easier optimization to map to hardware
and operators. It would also help to alleviate the issues that caused the
need for the TypeArray spec. That is allowing the user to work with types
that map to native hardware on the CPU and GPU.
For developers who work with binary formats this simplifies the usage of
integer and floats along with their respective binary operators.
The main issue I see is that big integers are niche so it might be a bit
naive to include them, but it's something I'd prefer was included as it
makes the language flexible for the future. The other issue is defining any
type of generic syntax using would need serious discussion if there are
any issues making the system compatible.
Future additions this would allow would be function overloading, but I
left that out as it complicates the proposal.
I've been looking through the archive for similar discussions as I assume
something like this has been proposed before. If anyone has any related
links that would be appreciated along with a discussion of issues or
compatibility conflicts. (Or general feelings toward adding types in
general as
RE: Proposal for new floating point and integer data types
Also http://www.slideshare.net/BrendanEich/js-resp/5, presented in convenient
video form at http://www.youtube.com/watch?v=IXIkTrq3Rgg.
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Rick
Waldron
Sent: Sunday, October 27, 2013 00:06
To: Brandon Andrews
Cc: es-discuss@mozilla.org
Subject: Re: Proposal for new floating point and integer data types
Sorry for the top post, but I recommend reading this:
http://wiki.ecmascript.org/doku.php?id=strawman:value_types
Rick
On Saturday, October 26, 2013, Brandon Andrews wrote:
I've seen posts asking for optional strong typing (often relating to
typescript), but not many asking for data types. I think since the process
takes a while it would be a good idea to consider adding extra data types on
top of the already existing dynamic ones. I'll keep each comment short since
everyone here is probably familiar with how Actionscript did their type specs.
I'd like to discuss proposing these data types to start:
int,int8/16/32/64
uint,uint8/16/32/64
single (32-bit IEEE 754)
double (64-bit IEEE 754 as an alias for Number)
These correspond to most computer hardware and have fairly standard instruction
set operations on them. The goal here is mostly to bring ECMAScript closer to a
generic bit based computer. These types are fairly standard across hardware and
are well understood in other languages.
var foo: uint16 = 100;
var bar: uint64 = foo;
var baz = bar 58;
This would in turn expand things that JavaScript was never able to do, which is
to work with 64-bit types. (The idea being this could be expanded later for
higher bit types).
This would translate to functions:
function Foo(a: int32, b: int32): int32
{
return a + b;
}
var foo = new function(): void { }
Then expanding more, users would be allowed to type functions making function
parameters easy to understand:
function Foo(a: function(a: int32, b: int32): int32): void
{
}
Other type specifications allowed would be bool, string, and object with the
concept that classes would fit seamlessly into the typing when added later.
Some specific rules would be applied. Integer data types would not throw
exceptions when overflowing keeping them simple. Any binary operation would
immediately convert a single and double type to corresponding uint32 and uint64
data types.
The untyped Number data type would convert to any of the other types if
possible. It would be up to the programmer to ensure a Number variable fits
into the required data type.
var foo = 1000;
var bar: uint8 = foo; // 232
However a programmer could explicitly convert the type with the following
syntax:
var foo = (10 * 100): uint8;
This proposal would also include changes to Array, Map, and Set with a generic
type syntax found in C#:
var foo = new Arrayint8(100); // Identical to Int8Array
var foo = new Arraystring, int8();
var foo = new Mapint32,object();
var foo = new Setobject();
It would work as one would expect only accepting a specifically defined type.
int and uint would correspond to big integer data types which would remove any
current limitation with integer based math. they would support syntax for typed
array like views.
var foo: uint = 9;
var bar: Arrayuint8 = foo;
var baz: uint8 = bar[0];
These views would also work with the non-big integer types. So:
var foo: uint32 = 42;
var bar: Arrayuint16 = foo;
var baz: uint16 = foo[0];
They would also be the only way to go from an uint32/64 and int32/64 to a
single or double like:
var foo: uint32 = 42;
var bar: single = (foo: Arraysingle)[0];
While more verbose than other possible proposals it keeps with one syntax for
all bitwise conversions.
The last edge case I'd like to cover is making the changes work with Math:
var foo: uint32 = 42;
var bar: single = Math.cos((foo * 42):double);
By default the return type would be inferred by the input type or storage type
(in this case single) and the function would be overloaded for different
inputs. As another example Math.min and Math.max would return their input data
type rather than Number when the types are specified.
Benefits to this proposal would be easier optimization to map to hardware and
operators. It would also help to alleviate the issues that caused the need for
the TypeArray spec. That is allowing the user to work with types that map to
native hardware on the CPU and GPU.
For developers who work with binary formats this simplifies the usage of
integer and floats along with their respective binary operators.
The main issue I see is that big integers are niche so it might be a bit naive
to include them, but it's something I'd prefer was included as it makes the
language flexible for the future. The other issue is defining any type of
generic syntax using would need serious discussion if there are any issues
making the system compatible.
Future additions this would allow would be function overloading, but I left
that out as it
