Re: New Promise Syntax Proposal
Yes, I’ll be happy to provide a concrete example.
Let’s say I am creating a CLI using readline.
```js
const readline = require('readline');
const interface = readline.createInterface({
input: process.stdin,
output: process.stdout
});
async function run() {
var name = '';
var base = 0;
console.log('** Bienvenido al Calculador de Área **');
name = await requestInput(‘What’s your name?\n');
console.log(`Hello, ${name}!`);
}
function requestInput(question) {
return new Promise(function(resolve) {
interface.question(question, function(input) {
resolve(input);
})
})
}
run();
```
Instead of defining a wrapper function that returns a promise, I would like to
define the promise at the same time like this:
```js
const readline = require('readline');
const interface = readline.createInterface({
input: process.stdin,
output: process.stdout
});
async function run() {
console.log('** Bienvenido al Calculador de Área **');
const name = await requestInput(‘What’s your name?\n');
console.log(`Hello, ${name}!`);
}
promise requestInput(resolve, reject, question) {
interface.question(question, function(input) {
resolve(input);
})
}
run();
```
__
Jorge Téllez
+52 1 81 2567 8257
@novohispano <http://twitter.com/novohispano>
> On Nov 6, 2017, at 9:33 AM, Jonathan Barronville <jonat...@belairlabs.com>
> wrote:
>
> From the example provided, as someone who uses promises a lot, I’m not sure
> I’m sold on the need for this either. Maybe you could provide some more
> concrete examples, Jorge?
>
>
> P.S. Proposals like this are why JavaScript should’ve been a LISP ;p …
>
> On Mon, Nov 6, 2017 at 10:28 AM, Isiah Meadows <isiahmead...@gmail.com
> <mailto:isiahmead...@gmail.com>> wrote:
> I'm not convinced of the need. Promises are already sufficient, and in
> general use, I rarely use the constructor outside of adapting
> callback-related code or other lower-level cases.
>
> Also, keep in mind, most such promise-returning functions do have arguments,
> which this proposal seems to miss.
>
>
> On Mon, Nov 6, 2017, 10:23 Jorge Téllez <novohisp...@gmail.com
> <mailto:novohisp...@gmail.com>> wrote:
> I would like to propose a new syntax for promises for the next ECMAScript.
>
> It is common to define promises in the following way:
>
> function promiseFunction() {
> return new Promise(resolve, reject) {
> resolve(someValue);
> };
> }
>
> In the previous example, I am declaring a function so that I can access the
> promise throughout.
>
> I would like propose a simpler syntax to remove this redundancy:
>
> promise promiseFunction(resolve, reject) {
> resolve(someValue);
> }
>
> This will make the promise declaration easier to read in a similar fashion as
> the new class syntax made it easier to declare prototypes.
>
> __
> Jorge Téllez
> +52 1 81 2567 8257 <tel:+52%201%2081%202567%208257>
> @novohispano <http://twitter.com/novohispano>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
>
> --
> - Jonathan
>
> —
>
> Life is a game and we’re all just high density pixels.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
New Promise Syntax Proposal
I would like to propose a new syntax for promises for the next ECMAScript.
It is common to define promises in the following way:
function promiseFunction() {
return new Promise(resolve, reject) {
resolve(someValue);
};
}
In the previous example, I am declaring a function so that I can access the
promise throughout.
I would like propose a simpler syntax to remove this redundancy:
promise promiseFunction(resolve, reject) {
resolve(someValue);
}
This will make the promise declaration easier to read in a similar fashion as
the new class syntax made it easier to declare prototypes.
__
Jorge Téllez
+52 1 81 2567 8257
@novohispano <http://twitter.com/novohispano>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: for statement with index and value
Unless you have a specific requirement I am missing, your use case is more
elegantly resolved IMO using a custom generator that yields exactly the
information you need per iteration.
A functional approach using a function that has the information you need is
also another valid solution.
div 元のメール /divdiv送信元： Tingan Ho tinga...@gmail.com
/divdiv日時:2015/07/14 PM1:32 (GMT+09:00) /divdiv宛先： Edwin Reynoso
eor...@gmail.com /divdivCc： es-discuss es-discuss@mozilla.org
/divdiv件名: Re: for statement with index and value /divdiv
/divYes the proposed syntax is a special case for arrays.
tis 14 juli 2015 kl 12:23 skrev Edwin Reynoso eor...@gmail.com:
Something wrong with server that doesn't let me edit.
But what I meant by the first code snippet was:
```JS
for(let a, b of new Set([1,2])) // what would `a` and `b` be here? How would it
know what to extract??
```
Would `b` just be `undefined`, yet for an array it returns the `index` how does
it determine that unless again this is special to Arrays?? because `b/index`
could be anything else, that's not obvious compare to destructuring.
On Tue, Jul 14, 2015 at 12:13 AM, Edwin Reynoso eor...@gmail.com wrote:
So I'm assuming this would be special to arrays??
because destructuring works fine for anything that's iterable:
meaning how would it know what to take out for Sets??
```JS
for(let value, index of [1,2]) {
// do something
}
```
With destructuring we at least know what's being extracted (not sure if
destructured would be the right word, clueless on that):
```JS
let it = [1,2].entries();
let [index, value] = it.next();
// same as:
let [index, value] = [0, 1];
// the matching is obvious
```
With your suggestion it's not obvious:
```JS
for(let value, index of [1,2]) // how does it know what value and index would
be??
```
I don't think this would be done if it's only for Arrays.
On Tue, Jul 14, 2015 at 12:04 AM, Tingan Ho tinga...@gmail.com wrote:
Unfortunately we can't have both...
```
for (let [index, value] of values){
```
I was suggesting the syntax:
```
for (let value, index of values){
```
`value` comes first and no `[ ... ]`.
On Tue, Jul 14, 2015 at 11:52 AM, Logan Smyth loganfsm...@gmail.com wrote:
Unfortunately we can't have both
```
for (let value of values){
```
and
```
for (let [index, value] of values){
```
Over all, the first one is the more likely one on a day-to-day basis.
The `[]` are needed because the `for...of` follows the standard rules for
assignment, so it uses standard destructuring, and JS array destructuring
requires `[]`.
```
for (let [index, value] of values.entries()){
```
is essentially is the same as
```
for (let pair of values.entries()){
let [index, value] = pair;
```
As for your last question, `.entries` returns an iterator, so it will not
create a copy of the array.
On Mon, Jul 13, 2015 at 7:43 PM, Tingan Ho tinga...@gmail.com wrote:
for (let [index, value] of [1, 2, 3].entries())
console.log(index + : + value)
I still think most people will write:
```
for (let value of values) { ... }
```
and then rewrite the whole expression inside the `for-loop` when they find out
that they need the index too:
```
for (let [index, value] of [1, 2, 3].entries())
console.log(index + : + value)
```
`for (let value, index of values) { ... }` is still much easier to type than
`for (let [index, value] of [1, 2, 3].entries())` and also more readable.
Also, doesn't that makes a copy of the `[1, 2, 3]`?
--
Sincerely,
Tingan Ho
@tingan87
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sincerely,
Tingan Ho
@tingan87
___
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: How to fix the `class` keyword
On 04/03/2015, at 20:13, Matthew Robb wrote:
Making the following two things no longer interchangeable completely breaks
my mental model for JS:
```
var x = new X;
```
and
```
var x = {}; X.call(x);
```
This has never been the same and it isn't interchangeable. In one case the
prototype is X.prototype and in the other it's Object.prototype.
Have you never seen this line in constructors?
if ( !( this instanceof X ) ) return new X(a.copy.of.the.arguments.goes.here);
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How to fix the `class` keyword
On 04/03/2015, at 20:17, Matthew Robb wrote: Sorry this should have read: ``` var x = Object.create(X.prototype); X.call(x); ``` Ooops, too late, sorry... :-P -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign and inherited properties
On 27/02/2015, at 16:16, Andri Möll wrote:
because every object inherits from Object.prototype
[ {} instanceof Object, Object.create(null) instanceof Object ]
- [true, false]
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
04+05 vs 040+050
$ node 04+05 9 040+050 72 Is that right? Isn't it a bit of a mess/wtf? Is it going to stay so in the future? Thank you, -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On 30/01/2014, at 17:13, Brendan Eich wrote:
John Barton wrote:
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x)
{...} is a block. An unbraced consequent is not a block, and you
can't have a conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
I'm with John: the alert should say 0 and I can't see why that is not
obvious.
Interesting!
You don't want the alert to show undefined, so the extent of the inner
binding in your model is the unbraced consequent of the if.
That is not block scope in any plain sense.
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
On 31/01/2014, at 03:11, Brendan Eich wrote:
OMG LETS MAKE USELESS LETS EVERYWHERE LOLJSSUXZ0RZ! Um, no.
:-)
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 25/10/2013, at 08:17, Ilya Grigorik wrote: 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. The ability to ask for n files in a *single* request is key, yes. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 24/10/2013, at 17:06, François REMY wrote: HTTP 2.0 can send you multiple files in parallel on the same connection: that way you don't pay (1) the TCP's Slow Start cost, (2) the HTTPS handshake and (3) the cookie/useragent/... headers cost. Doesn't connection:keep-alive deal with (1) and (2) nicely? Under HTTP 2.0, you can also ask for the next files while you receive the current one (or send them by batch), and that reduces the RTT cost to 0. Http2.0 doesn't (and can't) fix the 1 RTT per request cost: it's just like http1.1. If http2.0 lets me ask for n files in a single request then yes, the RTT would be ˜ 1, or 1/n per request if you will, which is just like asking for a .zip in http1.1 Also, the server can decide to send you a list of files you didn't request (à la ZIP), making totally unnecessary for your site to ask for the files to preload them. Can a server always know what the page is going to need next... beforehand? Easily? The priority of downloads is negotiated between the browser and the server, and not dependent on the 6 connections and the client. Yes, that sounds great! The big advantage of the HTTP2 solution over the ZIP is that your site could already load with only the most important files downloaded while if you use a ZIP you've to wait until all files have been downloaded. 1.- Bundle *wisely* 2.- n gzipped files multiplexed in a single http2.0 connection don't necessarily arrive faster than the same files .zipped through a non-multiplexed http1.1 connection: multiplexing has an overhead (at both ends) that http1.1 hasn't. 3.- Yes, you can't (you can, but shouldn't until you've got the index which comes last) unzip a .zip as it arrives, but knowing for sure that all its files are cached (after unzipping) is a plus, imo. 4.- It's not http2.0 *or* .zip bundling. We could have both. Why not? From a performance point of view, this is an issue. Also, since you can only start analyzing the resources at that time, you will overload the CPU at that time. If you can unzip the files one by one, you can spread the load over a much longer time. Overload the cpu? :-P ± 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. Go find some HTTP2 presentation, you'll learn things ;-) Look, I've done it, I♥it, it's awesome, and I keep thinking that .zip bundling would be a nice thing to have too. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 24/10/2013, at 04:17, Ilya Grigorik wrote: Hey all. Late to the discussion here, but after scanning the thread, figured it might be worth sharing a few observations... The fact that we have to bundle files at the application layer is an unfortunate limitation of HTTP 1.x protocol. Specifically, because HTTP 1.x forces us to serializes responses (actually, in practice it also forces us to serializes requests on the client since pipelining adoption has effectively failed), it means we can have up to 6 parallel transfers per origin * number of origins (aka, domain sharding). This sucks at multiple levels.. it adds unnecessary complexity to our build/deploy steps (e.g. try explaining sprites to any designer...), and it also *hurts* performance in many cases. For details on cost/benefits of pipelining, sharding, concatenation: - http://chimera.labs.oreilly.com/books/123000545/ch11.html#HTTP11_MULTIPLE_CONNECTIONS - http://chimera.labs.oreilly.com/books/123000545/ch11.html#_domain_sharding - http://chimera.labs.oreilly.com/books/123000545/ch11.html#CONCATENATION_SPRITING As noted in last link, concatenating large bundles is actually *the opposite* of what you want to do for performance: a) we want to deliver small, granular resources, such that they can be cached, invalidated, and updated individually b) small resources allow incremental processing and execution c) small resources map to modular code and better prioritization (e.g. I need this submodule only after X operation or in Y view, etc) In practice, (a) is a serious problem for many large sites already.. every rev of their JS / CSS bundle results in a massive (and mostly unnecessary update) - case in point, GMail team has spent an enormous amount of cycles trying to figure out how to scale this process without running a self-imposed DoS attack every time their JS asset is rev'ed (plus doing so in an efficient way for users on slow connections). Similarly, in our Google PageSpeed libraries we've dropped the concatenate all things strategy several years ago after we realized that it hurts perceived performance: instead we merge small files into large bundles (up to 30-50kb in size) -- even this is annoying and ideally unnecessary, and we recommend disabling all spriting / concat logic when running over SPDY. Long story short: we don't want large bundles. Also, large bundles break prioritization! To deliver good performance we want modular assets with different priority levels. This is exactly why we're working on ResourcePriorities spec: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html. Merging multiple files into a single blob, or a zip, breaks this model and makes the situation even worse: a) a single byte update on any part of the bundle would force downloading the entire blob ($$$, slow for clients on slower connections, low cache hit rates) b) streaming sub-resources from a bundle is at best complicated, and in the worst case completely broken, which only makes the performance story even worse c) the entire bundle is delivered with a single priority level In short, pitching zip bundling as a performance optimization is a complete misnomer. If anything, it will only make things worse, even for HTTP 1.x clients. And with HTTP 2.0 on near horizon, the limitation in number of requests is completely removed: we have full multiplexing, prioritization, flow control.. which is exactly where we want to go if we want to accelerate page load times. ig P.S. HTTP 2 recommendations: http://chimera.labs.oreilly.com/books/123000545/ch13.html#_removing_1_x_optimizations Hi, You're not saying that gzipping and wise pre-fetching and parallel download of scripts don't improve page load times. Or are you? 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. 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. Cheers, -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 13/10/2013, at 21:34, Brendan Eich wrote:
Jorge Chamorro wrote:
Are main.js and assets.zip two separate files, or is main.js expected to
come from into assets.zip?
The latter.
I think the latter would be best because it would guarantee that the assets
are there by the time main.js runs, as if they were local files, ready to be
require()d synchronously.
How would old browsers cope, though? They would load only lib/main.js (and
possibly make a request storm, as Russell brought out elsewhere in this
thread), so (synchronous) require of another member of assets.zip might or
might not work.
Exactly.
The only 'fix' that I can think of is to use sync XHRs (I know, I know...). For
example this code would run fine in any browser, with or without .zip packages:
```
function require (modulo) {
if (!require.modulos) {
require.modulos= Object.create(null);
}
if (!(modulo in require.modulos)) {
var xhr= new XMLHttpRequest();
xhr.open('GET', modulo, false);
xhr.send();
require.modulos[modulo]= Function('require', xhr.responseText)(require);
}
return require.modulos[modulo];
}
require('js/main.js');
```
Only much slower in old browsers, but lightning fast with .zip packages (if you
choose wisely what you put into the .zip package).
A prefetching link element might not suffice in old browsers, I'm pretty
sure it won't.
If the only way to cope with downrev browsers is to use Traceur, so be it. We
just need to be sure we're not missing some clever alternative.
I for one don't have any better ideas, sorry.
Thank you,
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 14/10/2013, at 17:20, David Bruant wrote: How much are we trying to save with the bundling proposal? 200ms? 300ms? Is it really worth it? I feels like we're trying to solve a first-world problem. I think that the savings depend very much on the latency. For example from where I am to Brazil the latency (round-trip) is almost 500 ms, so if I could bundle 60 files in a .zip instead of requesting them in series (say at max 6 in parallel), the page would load in a little more than 500 ms instead of in 10 seconds. You can also think about it this way: the price per request with 500 ms of latency, is 500kB on a 1 megabyte per second ADSL, or 1 megabyte in a 2 megabyte/s ADSL, etc. So for 60 requests it's 30 or 60 megabytes. Yes a server could perhaps fix that for me almost transparently, but with this I could as well fix it all by myself. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 14/10/2013, at 18:47, Andrea Giammarchi wrote: IIRC roundtrip happens once per domain so your math is a bit off. Can you elaborate? I don't quite understand... Thank you, -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 14/10/2013, at 22:11, David Bruant wrote: You already can with inlining, can't you? Yes and no: -It's much more complicated than pre zipping a bunch of files and adding a ref attribute. -It requires additional logic at the server side, and more programming. -It's not trivial always: often you can't simply concatenate and expect it to work as-is (e.g. module scripts). -You might be forcing the server to build and/or gzip (á la PHP) on the fly = much more load per request. -Inlined source isn't always semantically === non-inlined source = bugs. -Etc. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 14/10/2013, at 22:27, Andrea Giammarchi wrote: AFAIK you have those 500ms delay per roundtrip, as you said, but not per domain. I am talking about mobile and radio behavior where fetching from multiple sources will result in a roundtrip mess/hell but fetching all resources from a single domain should result in a roundtrip delay only for the first file. Accordingly, avoiding multiple CDN for different external scripts might help to speed up first-contact too. I don't remember (I might look for it) who brought all these facts on the table but I remember this was practical/concrete situation 3+ years ago and I don't expect to be different today. As summary: if you have 500ms delay and 10 files, you won't have 500 * 10 ,s delay but 500 plus common network delay accordingly with your host situation so 500 + (100 * 10) considering a regular 100 ms delay I mean, still some delay, but it's not multiplied 500 ... that's what I've meant :-) You are sitting in the moon with a lamp sending signals to the earth and no matter what you do it takes more than 1 second for the light of your lamp to arrive to the earth. There is a mirror in the earth reflecting the light back to you, the round-trip will be more than 2 seconds and there's no way to fix that. What I meant with round-trip latency is: once the connection has been established, a network packet takes almost 250 ms to go from the ethernet port of my computer the the ethernet port of a server in Brazil, and another 250 ms for the response packet to come back. The only work around for that is making as few requests as possible. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 14/10/2013, at 22:11, David Bruant wrote: You already can with inlining, can't you? It would also be very interesting to know if you had .zip packing, would you be inlining? -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 11/10/2013, at 03:10, Andrea Giammarchi wrote: Last personal thought: this is way nicer than any AMD solution I've seen, giving a real alternative to async modules too via script defer/async attributes without requiring boiler plates all over to include on demand. Because all the files in the .zip would appear to be 'local', a synchronous require() can be built on top of that, and suddenly we'd have almost 100% node-style modules compatibility in browsers. Or am I missing something? -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 11/10/2013, at 03:53, Brendan Eich wrote: On Thu, Oct 10, 2013 at 8:10 PM, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote: You are confining the problem in HTTP only scenarios while the solution provided by script src=lib/main.js ref=”assets.zip”/script No, you're right -- agree with you and Andrea, this is sweet. Are main.js and assets.zip two separate files, or is main.js expected to come from into assets.zip? I think the latter would be best because it would guarantee that the assets are there by the time main.js runs, as if they were local files, ready to be require()d synchronously. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 11/10/2013, at 12:02, David Bruant wrote: Providing a zip in the manifest file could work, but I'm not sure I see the benefit over individual files. Disk fragmentation issues maybe? One benefit is that a single .zip can fetch a bunch of files in a single network round trip. Another is than once the .zip has been unzipped, its files can be accessed synchronously. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 11/10/2013, at 13:23, David Bruant wrote: Le 11/10/2013 12:46, Jorge Chamorro a écrit : On 11/10/2013, at 12:02, David Bruant wrote: Providing a zip in the manifest file could work, but I'm not sure I see the benefit over individual files. Disk fragmentation issues maybe? One benefit is that a single .zip can fetch a bunch of files in a single network round trip. The manifest file was in response to Andrea's point about packaged app (where he pointed that network requests aren't the only use case), so network round trips don't apply. Another is than once the .zip has been unzipped, its files can be accessed synchronously. If we're back on the network use case, server push has the same benefits (resource bundling and in-memory availability)... and saves a network round-trip since the resources come along! I've read/seen the links you've posted now, thank you. HTTP2.0 is awesome, but it requires resource planning a priori, and the cooperation of the server, and a server HTTP2.0 capable. Not sure if the client's http stack does need to be updated too, does it? OTOH the script src='main.js' ref='assets.zip' is a 100% client-side solution, so it would be compatible with any server of any http version. It requires a browser that implements it though, and preferably a way to feature-detect the capability, of course, so it's not perfect either. But the ability to use synchronous require()s, á la node, in a browser would be a big big big win. imho. The ref='assets.zip', it seems to me, is an easier proposition. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 11/10/2013, at 15:15, Russell Leggett wrote: Just wanted to point out a couple of previous attempts at something similar to generic bundling and the reactions it got, because so far it hasn't panned out. Way back in 2008, it was my one and only real contribution to the whatwg list before getting a little frustrated and moving on: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015411.html Brilliant, Yes! That's it! if all js,css,and even images and other files could be zipped up or tarred, that would only require a single HTTP request. This could basically just add the files to the browser cache or other local storage mechanism so that requests for the resources would not need to make an extra trip 2008? That's 5 looong years ago. Then a year later, Alex Limi independently came up with a very similar proposal: http://limi.net/articles/resource-packages/ and actually got a version of it working in some branch of firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=529208 And here's a couple of discussions on that proposal: https://groups.google.com/forum/#!topic/mozilla.dev.platform/MXeSYsawUgU http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027582.html As you can see the resource packages attempt got dropped. Perhaps this proposal will go through because it is tied to the module loader? It's sad. What happened? Why was it ditched? Was it, perhaps, too ahead of its time? Let's try again :-) -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
On 11/10/2013, at 15:53, Russell Leggett wrote: As you can see the resource packages attempt got dropped. Perhaps this proposal will go through because it is tied to the module loader? It's sad. What happened? Why was it ditched? Was it, perhaps, too ahead of its time? Let's try again :-) As you can see, it basically fell to the same conclusion as you are trying to fight right now - SPDY and html pipelining. The idea that this can be transparently handled better with http rather than a bundling approach. I appreciate the beauty in 'speedy' and http2.0, but it requires an upgrade of both ends to http2.0, all the servers and browsers in the world. We could have the .zip prefetch ref attribute operative tomorrow in the next browser update, an update which we are going to do anyway. No need to touch any server. There are many more client than server side developers, and to grasp the idea behind an assets.zip prefetch ref attribute takes just a few seconds, or perhaps a minute, no more. The word spreads, and in less than a year we'd have the web served zipped, but servers are much more complicated than that, and no two servers are programmed nor configured equal. And http2.0 and 'speedy' and all their beauty too, in the future. Why does it have to be one or the other? -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Are there any plans to introduce Date/Time literals?
On 09/10/2013, at 18:46, Oliver Hunt wrote:
function f() {
var undefined = null /* fix that silly null vs. undefined shenanigans */,
NaN = Math.sqrt(2) /* make sure nan is not rational */,
Infinity = 1000 /* this should be big enough */
}
Sheesh, fix NaN, it shouldn't be a number!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: FYI: Ecma-404 approved and published
On 08/10/2013, at 19:59, Allen Wirfs-Brock wrote: The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See http://www.ecma-international.org/publications/standards/Ecma-404.htm It provides the normative specification of the syntax of JSON Text used for data interchange. Note that it does not define any semantics for such texts. There are many such possible semantics. Actual data interchange requires agreement between a producer and consumer regarding the semantic interpretation of a JSON text. This might, for example, take the form of ad hoc agreement between a producer and consumer upon an application specific JSON schema or it might be the subject of other standards that defines a semantics for some particular use case of the Ecma-404 JSON syntax. IIUC top level values are valid JSON texts now, is that right? 4 JSON Text A JSON text is a sequence of tokens formed from Unicode code points that conforms to the JSON value grammar. The document is sublime. 14 pages of which 8 are not content. Now that's concise. I love it. The intro is, well, chapeau!. Thank you, -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: setImmediate
On 08/08/2013, at 15:55, David Bruant wrote: This is not a Trying to protect us from ourselves situation. This is a browser trying to protect users from any sort of abuse situation. For while loops, they implemented the script takes too long dialog. For mistakenly infinitely nested too short setTimeouts, they implemented 4ms clamping. If browsers can't have mitigation strategies when features are abused, we will run in the same situations than before. As a JS dev, I want the same features than you. Now, how do browsers make sure this doesn't drain users battery in case of misuse? (I don't have an answer yet) I think that it can't be avoided. A program, in the middle a longish operation, *must* yield to the event loop to avoid events starvation and/or to force redraws, so there *must* be a way to do so, and it *must* be *fast* (without 4ms clampings). Yes, there are malicious sites and there are silly programmers to drain your batteries, but there are also 100% legit reasons to spin the event loop... I would put in the browsers a cpu hog/battery drain dial/indicator per page, so that the users could at least see it and act accordingly (they'll soon learn why that's important). I for one have already uninstalled lots of iPhone apps, just because they drained my batteries too fast. Also, the original classic MacOS had an EventAvail() call to let the program know if there were any events pending, in a program in a busy loop this helps decide whether it's time to yield or not. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.last
On 28/07/2013, at 14:13, David Bruant wrote: Hi, Asked by Angus Croll [1]. Interestingly, people who answered giving code didn't agree on a method or getter. Hence the need for a standard :-) I've seen that before, somewhere, but it was .peek() not .last: [1,2].peek() 2 -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On 13/07/2013, at 01:24, Jeff Walden wrote: On 07/12/2013 04:13 PM, Tab Atkins Jr. wrote: If you don't agree with that reasoning, then I suppose you'd argue that *all* numbers 2^53 should return true, since they're all forced into being represented as integers? All numbers = 2**53 except Infinity, yes. I think isInteger implies the mathematical concept, with the only addition that it should pass -0. And while it would somewhat unfortunately diverge from the ToInteger spec operation, toInteger should imply the mathematical concept as well, and only produce values that are mathematical integers. (toInteger should probably convert -0 to -0 for consistency with isInteger on -0, but probably I could go either way here.) Everything from Math.pow(2,52) to Math.pow(2,53) are integers (if represented as IEE-754 doubles), because there's no bit left to represent Math.pow(2,-1): Math.pow(2,52) 4503599627370496 Math.pow(2,52).toString(2) 1 Math.pow(2,52).toString(2).length 53 (Math.pow(2,52)-1).toString(2) (Math.pow(2,52)-1).toString(2).length 52 Math.pow(2,52)-0.5 4503599627370495.5 Math.pow(2,52)+0.5 4503599627370496 -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On 10/07/2013, at 03:45, Brendan Eich wrote: Jorge Chamorro wrote: On 10/07/2013, at 03:23, Brendan Eich wrote: Mark S. Miller wrote: FWIW, we include 2**53 as in the contiguous range of exactly representable natural numbers. https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#492 It's exactly representable, but its representation is not exact. If that makes sense! 2**53 is exactly representable, but it gets the exact same representation as 2**53 + 1 Yes, you said that last time, and Allen said it before in the message to which you replied :-P. He, yes, I'm amazed, there's lots of fun on the edge: a = Math.pow(2,53) 9007199254740992 a === a+1 true a === a+2-1 true And my favorite: (a+1-1) === (a-1+1) false -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On 10/07/2013, at 03:23, Brendan Eich wrote: Mark S. Miller wrote: FWIW, we include 2**53 as in the contiguous range of exactly representable natural numbers. https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#492 It's exactly representable, but its representation is not exact. If that makes sense! 2**53 is exactly representable, but it gets the exact same representation as 2**53 + 1 -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On 10/07/2013, at 03:49, Mark S. Miller wrote:
I initially didn't think this mattered, but it is an excellent and important
point. Look at the use I make of Nat in Dr.SES in Figure 1 of
http://research.google.com/pubs/pub40673.html:
var makeMint = () = {
var m = WeakMap();
var makePurse = () = mint(0);
var mint = balance = {
var purse = def({
getBalance: () = balance,
makePurse: makePurse,
deposit: (amount, srcP) =
Q(srcP).then(src = {
Nat(balance + amount);
m.get(src)(Nat(amount));
balance += amount;
})
});
var decr = amount = { balance = Nat(balance - amount); };
m.set(purse, decr);
return purse;
};
return mint;
};
Because Nat includes 2**53, this code actually fails to enforce conservation
of currency!! I've repeatedly claimed this conservation property about this
code and code like it for a long time now, to many audiences and in several
papers. There have been several exercises proving some properties of this
code correct and laying the groundwork for proving conservation of currency.
However, none have previously spotted this hole.
Right, if balance+amount ever result in 2**53+1, the code would rather see it
(and save it!) as 2**53.
Sort of a new kind of off by one error... for the wikipedia?
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
IIAFEs?
Hi,
How would this:
(Function () {
// ...
})();
now look like with arrow functions?
(()={
// ...
})();
What can be left out, if anything?
Thank you,
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IIAFEs?
s/Function/function/g ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IIAFEs?
On 01/06/2013, at 23:49, Axel Rauschmayer wrote:
On Jun 1, 2013, at 14:38 , Jorge jo...@jorgechamorro.com wrote:
How would this:
(Function () {
// ...
})();
now look like with arrow functions?
(()={
// ...
})();
What can be left out, if anything?
You’ll rarely, if ever, need IIFEs with ES6, thanks to block-scoped function
declarations and for-of (which creates a fresh copy of the iteration variable
for each iteration).
Thus, instead of:
(function () {
var tmp = …;
}());
you can do:
{
let tmp = …;
}
I’d still love to have do-blocks, though.
But they're not fully interchangeable, for example I can exit a function at any
point with a return, but can I exit a block at any point with a break or
something? Also a function returns a value, does a block evaluate to something?
In any case, I would really like to know which parenthesis or curly braces can
I leave out in an immediately invocated arrow function expression, for example
this:
var x= (={
//...
})();
Is it correct ES6? Is there anything else that I could rmv in that IIAFE?
Thank you!
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Harmony modules
On 01/06/2013, at 23:57, François REMY wrote:
Arrow functions probably shouldn’t be used for this, this is not very
readable.
Yeah, arrow functions are grawlix-y per se, but I've come to admit that Brendan
(et al) was (were) right: they're going to be a Good Part™.
I think you should have a look at modules, this is what is expected to
replace this pattern ;-)
I understand node modules perfectly but everything I've seen in es-discuss
about the modules proposal was almost incomprehensible (for me). Do you know of
a harmony-modules-for-dummies doc or video that I can read/see to learn more?
:-)
How would I turn this IIFE into an inlined module?
var myModule= (()={
//...
return someThing;
})();
Also, in node the modules are read synchronously from a disk drive, how can
these new es6 modules deal with modules that have to be read from the network
when is JS there's no means for IO?
Thank you,
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IIAFEs?
On 02/06/2013, at 01:12, Axel Rauschmayer wrote:
for example I can exit a function at any point with a return, but can I exit
a block at any point with a break or something?
You can give the block a label, say, `foo` and then exit via `break foo`.
So should I break to a label *outside* the block? Like so?
{
//...
while (condition) {
//...
if (something) break resume;
//...
}
//...
}
resume:
Also a function returns a value, does a block evaluate to something?
No it doesn’t. David Herman proposed a “do expression” that would be able to
do so:
http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions
Do expressions are cool! Are they in for es6?
Thanks.
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IIAFEs?
On 02/06/2013, at 01:22, Brandon Benvie wrote:
On 6/1/2013 3:44 PM, Jorge wrote:
But they're not fully interchangeable, for example I can exit a function at
any point with a return, but can I exit a block at any point with a break or
something?
block: {
if (true) {
break block;
}
}
What might happen with this is that if you concatenate a bunch of .js files
that use this pattern, they might end redefining the same label (which would be
an error, I guess). Wrapping it all in another block would solve that?
{
block: {
if (true) {
break block;
}
}
}
But then... I'm not sure this is any better than an IIFE!
Also a function returns a value, does a block evaluate to something? In any
case, I would really like to know which parenthesis or curly braces can I
leave out in an immediately invocated arrow function expression, for example
this: var x= (={ //... })(); Is it correct ES6? Is there anything else that
I could rmv in that IIAFE? Thank you!
You can only get the return value of a block using eval.
I knew that ;-P
However you can accomplish the same task by assigning to some outside
variable.
let x;
block: {
x = 20;
// do some stuff
if (condition) {
break block;
}
x = 30;
}
But that's a bit awful, isn't it? When it's wrapped in an IIFE the code inside
the block needs to know nothing about the outside var.
Some fun stuff you can do with eval:
console.log(eval(block: { 'a'; if (Math.random() .5) break block; 'b'
}))
Cool :-)
Thanks,
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Future feedback
On 13/05/2013, at 05:37, Jonas Sicking wrote:
On Sun, May 12, 2013 at 7:31 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Moreover the page can be reflowed between tasks.
_ANY_ async solution will have this property. What does it even mean to be
async if you don't allow reflows in the meantime?
Work that is performed at end-of-microtask is sort of between fully
asynchronous and normal synchronous. Since it runs as part of the same
task it means that reflows can't happen before the end-of-microtask
work happens.
This means that you get some advantages of asynchronous code, such as
not having to worry about being in an inconsistent state due to code
higher up on the call stack being half-run. And likewise you don't
have to worry about not messing up code higher up on the callstack
which didn't expect to have things change under it.
But it also means that you are missing out of some of the advantages
of asynchronous code, such as you still have to worry about hogging
the event loop for too long and thus not processing pending UI events
from the user.
The event loops used to look ~ like this (node's nextTick used to be ===
setImmediate):
while ( RUN ) {
despatchSetImmediate();
despatchIOandGUIandTimerEvents();
if (!setImmediateQueue.length !pendingEventsSignal) sleep();
}
IIUC now node's (new) event loop looks ~ like this instead (now that nextTick
!== setImmediate):
while ( RUN ) {
despatchSetImmediate();
despatchNextTickQueue();
despatchIOandGUIandTimerEvents();
if (!setImmediateQueue.length !nextTickQueue.length
!pendingEventsSignal) sleep();
}
despatchNextTickQueue() unlike despatchSetImmediate() walks its queue entirely
(simplified pseudo code):
function despatchSetImmediate () {
var queue= setImmediateQueue;
setImmediateQueue= [];
for (var i=0 ; i queue.length ; i++) queue[i]();
}
function despatchNextTickQueue () {
for (var i=0 ; i nextTickQueue.length ; i++) nextTickQueue[i]();
nextTickQueue.length= 0;
}
If a nextTick()ed function adds further nextTick()ed functions, those newly
added functions will run in the *current* tick as well, unlike setImmediate()ed
functions, which seems to be the whole point of this modified, new event loop.
Bus this also means that if nextTicked functions call nextTick() recursively
the event loop blocks!
To solve that they've added a counter into despatchNextTickQueue() so that it
won't ever walk in a single tick more than n elements of the nextTickQueue.
Now that means that nextTick()ed functions may sometimes behave as if
setImmediate()d: you never know for sure.
To have a new event loop model that may block is a bad thing IMO, and the
let's add a counter solution isn't a good solution.
Before the mod always knew what was going to happen, now you don't.
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More flexibility in the ECMAScript part?
On 18/04/2013, at 14:40, David Bruant wrote: I believe the ES spec should provide the primitives of what type of interaction with the message queue is allowed and what isn't. This set of primitives would obviously contain all the interactions allowed today by HTML5. For now, I'm aware of only these types of interactions: 1) add a message to the queue LIFO-style (which is the default?) This isn't neccessary, 2) add a message to the queue FIFO-style also known as add for the next turn This is the only one needed, 3) remove a message (clearTimeout which cancels a message added via a setTimeout message). and this has nothing to do with the events queue. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Futures (was: Request for JSON-LD API review)
On 17/04/2013, at 17:46, Anne van Kesteren wrote: If it was up to me JavaScript would just be part of the W3C and we would not have to deal with that layer of distraction. On 17/04/2013, at 19:48, Tab Atkins Jr. wrote: I strongly support any efforts to move JS standardization into the umbrella of the W3C. The very thought of it sends chills down my spine. The w3c has demonstrated blindness and incompetence. Remember how and why the whatwg came to be? Stop pretending. You guys ought to be deeply embarrassed because HTML5 is *not* your child. Who wants a JS infested of inconvenient APIs w3c-style? -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Upcoming talk on ES6 in Russia
On 23/03/2013, at 19:41, Axel Rauschmayer wrote:
Arrow functions are a good example: A more JavaScript-y syntax would have
been `fn`:
let squares = [1,2,3].map(fn(x) { return x*x });
Or:
let squares = [1,2,3].map(fn(x) x*x);
However, due to backward compatibility that syntax wasn’t possible.
I don't think that's true: old code (that doesn't use the new syntax) would
continue to run, and new code that opts-in to es6 (using the new syntax) would
reject the (very rare) old uses of ƒ as in function ƒ(){} or var ƒ; or ƒ=xxx;,
and would allow the new forms, e.g. .map(ƒ(n) ...).
It's ~ the same case as `with` and if they really wanted it could be done, I
don't buy the it wasn't possible, no.
But as bluntly as @rwaldron put it the other day: arrows are here to stay
(full stop)... well, ok! but I for one don't like them as much.
--
(Jorge)();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Self-recursion and arrow functions
On 17/03/2013, at 10:43, Claus Reinke wrote: I understand, but it's still a limitation of arrow functions that they rely on arguments.callee to self-reference. Relying on the defined name they're assigned to suffers from the can be redefined problem. NFE's don't suffer this problem and can completely avoid `arguments` in ES6 for all use cases Arrow functions, currently, cannot. Neither arguments.callee (not available in strict) nor let (clumsy to use in expressions) are needed for self-reference var rec = (f) = f((...args)=rec(f)(...args)); var f = (self)=(n)= n1 ? n*self(n-1) : n; [1,2,3,4,5,6].map((n)=rec(f)(n)); God, my eyes, they're bleeding! Sorry arrow functions but this isn't a better JS. -- (Jorge)(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Self-recursion and arrow functions
On 17/03/2013, at 12:16, Jason Orendorff wrote: On Sun, Mar 17, 2013 at 2:43 AM, Claus Reinke claus.rei...@talk21.com wrote: Neither arguments.callee (not available in strict) nor let (clumsy to use in expressions) are needed for self-reference var rec = (f) = f((...args)=rec(f)(...args)); var f = (self)=(n)= n1 ? n*self(n-1) : n; [1,2,3,4,5,6].map((n)=rec(f)(n)); ...but then you have a function rec which self-references. Much better to use the Z combinator: f = (x = f(v = x(x)(v)))(x = f(v = x(x)(v))) which can be conveniently inlined into any expression where it's used: js [1,2,3,4,5,6].map((n)=(f = (x = f(v = x(x)(v)))(x = f(v = x(x)(v(self = n = n1 ? n*self(n-1) : n)(n)); [1, 2, 6, 24, 120, 720] Obviously this is much better than arguments.callee. :-) And I want to tear out my eyes! -- (Jorge)(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Self-recursion and arrow functions
On 17/03/2013, at 14:33, Mark S. Miller wrote:
Just in case anyone does not realize that this thread is humorous,
const factorial = n = n1 ? n*factorial(n-1) : 1;
Yes, you can't use this as an expression. So what? After this declaration you
can use factorial as an expression.
IIRC the possibility of *simply* using 'ƒ' (instead of 'function') for lambdas,
which is a syntax that's immediately familiar to any JS developer:
[1,2,3,4,5,6].map(ƒ factorial(n) { n1 ? n*factorial(n-1) : 1 });
and could also give us anonymous and named lambdas that can be used à la
'function' function:
A lambda declaration: ƒ factorial(n) { n1 ? n*factorial(n-1) : 1 }
A named lambda expression: (ƒ factorial(n) n1 ? n*factorial(n-1) : 1)(5);
Anonymous lambdas:
[1,2,3,4,5,6].map(ƒ(n) n*2); //ƒ lambdas are even shorter than arrow functions
[1,2,3,4,5,6].map((n)= n*2);
was being considered in the past, but we ended up with arrows instead. I for
one liked ƒs much more than arrows because ƒ()... looks like a function much
more than the grawlixy ()=...
Now, given that ƒs could be created named or anonymous and used as expressions
in any case, with ease, just like the regular functions can, perhaps ƒ-lambdas
may deserve a reconsideration?
Anonymous lambda expressions are a wonderful things. But in actual
development, I have never yet encountered a recursive function I didn't want
to name.
But Brandon Benvie was pointing out at the problem: Relying on the defined
name they're assigned to suffers from the can be redefined problem:
var factorial= (n)= n1 ? n*factorial(n-1) : 1;
The factorial lambda above depends on a free var to function properly which is
a hazard.
It never ocurred to me that using const instead of var/let as you've done above
fixes that, thank you!
Still, ƒ named lambdas have the advantage that can be used directly as
expressions, without going through any const roundabouts.
Ok, and now back to our irregularly scheduled humor...
--
(Jorge)();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Self-recursion and arrow functions
On 18/03/2013, at 01:49, Rick Waldron wrote:
snip
...and Brendan's point about backwards compatibility is irrefutable:
https://mail.mozilla.org/pipermail/es-discuss/2012-January/019860.html
snip
How is
ƒ fib(n) { ... }
any more backwards incompatible than
const fib = (n) = { ... };
?
--
(Jorge)();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: a future caller alternative ?
On 09/03/2013, at 00:54, Andrea Giammarchi wrote: Mark, that is an exhaustive list of links and talks but how many real use cases where we let the user inject any sort of script code in the website and we inject malicious libraries we are not aware, compared with the number of all website that would never suffer any problem with this ? Comparing Java Applets with JavaScript is a no-go, Java had privileged access to the system, nothing caller could achieve in all it's possible evil forms, neither eval could do much there. I think there are no real use cases where caller is dangerous if not few academic purpose attempts to make it safer, and you seemed to work in probably all of them ... ask devs out there how many are using those libraries. As summary, you ask us to bring real cases where caller is needed, I would do the other way around: bring real cases in the real world where caller could be such disaster because trusting user inputs and blindly include external libraries are not, again, real world use cases ... not the majority of them, am I wrong ? I see this like don't use SQKL ever because there could be SQL injections ... sense? None for me :-/ I think the key terms are cooperation under mutual suspicion, mashups, and object capability: the idea is that you'd *want* to be able to run untrusted possibly evil code side by side with your code in your page (e.g. an ad and a payment gateway). Other links: Gears and the Mashup Problem: http://www.youtube.com/watch?v=qfBL2sc2zUU/ Web Forward: http://www.youtube.com/watch?v=yh7TeoEwNyI#t=15m40s Securing JavaScript: http://www.youtube.com/watch?v=T6TTQoqln7c We'd much rather play with unloaded guns than in hopes that nobody else pulls the trigger? -- (Jorge)(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 10 biggest JS pitfalls
On 31/12/2012, at 15:55, Juan Ignacio Dopazo wrote: I'm surprised not to see Automatic Semicolon Insertion in the list. Yes I would ditch ASI altogether if only to force the javascrhipsters to put back each and every semicolon where it belongs: they are *delimiters*. No ASI would force them to stop writing in those silly -and ugly- dialects in which every now and then lines *begin* with a semicolon... As JS compiler *wants* semicolons as delimiters, instead of attempting to guess and fix buggy src code via A.S.I. which often results in failure anyway (even silent failures which is worse), it should better halt and complain loudly about syntax errors. IOW, Javascrhipster's style code is nothing but a big multi line syntax error, fixed by ASI. Happy new year! -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
On 25/11/2012, at 00:52, Brendan Eich wrote: No. You're rehashing a hypothetical worry at this point. No worries, but it's not a hypothesis that code outside a recursive FD can break it at its will. Evidence first, to get any farther. The only evidence is that sometimes yes sometimes no, functions' names are free vars. Cheers, -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
On 24/11/2012, at 07:14, Brendan Eich wrote:
Jorge Chamorro wrote:
Bind the name inside the function *too*.
That's not a compatible change, and unmotivated by any actual foot damage.
The footgun (1) is to have the name bound *only* in the outer scope.
We need evidence this is a real hazard. Otherwise you're assuming a
conclusion and using a circular argument of sorts: that lack of the inner
unwritable name binding is a problem requiring just that solution.
Yes it's a corner case.
Ok, so what's the non-corner foot-damaging case?
Programmers do intentionally replace a function's name in its scope, e.g.
to auto-memoize.
Oh, how does that work? I've written memoizers but never needed to overwrite
a name.
http://osteele.com/posts/2006/04/one-line-javascript-memoization
Works on global functions as well prototype methods.
It can be done with FDs, but all the examples are using NFEs.
The writable binding created by a function declaration? That's required by
backward compatibility (e.g. the memoization pattern).
The -outer- writable binding isn't the problem, the problem is the lack of
binding in the inner scope. Is there a reason for not having it?
Again, introducing such a binding is an incompatible change. I don't know
what it might break, but I doubt anyone wants the risk. Also there's overhead
in making such an inner binding -- another reason implementors won't go
there. Finally, you have not justified this change by any evidence it
addresses a real, observed hazard.
Sorry, but I can't help thinking that fib should be bound in FDs as in NFEs:
function fib (n) {
return (n 2) ? 1 : fib(n-2)+ fib(n-1);
}
because if not it becomes a free var meaning that any recursive FD can be
broken from the outside at any time, which does not seem to be the Right Way to
do the things.
Sounds like a WTF... one that's rarely going to bit, but a WTF nevertheless.
Don't you think so?
Cheers,
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
On 22/11/2012, at 09:38, Brendan Eich wrote: Brandon Benvie wrote: I don't know the specific reasoning behind it. I guess the idea is that a function is declared in a maximum of one scope. For the declaration it's the outer scope, for a named function expression it's a static scope that sits between the outer scope and the (during execution of the function) inner scope. Also just to clarify, the above isn't something I'm proposing. It's how things currently work. Right. I think Jorge may be concerned that naming a function does not always relieve the need for arguments.callee. But that's only true in a function declaration, which is inherently named, as you showed -- and only if one then overwrites the name in its scope. So don't do that. Fear that someone else might means you are in the global scope, which means that instead of using such a hard case to justify arguments.callee, you ought to modularize with an IIFE or (in due course) ES6 module. To clarify, I wasn't trying to justify arguments.callee. don't do that is a solution, for this and for many other WTFs and footguns... But, isn't the NFEs' way the Right Way to do it? Do we want this footgun in function declarations? Why? Is there any reason for not removing it? (Other than because it's a corner case?) Cheers, -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
On 23/11/2012, at 18:47, Brendan Eich wrote:
Jorge Chamorro wrote:
On 22/11/2012, at 09:38, Brendan Eich wrote:
Right. I think Jorge may be concerned that naming a function does not
always relieve the need for arguments.callee. But that's only true in a
function declaration, which is inherently named, as you showed -- and only
if one then overwrites the name in its scope.
So don't do that. Fear that someone else might means you are in the global
scope, which means that instead of using such a hard case to justify
arguments.callee, you ought to modularize with an IIFE or (in due course)
ES6 module.
To clarify, I wasn't trying to justify arguments.callee.
don't do that is a solution, for this and for many other WTFs and
footguns...
But, isn't the NFEs' way the Right Way to do it?
Do what?
Bind the name inside the function *too*.
Function declarations are useful too. They hoist so you can write them in
top-down order and call in any order from top-level code.
And hoisting is handy, I use it a lot and can't live without it.
You can't do this with vars initialized with function expressions.
Of course, if they were interchangeable we'd simply write var x= function x ()
{}; and done.
Do we want this footgun in function declarations?
What footgun?
The footgun (1) is to have the name bound *only* in the outer scope.
People don't overwrite function declarations' bindings by accident much, if
at all.
I can't remember hearing of this lately, although it can happen when loading
libraries where a common name is used by two libraries.
Yes it's a corner case.
Programmers do intentionally replace a function's name in its scope, e.g. to
auto-memoize.
Oh, how does that work? I've written memoizers but never needed to overwrite a
name.
Why?
Is there any reason for not removing it? (Other than because it's a corner
case?)
Removing what?
The footgun (1)
The writable binding created by a function declaration? That's required by
backward compatibility (e.g. the memoization pattern).
The -outer- writable binding isn't the problem, the problem is the lack of
binding in the inner scope. Is there a reason for not having it?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
On 19/11/2012, at 20:34, Brandon Benvie wrote:
On Mon, Nov 19, 2012 at 2:29 PM, Jorge Chamorro Bieling
jo...@jorgechamorro.com wrote:
On 17/11/2012, at 18:45, Brandon Benvie wrote:
The name property doesn't currently (and the I don't propose it should)
have a correlation to the name in scope. In function declarations the name
is only in scope because its declared in the outer scope, and this can be
overwritten permanently rendering the name unusable in that scope. A named
function expression
--and function declarations too--
puts the name association in a decorative scope that is untouchable and
only accessible inside the function.
It's not clear to me whether one might end with function whose name (the
value returned by function.name) might be !== than its name as seen from
inside the function itself:
function ƒ () { return (ƒ.name !== 'ƒ') }
?
function x(){ x = { name: 'y' }; return x.name } x(); // 'y'
(function x(){ x = { name: 'y' }; return x.name })() // 'x'
The behaviour of the function declaration surprises me for since the days of
the discussions about the ditching of arguments.callee, I seem to recall, one
of the arguments in favor of ditching it was that a reference to itself was
already available there, inside the named function, safe and in scope, *ever*,
and not only in the case of (named) function expressions.
Having it declared (only) in the outer scope has risks that arguments.callee
didn't have, and that NFEs don't have. Is there any justification for this
difference?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
On 17/11/2012, at 18:45, Brandon Benvie wrote:
The name property doesn't currently (and the I don't propose it should) have
a correlation to the name in scope. In function declarations the name is only
in scope because its declared in the outer scope, and this can be overwritten
permanently rendering the name unusable in that scope. A named function
expression
--and function declarations too--
puts the name association in a decorative scope that is untouchable and only
accessible inside the function.
It's not clear to me whether one might end with function whose name (the value
returned by function.name) might be !== than its name as seen from inside the
function itself:
function ƒ () { return (ƒ.name !== 'ƒ') }
?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
On 16/11/2012, at 21:46, Brandon Benvie wrote: Yeah, once you try to get fancy with interpolating a name you go down a dark path real quick. I think that tends to be more in line with the concept behind displayName which is the debug flavor of this and wants to do heroic feats to trace a usable debug name. The name property should be something that you'd actually purposefully write out yourself, not a derived object path. This is where the writability comes in. If the author does fail to hit the mark and doesn't provide a usable name, they can at least manually set it after the fact. Remember that a function's name is more than that string attached to function.name: it's also that var declared inside the function whose value is the function itself. When you talk about writable and automatically generated names, do you mean both the string in function.name *and* that var's name? Cheers, -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: typeof null
On May 9, 2012, at 11:43 PM, Brendan Eich wrote: I think we should consider Object.isObject just because the typeof null change replaced it, but 1JS killed that replacement. Also gives Object.isValue and Array.isArray some company ;-). Why not .isPrimitive()? We've always been talking about primitive values and objects, isn't it? Are we going to have RegExp.isRegExp() and Date.isDate() and Number.isNumber() etc. too ? -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: typeof null
On May 10, 2012, at 1:08 AM, Axel Rauschmayer wrote: Are we going to have RegExp.isRegExp() and Date.isDate() and Number.isNumber() etc. too ? I did wince a bit about ES5's Array.isArray -- perhaps since it takes any x and tells whether x is an Array (from any window or frame) instance, it should have gone on object. You're right that the instanceof limitation motivating Array.isArray applies to these and other built-in classes as well. Do we just add 'em all, or try to add only the ones for which we have enough experience to hope we're actually helping developers? How many times have you wanted RegExp.isRegExp, say? The belief is that testing for array-ness is more common. I don't have data, though, so I'm uncomfortable with any need-based approach. Adding lots of predicates is straightforward, but then the dialectic requires us to wince at the sheer number of predicates (and the redundant name stems), and try for something like what Axel suggested: a do-it-all type or typeOf or classify API. Comments welcome. I'm not sure what is best but lean toward predicates as goods in themselves, even if not the complete solution (if there is a complete solution). It would be great if we could eliminate these predicates completely. How often does the frame crossing problem matter in practice? It doesn’t show up in non-browser environments, right? I see several possibilities: - Make instanceof work correctly with objects that have crossed frames. - Introduce a binary predicate, e.g. likeInstanceOf that correctly handles cases where the lhs and rhs come from different contexts/frames. Additionally, one could throw an exception if there is an instanceof check whose lhs and rhs are from different contexts (failing fast, preventing obscure and hard-to-debug errors). When you want to dispatch based on a type, a fixed typeof (one that worked well) would be better: switch (typeof x) case Array: case RegExp: case ... else you'd have to do: if (Array.isArray(x)) ... else if (RegExp.isRegExp(x)) ... else if ( etc ) When you just want to assert that x is of type Type, then an if (Type.isType(x)) would be ok, but a proper typeof would do just as well: if (typeof x === Type) So it seems that a new, fixed typeof would be best? And if the new, fixed typeof were typeOf(), with capital O, a global function instead of a language keyword/operator? That would be easily polyfill-able. -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Should ... be suffix rather than prefix?
On Apr 3, 2012, at 10:16 PM, Mark S. Miller wrote: foo(a, b, ...rest) vs foo(a, b, rest...) Which is clearer? ES6 has currently agreed on the first. English and Scheme agree on the second. The second, of course. As in C: the ellipsis always ends the parameters list. -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow function syntax simplified
On Apr 2, 2012, at 6:48 AM, Dmitry Soshnikov wrote:
P.S.:
Offtopic footnote. 6 types:
1. Function Declaration (FD). Features: hoisting, always named.
2. Function Expression (FE). Features: no hoisting, available for
immediately invoked functions (IIF).
3. Named Function Expressions (NFE). Features: no hoisting, the same as FE
actually, but because of many old (?) bugs/features, especially in IE, I put
them in the separate type. Since ES5 strict they are just FE if implemented
correctly.
4. Functions created via Function constructor (FF). Features: only global in
the scope chain.
And always anonymous.
5. Bound functions (BF). Features: captures `this', but dynamic `this' in
case of `new', no `prototype', no [[Scope]], no [[Construct]], but delegation
to the target's, etc.
No [[Scope]]? I must be missing something! Given this code:
bound= (function a(i) { return function b () { return i }.bind(null) })(27);
bound()
-- 27
How can bound() resolve `i` without a [[Scope]] ?
6. Arrow functions (AF). Features: captured `this', captured `this' even in
case of `new'.
And [[Extensible]] === false... I wonder why, why non-extensible ?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow function syntax simplified
On Apr 2, 2012, at 2:12 PM, Brendan Eich wrote:
Jorge wrote:
No [[Scope]]? I must be missing something! Given this code:
bound= (function a(i) { return function b () { return i }.bind(null) })(27);
bound()
-- 27
How can bound() resolve `i` without a [[Scope]] ?
By delegating to bound()'s [[TargetFunction]], which does have a [[Scope]] --
see ES5 15.3.4.5.1 and 15.3.4.5.2.
Oh, I see. Thank you!
6. Arrow functions (AF). Features: captured `this', captured `this' even
in case of `new'.
And [[Extensible]] === false... I wonder why, why non-extensible ?
No, arrows are extensible -- where did you see [[Extensible]] === false?
I saw it here:
http://www.yuiblog.com/blog/2012/03/30/what-is-the-meaning-of-this
Function objects are mutable like other objects. This will make the securing
of JavaScript more difficult because every function object can be used as a
channel to facilitate unwanted collusion between widgets. ES5 provides tools to
freeze functions, making them immutable, but the tools are really difficult to
use for that purpose. The Sixth Edition of ECMAScript may correct all of these
problems.
...
Fat arrow functions do not have prototype properties, which makes them cheaper
to make. They are immutable.
...
You will need the old functions to make mutable functions, although I don’t
recommend those either.
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow function syntax simplified
On Apr 2, 2012, at 9:47 PM, Brendan Eich wrote:
Douglas Crockford wrote:
It seems I misunderstood what we were agreeing to. I think the (this...)
form is critically important, and the immutability thing as well.
(...)
I agree that leading |this| could be important for dynamic non-method
use-cases, but those are relatively rare (let's not discount JQuery, but
again, it could use long functions and survive). We could put
leading-this-parameterization on the agenda for May, but we'll have to be
careful not to lose consensus on arrows.
I was chatting this evening with a friend about this (ruby) thing:
class Numeric
(Math.methods - Module.methods - [hypot, ldexp]).each do |method|
define_method method do
Math.send method, self
end
end
end
And I showed him how one could do that easily in JavaScript:
Object.getOwnPropertyNames(Math).forEach(function (key) {
if (typeof Math[key] === 'function') {
Number.prototype[key]= function () {
return Math[key](this);
};
}
});
Then I thought, let's see how would that look like with arrows ?
Object.getOwnPropertyNames(Math).forEach((key) = {
if (typeof Math[key] === 'function') Number.prototype[key]= () =
Math[key](this);
});
And it turns out that here, the outer/enclosing context `this` isn't the one
you want/need. You'd need a dynamically bound `this` instead:
Object.getOwnPropertyNames(Math).forEach((key) = {
if (typeof Math[key] === 'function') Number.prototype[key]= (this) =
Math[key](this);
});
and thus the this-in-the-parameters-list trick.
I don't think it's such a rare case: Inside a constructor function called with
`new`, yes, `this` is most likely going to be the right `this` always, but when
you are building objects with a factory (e.g. with a .create() method), the
enclosing `this` usually isn't going to be the right one.
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: optional function keyword
On Mar 9, 2012, at 9:45 PM, Brendan Eich wrote:
I originally wrote up
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
and
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
as mutually exclusive alternatives, but changed the framing for the latter to
recognize the new semantics (beyond ='s |this| TCP conformance). Yet I agree
that if we get shorter function syntax together, block-lambdas lose some of
their oomph.
For downward funargs called by the control flow, and so for novel control
structures, with paren-free call affordances even, they still have some win.
Perhaps not enough to make it into any future edition without prototyping in
popular engines and grass roots pressure...
Anyway, I'm still trying to get something for shorter function syntax into
ES6. I think TC39 can yet make an exception if we have our validation story
figured out. That is where to focus fire.
If short function syntax and block lambdas are mutually exclusive, then the
block lambdas' syntax should be considered as an alternative for short function
syntax, that is, {| params | /* body */ } is a perfectly valid candidate for
short functions, without TCP.
And given that `this` is an invalid name for a parameter, to indicate a bound
this we could simply include it in the parameters list:
{|this, arg1, arg2| /* body */} bound `this`
{|arg1, arg2| /* body */} unbound `this`
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
On Mar 5, 2012, at 11:50 AM, 程劭非 wrote: Hi, everyone, As you know, JSON API will throw a syntax error when trying to stringify a object with circular reference.But indeed the feature serializing/unserializing object with circular reference is needed.(eg. when storing a graph,or status machine) This could interest you: https://github.com/xk/JASON JASON is just like JSON, but unlike JSON it can: • serialize objects with methods • serialize objects with cyclic references • understand Dates, Regexps, Booleans, etc, and restore them with .parse() with their proper types/classes. • understand and serialize all the JS primitives, including undefined • properly recreate the holes in Arrays -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
On Mar 5, 2012, at 5:53 PM, Allen Wirfs-Brock wrote: Finally, I'm not saying there are no circumstances under which we should consider extending the ES JSON support. For example, I think we should consider adding JSON.parseJSONP as a function. JSONP has broad adoption and there would be a major security benefit from safely parsing it at the ES engine level. Yes, please, that would be awesome. IIRC Crockford proposed ~ that about a century ago (JsonRequest() or something, ISTR) +1k -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
On 22/01/2012, at 21:00, Brendan Eich wrote: Brandon Benvie mailto:bran...@brandonbenvie.com January 21, 2012 9:59 PM Sorry to spam this thread but I wanted to get the relevent points in up front: 'Actually, wait a minute -- I think I disagree with you here. On what? Being past the deadline? Not rushing a de-jure standard before we have synthesized the right semantics from relevant JS embeddings? Spec the unofficial agreement, including the minimal(/maximal if it exists) time constraints, and go from there. This is needed. Why? What goes wrong if we go light on execution model one more time? I think nothing. But in fact we are going to get a little more into execution model in ES6. How much remains to be seen. We discussed it at last week's meeting. But this is not an all-or-nothing proposition, and I do not see the do-or-die requirement. Reality is what it is. HTML5 captures a lot. Node.js conforms. ES6 saying more doesn't alter these facts. Now isn't that ~ the opposite of what you said on 2011-03-18 in David Bruants' Bringing setTimeout to ECMAScript thread ? quote Add to that the fact that Netscape and Microsoft failed, or chose not to, standardize the DOM level 0, and we have the current split where setTimeout is in HTML5 but the core language is embedded with increasing success in non-browser, no-DOM host environments *that want setTimeout*. I'm open to Ecma TC39 absorbing setTimeout and the minimum machinery it entrains. We should ping Hixie. /quote Why ? What has changed ? P.S. Node.js does *not* conform. Not at all. Not only it doesn't clamp to 4ms (which happens to be a good thing, IMO), but its timers often fire out of order ! -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
On 23/01/2012, at 04:57, Mikeal Rogers wrote: On Jan 22, 2012, at January 22, 20121:35 PM, Jorge wrote: . Not at all. Not only it doesn't clamp to 4ms (which happens to be a good thing, IMO), but its timers often fire out of order ! node.js does not conform to the 4ms clamp because that would be silly. Exactly http://groups.google.com/group/nodejs-dev/msg/788492357732e93e It does not fire timers out of order, that I know of. http://groups.google.com/group/nodejs-dev/browse_thread/thread/922a30cf88a1b784 If you have a case where that is not true then it's a bug in libuv (setTimeout's event system is in libuv now) that we need to have fixed. The test that's been disabled: https://github.com/joyent/node/blob/master/test/simple/test-next-tick-ordering.js#L50-54 -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On 21/01/2012, at 05:31, Brendan Eich wrote: Jorge mailto:jo...@jorgechamorro.com January 20, 2012 7:15 PM Sorry, I don't follow, with that you mean something else or the acute accent ? Oh, not ' but the diacritical on é, you mean? Yes, the acute accent. For example. Or something else. You can choose almost any character you want. How do I type that on a US or UK keyboard? I don't know, my keyboard is spanish. Here it's next to the P. We are not going to use non-ASCII characters, so you are still barking up the wrong tree. Aren't you discussing the possibility of using ƒ or λ for functions in this same thread ? Well, the florín is not an ASCII character either. -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On 19/01/2012, at 22:14, Axel Rauschmayer wrote:
Suggestion: a community-edited page where we collect the rejected syntaxes
(= less running in circles) – simply copying emails (such as yours below)
there would probably suffice.
Has a backtick/accent grave ever been considered and/or rejected ?
Anonymous function expression:
setTimeout( '(){ ... }, 1e3);
Named function expression:
setTimeout( 'name(){ ... }, 1e3);
Declarations:
`(){ ... } // error: can't declare anonymous functions
`name(){ ... }
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On 20/01/2012, at 19:17, Brendan Eich wrote:
Jorge mailto:jo...@jorgechamorro.com January 20, 2012 1:22 AM
Has a backtick/accent grave ever been considered and/or rejected ?
Anonymous function expression:
setTimeout( `(){ ... }, 1e3);
Named function expression:
setTimeout( `name(){ ... }, 1e3);
Declarations:
`(){ ... } // error: can't declare anonymous functions
`name(){ ... }
Rejected, that is used by wiki.ecmascript.org/doku.php?id=harmony:quasis
already.
1.- There are not quasi literals in the language yet
2.- quasi literals could as well use something else (the acute accent ?) instead
3.- a shorter function syntax is almost at the top in the programmers' wish
list for ES.next (unlike quasis)
Isn't it -perhaps- too soon to reject ` for functions in favor of quasis ?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On 21/01/2012, at 02:34, Axel Rauschmayer wrote:
how about ƒ (which has been mentioned many times)? It seems very appropriate
and is even easy to type on a Mac (easier than square brackets on a German
keyboard!).
setTimeout( ƒ () { ... }, 1e3)
setTimeout( `() { ... }, 1e3)
setTimeout( ƒ name () { ... }, 1e3)
setTimeout( `name () { ... }, 1e3)
ƒ name () { ... }
`name () { ... }
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On 21/01/2012, at 03:59, Brendan Eich wrote: 2.- quasi literals could as well use something else (the acute accent ?) instead No, that is used for string literals, since JS1 in 1995! Sorry, I don't follow, with that you mean something else or the acute accent ? str = ´agudo´ Error • message: Invalid character '\u0180' -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Approx-equal operator
On 19/12/2011, at 10:10, Dmitry Soshnikov wrote: Have we already planned paren-free calls? Seems I missed approved strawman. Only for block lambdas, if I'm not mistaken: https://mail.mozilla.org/pipermail/es-discuss/2011-May/014595.html quote 3) Should paren free calls be introduced? I'm not proposing this in general, and I do not believe anyone else on TC39 will. /be /quote There's this too: https://mail.mozilla.org/pipermail/es-discuss/2011-May/014587.html quote You're ignoring the goal of providing paren-free block-argument call syntax for control abstractions that look like built-in control-flow statements. /quote The thread was block lambda revival: https://mail.mozilla.org/pipermail/es-discuss/2011-May/thread.html#14563 Cheers, -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)
On 09/11/2011, at 22:05, Brendan Eich wrote:
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach( function(key) {
body
});
By the way, isn't that above a(nother) good use case for a goto, given that
there's no (easy) way to break out of a forEach 'loop' ?
goto as in C, from body to a label in the outer function or script?
Seriously?
OMG. Did I say that ? a goto across functions ? :-P My bad.
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Lecture series on SES and capability-based security by Mark Miller
On 03/11/2011, at 23:55, Mark S. Miller wrote:
3) Although SES is *formally* an object-capability language, i.e., it has all
the formal properties required by the object-capability model, it has bad
usability properties for writing defensive abstractions, and therefore bad
usability properties for use as an object-capability language or for serious
software engineering. One example:
In a SES environment, or, for present purposes, an ES5/strict environment in
which all primordial built-in objects are transitively frozen, say Alice uses
the following abstraction:
function makeTable() {
var array = [];
return Object.freeze({
add: function(v) { array.push(v); },
store: function(i, v) { array[i] = v; },
get: function(i) { return array[i]; }
});
}
Say she uses it to make a table instance with three methods: add, store,
and get. She gives this instance to Bob. Alice and Bob are mutually
suspicious. All of us as programmers, looking at this code, can tell that
Alice intended the table abstraction to encapsulate the array. Given just a
table instance, can Bob nevertheless obtain direct access to the underlying
array?
Yes, this:
function makeTable() {
var array = [];
return Object.freeze({
add: function(v) { array.push(v); },
store: function(i, v) { array[i] = v; },
get: function(i) { return array[i]; }
});
}
o= makeTable();
o.add(1);
o.add(2);
o.add(3);
o.add('Yay!');
o.store('__proto__', {push:function () { console.log(this) }});
o.add();
Gives:
[ 1, 2, 3, 'Yay!' ]
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Lecture series on SES and capability-based security by Mark Miller
On 04/11/2011, at 18:51, Jorge wrote:
On 03/11/2011, at 23:55, Mark S. Miller wrote:
3) Although SES is *formally* an object-capability language, i.e., it has
all the formal properties required by the object-capability model, it has
bad usability properties for writing defensive abstractions, and therefore
bad usability properties for use as an object-capability language or for
serious software engineering. One example:
In a SES environment, or, for present purposes, an ES5/strict environment in
which all primordial built-in objects are transitively frozen, say Alice
uses the following abstraction:
function makeTable() {
var array = [];
return Object.freeze({
add: function(v) { array.push(v); },
store: function(i, v) { array[i] = v; },
get: function(i) { return array[i]; }
});
}
Say she uses it to make a table instance with three methods: add, store,
and get. She gives this instance to Bob. Alice and Bob are mutually
suspicious. All of us as programmers, looking at this code, can tell that
Alice intended the table abstraction to encapsulate the array. Given just a
table instance, can Bob nevertheless obtain direct access to the underlying
array?
Yes, this:
function makeTable() {
var array = [];
return Object.freeze({
add: function(v) { array.push(v); },
store: function(i, v) { array[i] = v; },
get: function(i) { return array[i]; }
});
}
o= makeTable();
o.add(1);
o.add(2);
o.add(3);
o.add('Yay!');
o.store('__proto__', {push:function () { console.log(this) }});
Or even easier yet, what Axel says:
o.store('push', function () { console.log(this) });
o.add();
Gives:
[ 1, 2, 3, 'Yay!' ]
[ 1, 2, 3, 'Yay!', push: [Function] ]
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On 30/10/2011, at 23:36, Brendan Eich wrote:
On Oct 30, 2011, at 12:33 PM, Allen Wirfs-Brock wrote:
The object exemplar approach is just like self or selfish, except that it
builds upon features that are already in JS. Specifically, it uses the new
operator instead of a new method and it names the initialization method
constructor in order to tie into the object construction mechanisms that
already exist in JS.
+1
The only thing I find off the mark is the typography of |. In light of this,
and of the anti-grawlix reaction among many people, could we revisit an infix
operator used in restricted productions with [no LineTerminator here] on the
left of the operator contextual keyword?
Likely keywords include 'proto' (but 'protos' seems better English given the
LHS being the prototype object), or my current best shot: 'beget'.
let obj = base beget {a: 1, b: 2}
let arr = base beget [p, q, r]
let fun = base beget function (...args) { ... }
let re = base beget /(\w+)\s+(\w)+/g
It's still idiomatic as a name for differential inheritance, but it is more
pithy than 'make' or 'create' (and one character shorter than 'create' -- no
Unix 'creat' reruns! ;-). Comments?
Saying or writing triangle does not convey meaning, and it's confusing in
geometry/graphics contexts.
Perhaps a long arrow may work ?
let object= base == {a: 1, b: 2};
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On 31/10/2011, at 08:57, Brendan Eich wrote:
On Oct 31, 2011, at 12:20 AM, Jorge wrote:
Perhaps a long arrow may work ?
let object= base == {a: 1, b: 2};
Does not overcome the grawlix objection.
Hmm, it's grawlix-y too but... how about
let object= base :: {a: 1, b: 2};
?
let object= base == {a: 1, b: 2};
let object= base : {a: 1, b: 2};
let object= base | {a: 1, b: 2};
let object= base :: {a: 1, b: 2};
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On 20/10/2011, at 23:37, Brendan Eich wrote:
On Oct 20, 2011, at 12:59 PM, Jorge wrote:
the assert_invariants() at the next line might run in another turn of the
event loop (when f() resumes), just as the callback does.
No. Nothing in JS today, since it lacks coroutines or call/cc, can suspend
under f and cause the continuation to be captured and then called in a later
event loop turn.
That's why I put the comment //might suspend execution !
*IF* it had coroutines or call/cc, then
the assert_invariants() at the next line might run in another turn of the
event loop (when f() resumes), just as the callback does.
and then, as far as I can see, the risks wrt invariants would be exactly the
same in the two cases:
//#1
assert_invariants();
function callBack () {
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee.
};
setTimeout(callBack, 1e3);
return;
//#2
assert_invariants();
f(); //might suspend execution
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee either.
return;
And my point is that the invariants not invariant anymore argument against
call/cc (that the node.js guys keep harping on again and again) does not hold
for this kind of async code written in cps because this kind of async code
written in cps does not guarantee it either.
On the other hand, *IF* we could suspend f(), instead of:
asyncFunction(request, cb);
function cb (e, response) {
if (e) //whatever
//our code continues here
}
we could simply write the above like this:
try {
response = asyncFunction(request); //might suspend execution
}
catch (e) {
//whatever
}
//our code continues here
And this has several (valuable, imo) advantages:
- We aren't trashing the call stack on every async call: we can finally debug
properly!
- We can (finally!) catch the exceptions where and when it matters.
- We can loop and control flow in the usual ways (at last!).
- It's the habitual style of coding that everybody knows already.
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On 21/10/2011, at 11:07, Jorge wrote: And this has several (valuable, imo) advantages: - We aren't trashing the call stack on every async call: we can finally debug properly! - We can (finally!) catch the exceptions where and when it matters. - We can loop and control flow in the usual ways (at last!). - It's the habitual style of coding that everybody knows already. One more: - We won't have to keep pumping data upwards in the contexts in the closure (from the callback), and/or nesting them (both the contexts and the callbacks). -- Jorge ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On 21/10/2011, at 17:40, Eric Jacobs wrote:
Jorge,
Would it still be satisfying to you if instead of writing the call expression
like this:
try {
response = asyncFunction(request); //might suspend execution
}
catch (e) {
//whatever
}
//our code continues here
we needed to write it with an explicit annotation, like this:
response = yield asyncFunction(request); //might suspend execution
or perhaps this:
yield { response = asyncFunction(request); } //might suspend execution
or some other creative way of statically encoding the might suspend
execution condition into the syntax?
Yes, of course, it would be fine. Why ?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On 21/10/2011, at 21:23, Dean Landolt wrote:
On Fri, Oct 21, 2011 at 3:20 PM, Jorge jo...@jorgechamorro.com wrote:
On 21/10/2011, at 17:40, Eric Jacobs wrote:
Jorge,
Would it still be satisfying to you if instead of writing the call
expression like this:
try {
response = asyncFunction(request); //might suspend execution
}
catch (e) {
//whatever
}
//our code continues here
we needed to write it with an explicit annotation, like this:
response = yield asyncFunction(request); //might suspend execution
or perhaps this:
yield { response = asyncFunction(request); } //might suspend execution
or some other creative way of statically encoding the might suspend
execution condition into the syntax?
Yes, of course, it would be fine. Why ?
Because this is the fundamental difference between shallow and deep
continuations.
Yes, if we can write this:
try {
response = yield asyncFunction(request); //might suspend execution
}
catch (e) {
//whatever
}
and asyncFunction can suspend/resume then it's alright.
Why ?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On 19/10/2011, at 23:34, Brendan Eich wrote:
The other objection is that (ignoring some evil native APIs such as sync XHR)
JS has run-to-completion execution model now. You can model
assert_invariants();
f();
assert_invariants_not_affected_by_f_etc();
where etc means functions called from f. No data races, no preemption
points even if voluntary -- the immediately preempted function may have
volunteered, but in programming in the large, the sum of its ancestors in all
call graphs may well *not* have volunteered to lose their invariants.
This second objection is not an implementor issue, rather a
security/integrity/pedagogy concern. It's a big one too.
Is run-to-completion so important, really ?
Because, if there's a callback involved, the invariants are not invariant
anymore, and that's the sole argument node.js guys keep harping on again and
again (wrongly imo) against any way of suspending/resuming f().
For example:
assert_invariants();
function callBack () {
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee.
};
setTimeout(callBack, 1e3);
return;
So, as far as I can see, when dealing with asynchronous code, the risks in that
code are equivalent to the risks in this code:
assert_invariants();
f(); //might suspend execution
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee either.
return;
But, in the first case you can't try/catch where it matters (which is
annoying), and you can't write your code linearly as if it were synchronous,
which is a (bit of a) pain.
So I must be missing something. What's it ?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield and Promises
On 20/10/2011, at 18:38, Brendan Eich wrote:
On Oct 20, 2011, at 6:44 AM, Jorge wrote:
On 19/10/2011, at 23:34, Brendan Eich wrote:
The other objection is that (ignoring some evil native APIs such as sync
XHR) JS has run-to-completion execution model now. You can model
assert_invariants();
f();
assert_invariants_not_affected_by_f_etc();
where etc means functions called from f. No data races, no preemption
points even if voluntary -- the immediately preempted function may have
volunteered, but in programming in the large, the sum of its ancestors in
all call graphs may well *not* have volunteered to lose their invariants.
This second objection is not an implementor issue, rather a
security/integrity/pedagogy concern. It's a big one too.
Is run-to-completion so important, really ?
Yes.
Birdie: You looking for an answer or an argument?
Margo Channing: An answer.
Birdie: No.
Margo Channing: Why not?
Birdie: Now you want an argument.
Because, if there's a callback involved, the invariants are not invariant
anymore,
What do you mean by if there's a callback involved?
What I sketched showed a function f being called. There is no preemption
point under a function call. If I had written g(function callback() {...}))
then the ... would perhaps have run in a separate event loop turn. So what?
That's not issue.
and that's the sole argument node.js guys keep harping on again and again
(wrongly imo) against any way of suspending/resuming f().
You are changing the example to something not at issue. Callbacks run in
separate turns (by convention, better if defined as always, as for
setTimeout(0)).
For example:
assert_invariants();
function callBack () {
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee.
};
setTimeout(callBack, 1e3);
return;
Here again, as with 'yield', the programmer explicitly opted out of
run-to-completion. The reader can see the 'function callBack' head and braced
body. This signals that the code is deferred and won't be executed until
invocation.
So, as far as I can see, when dealing with asynchronous code, the risks in
that code are equivalent to the risks in this code:
assert_invariants();
f(); //might suspend execution
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee either.
return;
See above. You're now making every single call expression in an entire JS
codebase potentially a preemption point. That's bad for reasoning about
invariants, therefore bad for correctness, including security.
But, in the first case you can't try/catch where it matters (which is
annoying), and you can't write your code linearly as if it were synchronous,
which is a (bit of a) pain.
So I must be missing something. What's it ?
You changed the example to defer evaluation with a callback.passed down to
another function and then asserted the changed example was no different from
a direct call with no callback. That's different, because the function
wrapping explicitly defers evaluation of the function body.
I don't see how it's different: next to f() it says //might suspend execution:
the assert_invariants() at the next line might run in another turn of the event
loop (when f() resumes), just as the callback does.
?
--
Jorge.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Grawlix
On 13/10/2011, at 20:05, Allen Wirfs-Brock wrote: People coming to JS from C/C++/Java are generally happy with the JS syntax (but don't like other things about it). People coming from Ruby or Python generally aren't happy with JS syntax. There's many more JS/C/C++/Java programmers than Ruby/Python programmers. In the long run, if a language like JS is highly successful it doesn't matter because ultimately most people will just learn it as one of their first programming languages. If the objective were to serve the majority, then JS's C-like syntax should be left as is. C remains the second most popular programming language in the world: http://tcrn.ch/prmhOf JavaScript's C-like syntax is a Good Thing™ -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Grawlix
On 13/10/2011, at 19:05, Russell Leggett wrote: Is coffeescript vs. javascript big enough to be the difference between being happy or not? I think that depends on the person, but based on its popularity, I would say for some people it is. Based on its popularity, instead of for some people it is, I would say for most people it isn't. (I see the glass almost empty). -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony - proxies | asynchronous
On 02/09/2011, at 18:08, Mikeal Rogers wrote: fibers turns node.js in to something the core team doesn't really view as being node.js any longer. we believe that it's more important to have assurances that your state can't mutate between anything but a callback and that breaking that means you're basically breaking node. But fibers don't break that guarantee (if it exists at all: contexts are *not* immutable, even without fibers). -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Subject: Re: Harmony - proxies | asynchronous
On 03/09/2011, at 02:12, Brendan Eich wrote: On Sep 2, 2011, at 3:01 PM, Bradley Meck wrote: Even worse, libraries must support this, similar to how a few libraries that break when a script in strict mode invokes them but unlike frowned upon features, Strict mode is a static property of code. Strict callers cannot affect behavior of non-strict callees. So I'm not sure what you mean here. Can you give an example? we are talking about every feature that a proxy has would have to be guarded for this. In the browser, DOM and host object precedent means we crossed this bridge a long time ago. IINM, Node has built-in objects that can do magical host-object-like things too. Has it therefore crossed the same bridge too? That is, couldn't such Node host objects be passed to library code that cannot assume plain-old-native-object non-magical semantics? Yes, buffers are live too. buffer[i] === buffer[i] may be false sometimes. -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block-lambda revival
On 23/06/2011, at 23:01, Marc Harter wrote:
Peter Michaux encouraged me to write my thoughts on es-discuss so here I am.
Out of the various new function syntaxes proposed ( -, #, {||} ) I
have really taken a liking to the block-lambda revival strawman. I
think in general they all address similar wishes (e.g. implicit
return, this, shorter). I prefer the block-lambda because of some use
cases:
let a = [1,2,3,4];
let b = a.reduce((a,b) - a + b) // didn't see an example for this one
assuming this is how it looks
let b = a.reduce {|a,b| a + b} // less cluttery, fn bound by braces,
couple characters less to type
Self executing function expressions
(- {
// multi-line
}())
{||
// multi-line -- i'm assuming there wouldn't need to be parens
around the whole thing because block lambdas are expressions not
statements (is this the case with arrow?)
}()
I like block-lambda because:
1. From my understanding braces aren't going away, lets just embrace
them (use them as part of the syntax)
2. Arrow gets too bulky with braces (although worked good for CoffeeScript)
3. Seems to be terse yet clear
4. Encloses the function
It may be nice to have side by side comparisons of the different
proposals doing the same operation.
Here: http://jorgechamorro.com/blocks.html
Anyway, my 2 cents. Thanks!
{|| ... } for shorter *function* syntax is my favorite too. +1(e9)
Also, if any { block } could be a lambda, perhaps we won't need that (nor any
new) syntax for block-lambdas.
Also, I'd prefer to know/see clearly when a function is being call()ed, so I'm
not very fond of paren-free calls: foo(bar) is clearly an invocation, unlike
foo bar, and readability is more important than saving a few keystrokes.
The C language is still (and -ISTM- will be for a long time) important, so
-IMO- every little bit of JS's C-like syntax is a plus: less to learn: an old,
popular, widely used, well-known, and familiar syntax.
JS -unlike other languages- is important enough that it does not need to follow
these (dubious) trendy fashions to become popular. Nor to survive.
Proper punctuation aids comprehension and we're programming, not writing quick
SMSs.
--
Jorge.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On 28/05/2011, at 16:29, Brendan Eich wrote:
On May 28, 2011, at 1:49 AM, Jorge wrote:
On 27/05/2011, at 12:24, Brendan Eich wrote:
On May 27, 2011, at 2:36 AM, Jorge wrote:
Also, I wonder if in order to make blocks first class, do we need any new
syntax ?
function f() {
a.forEach({ return 3 });
The problem is that a block statement is ambiguous with an object
initialiser. See
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax#grammar_changes
in particular the To enable unparenthesized ObjectLiteral expressions as
bodies of arrow functions, without ambiguity with Block bodies, restrict
LabelledStatement as follows... section.
As labels are seldom used in JS, perhaps the easiest way to avoid
ambiguities would be to forbid blocks from beginning with a label ?
Would it be too much (or too ugly) to require the programmer to disambiguate
(only) in this corner case ?
A block:
{ noLabelHere ... }
We didn't talk about this change. It is yet another migration early-error to
consider.
But it's not very usual to begin a block with a label.
It's certainly simpler than a more powerful parsing algorithm than LR(1),
If you
1.- keep the familiar { block } syntax for first class blocks, and
2.- use {|| ... } for shorter functions syntax and
3.- keep the (obligatory) parens as the call() operator
wouldn't we gain everything in the arrow syntax and block lambdas strawmen,
except for paren-freeness ?
And, wouldn't that be easier for the current (proven) parsers, and pose almost
zero risks in this respect ?
And, wouldn't that be in line the already known, much appreciated by many of
us, current JS (and C) style ?
{ block }( call ) or {|| ... }( call )
foo bar baz ... wtf ? foo(bar(baz)) ? foo(bar)(baz) ? foo(bar)(baz)() ? meh!
This syntax introduces ambiguities !
Do David and Jeremy like it ? Good for them. Do JavaScripters like it ? The
least we can say is that it's quite polemical :
https://github.com/rails/rails/commit/9f09aeb8273177fc2d09ebdafcc76ee8eb56fe33
but we might want to cross that bridge anyway for arrow functions.
fwiw
Arrow syntax is extraneous to JS developers. It's an unnecessary, radical style
change. And ugly: there are JS developers that just *don't*like* it.
So, why ?
Paren-free(ness) is a fashion: foo bar baz, what's a function, who's calling
who ? with which parameters ? Meh! Ambiguities.
/fwiw
If we succeed there, we may not need such an incompatible restriction on
labels.
-1
--
Jorge.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On 27/05/2011, at 11:01, Brendan Eich wrote:
On May 26, 2011, at 4:22 PM, Waldemar wrote:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
The return will return out of f. Note also that the implementation of
forEach could have a try-finally statement that catches and revokes the
return. This kind of cross-function return catching is new.
And some on TC39 3 this Tennent sequel feature, to quote dherman. Others
cited the new as potentially too much for average users to grok. No one hated
it overtly.
It's not that it's too much to grok, it's that as I like that (blocks) syntax
so much, I'd prefer to use it for (shorter) functions (syntax) instead of the
(ugly, extraneous, imho) arrow syntax proposal, not for blocks.
Also, I wonder if in order to make blocks first class, do we need any new
syntax ?
function f() {
a.forEach({ return 3 });
}
?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On 27/05/2011, at 11:36, Jorge wrote:
On 27/05/2011, at 11:01, Brendan Eich wrote:
On May 26, 2011, at 4:22 PM, Waldemar wrote:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
The return will return out of f. Note also that the implementation of
forEach could have a try-finally statement that catches and revokes the
return. This kind of cross-function return catching is new.
And some on TC39 3 this Tennent sequel feature, to quote dherman. Others
cited the new as potentially too much for average users to grok. No one
hated it overtly.
It's not that it's too much to grok, it's that as I like that (blocks)
syntax so much, I'd prefer to use it for (shorter) functions (syntax) instead
of the (ugly, extraneous, imho) arrow syntax proposal, not for blocks.
Also, I wonder if in order to make blocks first class, do we need any new
syntax ?
function f() {
a.forEach({ return 3 });
}
?
I have edited (a copy of) the arrow_function_syntax strawman wiki page, to see
side-by-side the current function syntax, the arrow syntax and the blocks
(applied to functions) syntax:
http://jorgechamorro.com/blocks.html
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival, now with semantics
On 23/05/2011, at 07:15, Kam Kasravi wrote:
Is this valid?
function Person(a) {
this.age = a;
}
Person.prototype.myage = {|| this.age};
function info(myage) {
console.log('my age is '+myage());
}
info(new Person(10).myage);
info(new Person(12).myage);
If it's valid (I don't know if there can be a block-lambda standing alone
outside of a function), it would return the value of the global variable `age`,
I think, because the enclosing scope's `this` in that code above seems to be
the global Object.
Brendan, do you really want these block-lambdas to be blocks?
I thought you were just going to borrow its syntax for shorter function(){}
semantics, not blocks semantics ?
What if {||} were just the shorter function syntax we want, with the added
features we want (completion value as return value, lexical/dynamic `this`, ...
?), but not true blocks ?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival
On 21/05/2011, at 16:43, Brendan Eich wrote:
On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
An essential part of this proposal is a paren-free call syntax
Why is that essential?
The argument, as I understand it from Smalltalk, Ruby, and E experts, is
empirical, and in part a matter of intentional design: users write blocks as
actual parameters to make control abstractions. Most such abstractions taking
block arguments do not let those blocks escape through the heap or a return
value -- the blocks are downward funargs. This aids in making new control
abstractions more efficient than functions to implement, as well as more
usable. Built-in control flow statements have (optionally) braced bodies that
do not need parenthesization, so why should new ones created by users passing
blocks?
When I wrote essential, I was not claiming that there's a logical proof of
necessity. Rather I was declaring that this strawman includes paren-free
block-argument-bearing call expressions as an essential design element. (...)
fwiw
I for one do like explicit call()s better, the way it's always been in JS. (
and it's just 2 chars ), perhaps because I can't avoid to see it as a plus to
share syntax with C.
C is one of the -if not the- most important languages in history, and I can see
good reasons for you wanting to borrow from its syntax back then, in 1995 (but
even now, too, because it's *still* one of the most important and popular
languages)
But I can't say so much of borrowing from coffeescript's syntax ? Perhaps in 30
years, we'll see :-)
Why the (sudden) urge to copy so many bits ( paren-free, - // =, etc ) of
coffee's syntax ? (does JS have an identity crisis now ?)
WRT the syntactic noise that these () ; {} etc introduce in the source: I don't
like the way children write their SMSs either, everything are shorthands and
there's no punctuation marks: sure it's faster to write, but not easier to read.
A bit less (syntactic) noise would be good. But a bit less isn't let's make a
new JS that not even a JS programmer can recognize.
I'm a JS programmer that isn't ashamed of its C heritage, and I don't think
JS.next needs that breaking change.
I'd put the stress in the other important things more than in trying to make it
look more current-fashion.
/fwiw
Chopping it out chops down the whole strawman.
No paren-free call()s, no {|| ... } blocks ? Why ?
WRT lexical `this`: I think a simple (illegal var name) in the first parameter
position, for example '@', might serve :
({ lex:lexicalThis, dyn:dynamicThis }).lex().dyn();
function lexicalThis () {
var that= this;
{|@,a,b,etc| assert(this === that)}();
return this;
}
function dynamicThis () {
var that= this;
{|a,b,etc| assert(this !== that)}();
return this;
}
--
Jorge.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On 08/05/2011, at 05:52, Faisal Vali wrote: (...) I find the aesthetics of the arrow-syntax far more consistent with javascript's C-based-syntactic roots than the preprocessor-tainted '#' (...) Consistent ? - in C has a *totally* different meaning ! -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On 08/05/2011, at 04:58, Kyle Simpson wrote:
(...) So I felt like it was important to voice early that not everyone
feels universally so lovey-dovey over that syntax. (..)
What happened to Allen's lambda syntax proposal ?
When, why was it ditched in favor of - ?
Brendan, you liked it. What has happened ?
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008216.html
--
Jorge.
Begin forwarded message:
From: Brendan Eich bren...@mozilla.com
Date: 30 de noviembre de 2008 07:30:14 GMT+01:00
To: es-discuss@mozilla.org
Subject: Allen's lambda syntax proposal
At the TC39 meeting two weeks ago in Kona, we had a brief bikeshedding
discussion about lambda syntax and why it matters. Observation: blocks in
Smalltalk being lightweight means users don't mind writing them for control
abstractions, compared to JS functions in ES3. In Smalltalk, ignoring JS,
it's hard to beat [ and ] as overhead, although one must count the message
selector and its punctuation too.
Allen Wirfs-Brock put his proposal, which will not shock you who know
Smalltalk or Allen, on the whiteboard:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I then started to write an example of return to label, and in need of a
nested lambda, got stuck for a split second trying to write
function^H^H^H^H^H^H^H^lambda. After thinking 0.3 more seconds I then said I
will use Allen's proposed syntax. Pure win, readers and the writer (me)
agreed.
I think someone proposed pretty much the same syntax here on es*-discuss
within the last two years, but I can't find that message at the moment.
Bikeshed color is secondary to semantics, but lambda conciseness does matter.
I think Allen's homage to Smalltalk in JS wins. Every time I reach for more
verbose syntax my hand steers back to those || delimiters.
Am I an old Smalltalk fan? Sure, I have Byte magazine with the balloons on
the cover still (in a box somewhere; mildewed, sadly). I'm the C hacker who
took the make it look like Java orders and made it look like C with some
awk, Self, Scheme, and even HyperCard (HyperTalk, actually) influences.
Eclecticism is not an end, but it could be a means to a better end than a
cramped non-eclectic grammar, if the deeper reasons for concise lambda syntax
are sound and valid. Syntax is for users, it must be usably sweet. It's not
all about theoretical completeness and minimality.
Anyway, we need a fun weekend thread, and everyone loves syntax. Comments?
Huzzahs? The latter go to Allen. Go nuts.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On 07/05/2011, at 02:04, Peter Michaux wrote:
(...)
If the arrow syntax is only syntactic sugar for the existing function
forms then I don't see how it achieves any of the goals he outlined.
The only possible category is be a better language but the arrow
syntax won't make JavaScript a better language for complex
applications or libraries in comparison to any other kind of
JavaScript code. I would argue that the arrow syntax will make
JavaScript a worse language anyway as there are already perfectly good
forms using the function keyword now. We don't need new syntax and
we don't need multiple ways to do the same thing just for the sake 6
characters. Please keep JavaScript simple.
(...)
This above is ~ how I feel about it too.
But if I wanted a shorter syntax, I would no doubt choose ruby blocks' syntax,
it's even shorter yet and it's familiar already to millions of programmers.
On 07/05/2011, at 03:22, David Bruant wrote:
I'm attracted to the idea of a shorter function syntax not only because
it reduces the number of characters of the function keyword, but also
because it gets rid of the return keyword (and corresponding semicolon).
(return does not need the semicolon ;-)
The particular case where I would enjoy shorter syntax is when using
inlined functions in array extras.
// assuming a is an array
a.filter( (e)-(typeof e === number e3) )
.map( (e)-(e*e) )
.reduce( (prev, curr)-(prev+curr), 0);
Using ruby blocks' syntax (+6 versus +4 chars):
a.filter( {|e| typeof e === number e3})
.map({|e| e*e } )
.reduce( {|prev, curr| prev+curr}, 0);
Is {| as a token likely to be found in any .js source file in the world, as
of today ?
- Not in any object literal
- Not likely to be found at the beginning of a block.
- Inside a string it would not matter.
--
Jorge.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives
On 18/04/2011, at 16:37, Mike Ratcliffe wrote: Jorge, I would opt in for warnings e.g. if I planned on minifying my web app in the future. Most web apps will burn in hell if they are missing semicolons when you minify them. Indeed, for some minifiers it's a must. These minifiers avoid (understandably) the hassle/expensiveness of building a parse tree and rely on (clever!) tricks that in turn require the programmer to put every semicolon in the source text, as if post-ASI, explicitly. But a=b\nc=d\n.length is equal to a=b;c=d;.length and that proves that it can be minified just as much without the explicit semicolons. -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On 17/04/2011, at 19:44, Dmitry A. Soshnikov wrote: (...) Since usually, a programmer puts a one logical sentences per line -- *for what* you need additional statement/expression termination besides the new line itself? The useless actions in this case can be compared with masochism. (...) AFAIK, the parser is mostly 'greedy' and keeps parsing and skipping over \n trying to compose the longest sentence that makes sense. This is a feature (IMO) that allows us to break complex/longish statements/expressions onto several lines, for better readability, a feature I wouldn't want to ditch by making \n a statement/expression terminator, except, perhaps, in some very few special situations. -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives
On 19/04/2011, at 19:52, Isaac Schlueter wrote: On Tue, Apr 19, 2011 at 09:57, Jorge jo...@jorgechamorro.com wrote: Most web apps will burn in hell if they are missing semicolons when you minify them. Indeed, for some minifiers it's a must. Which minifiers? I don't know, the ones that make web apps burn in hell if they are missing semicolons. (...) you end up with more easily debuggable minified code, since the line numbers in stack traces are actually helpful. (No line 1, char 82,343 to deal with.) Great, I like that too, but (in production) most sites serve ~ illegible JS on purpose, I think. I don't believe that those minifiers actually get much use. They're hideously broken, and there is a huge selection of competent minifiers that do actually minify JavaScript properly. jsmin.c is all I've ever used and all I've ever needed. It's fast and effective. -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives
On 18/04/2011, at 09:52, Peter van der Zee wrote:
On Mon, Apr 18, 2011 at 3:12 AM, Oliver Hunt oli...@apple.com wrote:
An implementation _could_ add a mode (*shudder*) along the same lines as
strict mode:
die in hell ASI, i hate you with the fiery passion of a thousand burning
suns.;
And then make it a syntax error whenever ASI would occur. I have considered
this in JSC (albeit with a slightly shorter opt in string).
It wouldn't have the backwards compat problems you get by disabling ASI as
the points where ASI being removed changes behaviour would be errors :D
All things considered, another option for vendors is simply adding a
developer setting in their browser that enables warnings (or errors) for ASI
in the console. That would help a lot of current generation developers. Of
course, this wouldn't fix anything for non-browsers (like node). So for them
a directive would be nice, even if it was just to enable warnings while
debugging.
But there's many code :
a= b
c= d
function e () { f() }
that (ISTM) only works *thanks* to A(utomatic)S(emicolon)I(nsertion):
a= b;
c= d;
function e () { f(); }
so you won't want it to die in hell / issue any warnings / throw syntax
errors...
What am I missing ?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives
On 18/04/2011, at 13:10, Peter van der Zee wrote:
On Mon, Apr 18, 2011 at 12:34 PM, Jorge jo...@jorgechamorro.com wrote:
What am I missing ?
As far as the directive goes, they are opt-in. Old code won't be opting in.
Other than that they have the same issues as use strict might have.
But why would anyone want to opt-in to get warnings or even worse syntax errors
for code like this that depends on ASI, where ASI is helping out :
die in hell ASI, i hate you with the fiery passion of a thousand burning
suns.;
// ^ the anti-ASI directive ^^
a= b
c= d
function e () { f() }
*** Warning missing semicolon @ line #4,5
*** Warning missing semicolon @ line #5,5
*** Warning missing semicolon @ line #6,19
Or even worse, halt the program with a:
Syntax error missing semicolon @ line #4,5
?
I understand that it would be quite interesting to get a warning/error in this
case:
a= b
(c= d)();
...only that there's no ASI in this case !
--
Jorge.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
