My apologies, I didn't mean it as a rebuke ( although looking at what
I wrote I can understand the thought ).
I was a bit unsure about floating back up another email like this when
it seemed people maybe weren't interested in the topic. Obviously I
did an awful job at conveying that feeling.
The URLs you're proposing here just *are* logical names, and they
aren't in most cases being dereferenced to produce resources, which is
the core point of URLs on the web. They're just inconvenient logical
names.
No. In my hypothetical scenario they are simply URLs which when
dereferenced
I understand this design now. At scale, it depends upon an implicit,
centralized naming authority to manage naming conflicts. The namespacing
scheme of this authority will necessarily be flat because it will be seeded
with names like jquery and ember.
Who's authority will this be? Google's?
On 26 April 2013 00:27, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
First, I appreciate you setting your thoughts down in detail. I think
this will help us move forward in the discussion.
You write in a later message:
Having said that, interoperability with existing module systems was
not
On 26 April 2013 01:20, David Herman dher...@mozilla.com wrote:
But let's keep the question of having lexical *private* modules separate from
this thread, which is about Andreas's suggestion to have lexical modules be
the central way to define *public* modules.
No, that's not what I
On 27 April 2013 01:17, David Herman dher...@mozilla.com wrote:
On Apr 26, 2013, at 7:27 AM, Kevin Smith zenpars...@gmail.com wrote:
What you propose, with logical names, is a global namespace of short
human-readable names with *no* conflict resolution authority. How do you
see that
On Sun, Apr 28, 2013 at 4:23 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Sun, Apr 28, 2013 at 3:16 PM, Brendan Eich bren...@mozilla.com wrote:
Brian Di Palma wrote:
Another mail that I expected to receive more attention that hasn't...
@Brian, This is the second time you've opened
While this is starting to make a lot of sense to me, especially the
package-vs.-module concerns, I worry about trying to get it in ES6. Also, as
someone with an ES5 background, I don't see the value of lexically-named
modules, and so am happy to postpone them to ES7.
Taken together, I think
On 26 April 2013 17:58, Mark Miller erig...@gmail.com wrote:
I posed my challenge problem primarily as a response to Andreas' position.
Andreas, please rewrite the *very small* example in the linked-to paper
(Also at
https://code.google.com/p/es-lab/source/browse/trunk/src/ses/contract/) in
On 29 April 2013 16:24, Domenic Denicola dome...@domenicdenicola.com wrote:
While this is starting to make a lot of sense to me, especially the
package-vs.-module concerns, I worry about trying to get it in ES6. Also, as
someone with an ES5 background, I don't see the value of lexically-named
Hello,
I understand that the consensus among those present at the last TC39
meeting was that iterators should box their return values in objects of
the form
{ value: VALUE, done: DONE }
where DONE is true or false. Notes here:
Rick Waldron wrote:
Mark Miller and I had an offline discussion that clarified for me that
the example using a symbol as a property key would allow the value to
be discovered via ES6's Object.getOwnPropertyKeys() which returns the
result of the internal [[OwnPropertyKeys]] method. The mistake
[Responding to these two emails together]
On Mon, Apr 29, 2013 at 6:40 AM, Kevin Smith zenpars...@gmail.com wrote:
The URLs you're proposing here just *are* logical names, and they
aren't in most cases being dereferenced to produce resources, which is
the core point of URLs on the web.
Le 29/04/2013 18:09, Brendan Eich a écrit :
Users want class-private (and module-private?) syntax.
I'm not up-to-date on the module work, but last I looked at it, module
private is everything except what is explicitly exported, no? (which is
a good thing, I believe)
David
Hi again,
On Mon 29 Apr 2013 17:37, Andy Wingo wi...@igalia.com writes:
let (g = EXPR) {
let received = void 0, send = true;
while (true) {
let next = send ? g.send(received) : g.throw(received);
if (next.done)
break;
try {
received = yield
David Bruant wrote:
Le 29/04/2013 18:09, Brendan Eich a écrit :
Users want class-private (and module-private?) syntax.
I'm not up-to-date on the module work, but last I looked at it,
module private is everything except what is explicitly exported, no?
(which is a good thing, I believe)
Just a straw-spec device, not proposed for ES6 or 7.
/be
Andy Wingo wrote:
Hi again,
On Mon 29 Apr 2013 17:37, Andy Wingowi...@igalia.com writes:
let (g = EXPR) {
let received = void 0, send = true;
while (true) {
let next = send ? g.send(received) : g.throw(received);
Was there consensus on the return value of the various generator methods being
{ value?, done? } for next/send/throw? Is it needed for close?
The desugaring for yield* in the face of using { value?, done? } is more likely
(without refutable matching or let expressions for the moment):
```js
Thanks for the clarifications re: Future as a monad. My understanding of this
is as follows (please correct me if I am wrong):
* The expected result of the resolve/reject callbacks passed to Future#then is
itself a Future.
* If the result of the resolve/reject callbacks is not a Future it is
On Sun, Apr 28, 2013 at 9:36 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Note that ISO 8601 says that formatting simplifications
such as leaving out the T is permitted with mutual agreement between the
parties interchanging a data. It isn't clear who the other party is that
Ecma-262
On Mon, Apr 29, 2013 at 11:03 AM, Ron Buckton rbuck...@chronicles.org wrote:
Thanks for the clarifications re: Future as a monad. My understanding of this
is as follows (please correct me if I am wrong):
* The expected result of the resolve/reject callbacks passed to Future#then
is itself a
On Mon 29 Apr 2013 19:25, Ron Buckton rbuck...@chronicles.org writes:
The desugaring for yield* in the face of using { value?, done? } is more
likely (without refutable matching or let expressions for the moment):
```js
let a;
{
[...]
a = result;
}
```
Correct me if I am
-Original Message-
From: Andy Wingo [mailto:wi...@igalia.com]
Sent: Monday, April 29, 2013 11:56 AM
To: Ron Buckton
Cc: Brendan Eich; es-discuss
Subject: Re: yield* desugaring
On Mon 29 Apr 2013 19:25, Ron Buckton rbuck...@chronicles.org writes:
The desugaring for yield* in
Andy Wingo wrote:
close() does not seem to have much value given that it isn't part of the
iterators specification, and one can do any needed action by doing a
throw() on the iterator and relying on the generator to have a finally
block if needed.
But throwing has other unwanted effects, in
-Original Message-
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Monday, April 29, 2013 11:21 AM
To: Ron Buckton
Cc: Mark Miller; David Sheets; Mark S. Miller; es-discuss; public-script-
co...@w3.org; David Bruant; Dean Tribble
Subject: Re: A Challenge Problem for Promise
On Mon, Apr 29, 2013 at 1:07 PM, Ron Buckton rbuck...@chronicles.org wrote:
I updated [1] my rough implementation of Future based on this discussion.
This has the following changes from the previous [2] version which was based
on the DOM spec for Future:
* The resolver's resolve algorithm
-Original Message-
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Monday, April 29, 2013 1:20 PM
To: Ron Buckton
Cc: Mark Miller; David Sheets; Mark S. Miller; es-discuss; public-script-
co...@w3.org; David Bruant; Dean Tribble
Subject: Re: A Challenge Problem for Promise
Norbert--
Finally had a chance to read this in detail and respond to it. Sorry it too so
long, and sorry I couldn't make it to the last ad-hoc meeting; let's just say
things have been stressful here at work recently. I still haven't had a chance
to look at the minutes from the ad-hoc
I've created separate gists for three different ways that I am currently
investigating as a means to support the cancellation of a Future. These can be
found here:
1. Cancellation using Future: https://gist.github.com/rbuckton/5486149
2. Cancellation using Future.cancelable:
29 matches
Mail list logo
