Re: Module naming and declarations

On Sat, Apr 27, 2013 at 12:22 AM, Kevin Smith wrote: > >> And note that Java also does not mandate reverse-DNS, it's just a >> convention. But in fact, that convention is really annoying and people hate >> it. Node uses much simpler global names that are reserved via NPM. This does >> lead to coll

Re: Module naming and declarations

> > One additional point on this topic. Even on the web, where there isn't > something like NPM as an arbiter for names, the JS community has > managed to use shared resources like the global object and the AMD > module name space effectively. > Facility of scale. If done correctly, we ought to h

Re: Module naming and declarations

> And note that Java also does not mandate reverse-DNS, it's just a > convention. But in fact, that convention is really annoying and people hate > it. Node uses much simpler global names that are reserved via NPM. This > does lead to collisions and some people don't like that; an alternative > sys

Re: Module naming and declarations

Claus Reinke wrote: but do you think users are going to rewrite their code bases twice just because modules are going to be delivered in two stages? What are you talking about? People are not going to rewrite more than once. Current NPM/AMD modules do not nest, so there's no basis for asserti

Re: Module naming and declarations

On Fri, Apr 26, 2013 at 7:17 PM, David Herman wrote: > On Apr 26, 2013, at 7:27 AM, Kevin Smith wrote: > > I'm not understanding how this strategy will facilitate namespace > > coordination. I can > > only see it leading to namespace confusion. > > There is, of course, a need for people to agr

RE: Futures

I have an implementation in Typescript/ES5 at https://github.com/rbuckton/promisejs/tree/master/Variations with a test suite that can be run from node. Ron Sent from my Windows Phone From: Kevin Smith Sent: ‎4/‎26/‎2013 11:47 AM To:

Re: Module naming and declarations

On Apr 26, 2013, at 7:27 AM, Kevin Smith 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 working? From a namespace perspective, how is that any different than > hanging ident

Re: Module naming and declarations

On Apr 26, 2013, at 7:20 AM, Claus Reinke wrote: > You believe you have worked out the core parts that caused you to > postpone lexical modules, We're still on the hook to finish a "wiki-complete" design of the core by the May meeting. I'm a busy guy. Dave

Re: Promises in E (was Re: A Challenge Problem for Promise Designers)

Thanks for making these issues clearer to me Mark. I am beginning to get some idea of the problems that JS promises face given that they must have an object-like appearance. I like the fact that in E, promises "just work" and I think of Joule as a language where every value is a promise and c

Re: More accurate global object definition?

The right place to discuss this is probably in [3] below. On Apr 27, 2013, at 12:13 AM, David Bruant wrote: > Hi, > > ES5 remains pretty vague as far as the global object is concerned [1]. > Specifically, the [[Class]] is left to the implementation suggesting No, [[Class]] does not suggest a

More accurate global object definition?

Hi, ES5 remains pretty vague as far as the global object is concerned [1]. Specifically, the [[Class]] is left to the implementation suggesting that internal [[Get]], [[Set]], etc. are unbounded on what they can do. For instance, when doing "this.Object", an implementation could do anything a

Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 1:39 PM, Tab Atkins Jr. wrote: > On Fri, Apr 26, 2013 at 6:36 AM, David Bruant wrote: >> Le 26/04/2013 14:54, Kevin Smith a écrit : >>> >>> What exactly is the controversy here? >>> >>> I think we all agree with the semantics of "then" as specified in >>> Promises/A+. (If

Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 1:45 PM, Domenic Denicola wrote: > From: Tab Atkins Jr. [jackalm...@gmail.com] >> Shorter me: this is why I keep asking people who want flattening to actually >> provide an example of where flattening is useful, that isn't (a) >> assimilation, (b) a result of weird langua

RE: A Challenge Problem for Promise Designers

From: Tab Atkins Jr. [jackalm...@gmail.com] > Shorter me: this is why I keep asking people who want flattening to actually > provide an example of where flattening is useful, that isn't (a) > assimilation, (b) a result of weird language semantics from some non-JS > language, or (c) an authoring

Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 1:39 PM, Tab Atkins Jr. wrote: [snip] > No. Future callbacks can return Futures, which then chain (the return > value of then adopts the state of the callback's return value). This > is the big "monad" benefit that we keep talking about. [snip] Shorter me: this is why I

Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 6:36 AM, David Bruant wrote: > Le 26/04/2013 14:54, Kevin Smith a écrit : >> >> What exactly is the controversy here? >> >> I think we all agree with the semantics of "then" as specified in >> Promises/A+. (If not, then we have a really big problem!) >> >> If so, then the

Re: A Challenge Problem for Promise Designers

Le 26/04/2013 21:47, Domenic Denicola a écrit : From: David Bruant [bruan...@gmail.com] Which naturally leads to the question: why should platform promises be compatible with Promise/A+ and not jQuery "promises"? Because more libraries use Promise/A+? what about market share? I realize I was

Re: Futures

On Fri, Apr 26, 2013 at 11:44 AM, Juan Ignacio Dopazo wrote: > 2013/4/26 Tab Atkins Jr. >> >> On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith >> wrote: >> > Actually, I may have gotten it terribly wrong (apologies). In my >> > prototype >> > implementation, the following: >> > >> > Future.acc

Re: Futures

> > The difference would only surface when testing that case. > > Not quite. You can still have thenables that call `onFulfilled` with > another thenable, to any depth. You can also insert a real promise at the > end of any-length thenable chain. I understand now. Essentially, in the test you cr

Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 3:47 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > From: David Bruant [bruan...@gmail.com] > > > Which naturally leads to the question: why should platform promises be > compatible with Promise/A+ and not jQuery "promises"? Because more > libraries use Promis

Re: additional Math function

We did talk about Math.imul, Dave presented it briefly IIRC last fall. It's a bite-sized win. Should be able to get it into ES6. /be Rick Waldron wrote: Filed https://bugs.ecmascript.org/show_bug.cgi?id=1452 On Fri, Apr 26, 2013 at 2:01 PM, Oliver Hunt > wrote:

RE: A Challenge Problem for Promise Designers

From: David Bruant [bruan...@gmail.com] > Which naturally leads to the question: why should platform promises be > compatible with Promise/A+ and not jQuery "promises"? Because more libraries > use Promise/A+? what about market share? What we're discussing is not *compatibility* but *ability to

RE: Futures

From: Kevin Smith [zenpars...@gmail.com] >>> Yes, sorry. It will on version 1.1: >>> https://github.com/promises-aplus/promises-spec/#the-promise-resolution-procedure >> To clarify: in 1.0, the behavior of returning a thenable was highly >> underspecified, in part because of a lack of clarity a

Re: Futures

> > > Yes, sorry. It will on version 1.1: > https://github.com/promises-aplus/promises-spec/#the-promise-resolution-procedure > > To clarify: in 1.0, the behavior of returning a thenable was highly > underspecified, in part because of a lack of clarity about promises vs. > thenables. In 1.1, return

Re: A Challenge Problem for Promise Designers

Le 26/04/2013 20:36, Rick Waldron a écrit : The libraries discussed in this and similar threads have the benefit of very limited adoption, where breaking changes incur minimal costs. jQuery doesn't have that luxury ;) [0] and therefore won't break backward compatibility. I can assure you that w

Re: What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

Le 26/04/2013 20:39, Domenic Denicola a écrit : I think this is a really good description of the problems and possible solutions. Unfortunately, I think you underestimate the problems. Where should this wrapping occur? Each library can add a check+convert to all surface API. It doesn't sound

RE: Futures

From: Juan Ignacio Dopazo [dopazo.j...@gmail.com] > 2013/4/26 Kevin Smith Oops yeah. I guess that should be fixed. :/ >>> Fixing that would break compatibility with Promises/A+. To remain >>> compatible with A+ and unwrap only one layer, the spec would need a way to >>> discern promis

Re: Futures

On Fri, Apr 26, 2013 at 12:24 PM, Alex Russell wrote: > On Apr 26, 2013 8:33 PM, "Tab Atkins Jr." wrote: >> On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith >> wrote: >> > Actually, I may have gotten it terribly wrong (apologies). In my >> > prototype >> > implementation, the following: >> > >> >

Re: Futures

2013/4/26 Kevin Smith > > Oops yeah. I guess that should be fixed. :/ >>> >> >> Fixing that would break compatibility with Promises/A+. To remain >> compatible with A+ and unwrap only one layer, the spec would need a way to >> discern promises from thenables. >> > > I don't think so. It has no

Re: Futures

On Apr 26, 2013 8:33 PM, "Tab Atkins Jr." wrote: > > On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith wrote: > > Actually, I may have gotten it terribly wrong (apologies). In my prototype > > implementation, the following: > > > > Future.accept(Future.resolve(1)).then(value => { > > > >

Re: What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

On Fri, Apr 26, 2013 at 12:17 PM, Juan Ignacio Dopazo wrote: > 2013/4/26 Mark Miller >> On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg >> wrote: >> [...] >> the term "future" >> > What are the chances of the WHATWG renaming the spec to DOMPromise? Let's please, everyone, ignore the naming

Re: Futures

> Oops yeah. I guess that should be fixed. :/ >> > > Fixing that would break compatibility with Promises/A+. To remain > compatible with A+ and unwrap only one layer, the spec would need a way to > discern promises from thenables. > I don't think so. It has no bearing on Promises/A+, because A+ d

Re: What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

2013/4/26 Mark Miller > On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg > wrote: > [...] > >> >> the term "future" > > What are the chances of the WHATWG renaming the spec to DOMPromise? Juan ___ es-discuss mailing list es-discuss@mozilla.org htt

Re: Futures

2013/4/26 Anne van Kesteren > > If resolve called the thenable's then() with accept and reject, it would > only unwrap one layer. > > Oops yeah. I guess that should be fixed. :/ > Fixing that would break compatibility with Promises/A+. To remain compatible with A+ and unwrap only one layer, th

Re: Futures

On Fri, Apr 26, 2013 at 7:44 PM, Juan Ignacio Dopazo wrote: > I think Kevin's assertion is correct. According to the spec, callbacks are > wrapped in something called a "future wrapper callback". When a promise is > returned from the callback, the wrapper does this: > >> Let value be the result of

Re: Futures

> If resolved called the thenable's then() with *accept *and reject, it > would only unwrap one layer. > > Good spec googles (I think). I just whiteboarded it and came to the same conclusion. Does anyone else have a prototype implementation they can run this program on? { Kevin } ___

Re: Futures

On Fri, Apr 26, 2013 at 7:25 PM, Kevin Smith wrote: > Future.accept(Future.resolve(1)).then(value => { > > console.log(value !== 1); > return Future.accept(Future.resolve(1)); > > }).then(value => { > > console.log(value === 1); > }); > > logs > > - true > - tru

Re: additional Math function

Filed https://bugs.ecmascript.org/show_bug.cgi?id=1452 On Fri, Apr 26, 2013 at 2:01 PM, Oliver Hunt wrote: > I landed support for Math.imul in JSC yesterday as well. > > Can't find actual documentation on the expected behavior so just copied > what mozilla does. > > --Oliver > > On Apr 26, 2013

Re: Futures

2013/4/26 Tab Atkins Jr. > On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith > wrote: > > Actually, I may have gotten it terribly wrong (apologies). In my > prototype > > implementation, the following: > > > > Future.accept(Future.resolve(1)).then(value => { > > > > console.log(value !=

RE: What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

I think this is a really good description of the problems and possible solutions. Unfortunately, I think you underestimate the problems. > Where should this wrapping occur? Each library can add a check+convert to all > surface API. It doesn't sound that hard (library authors can jump in to say

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

On Apr 26, 2013 1:03 PM, "Domenic Denicola" wrote: > > From: Tab Atkins Jr. [jackalm...@gmail.com] > > > The need for this will decrease now that DOM Futures exist, and libraries switch to using those (or a subclass of them) rather than rolling bespoke promises. > > Last I heard, jQuery has commit

Re: Futures

On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith wrote: > Actually, I may have gotten it terribly wrong (apologies). In my prototype > implementation, the following: > > Future.accept(Future.resolve(1)).then(value => { > > console.log(value !== 1); > return Future.accept(Future.r

Re: What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

On Fri, Apr 26, 2013 at 8:58 AM, Mark Miller wrote: > On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg > wrote: >> Let me note that this is not the fundamental controversy (not for me, >> anyway). The fundamental controversy is whether there should be any >> irregularity at all, as is unavoidabl

Re: Futures

Actually, I may have gotten it terribly wrong (apologies). In my prototype implementation, the following: Future.accept(Future.resolve(1)).then(value => { console.log(value !== 1); return Future.accept(Future.resolve(1)); }).then(value => { console.log(value ===

Re: What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

Le 26/04/2013 17:58, Mark Miller a écrit : However, the need for assimilation is history dependent. If there is another plausible-enough path to adoption and widespread use of promises that does not require assimilation, I would be very happy. But I have not found any of the alternatives posted

Re: Futures

On Fri, Apr 26, 2013 at 11:03 AM, Kevin Smith wrote: > The current DOM spec, in code: Or, much more simply: * Future.accept takes a Foo and returns a Future. * Future.resolve takes either a Foo or a Future. In either case, it returns a Future. * In Future.then(cb), the cb is expected to have the

Re: Futures

The current DOM spec, in code: Future.resolve(1).then(value => { value === 1; // Return a non-promise return 2; }).then(value => { value === 2; // Return a promise for a non-promise return Future.resolve(3); }).then(value => {

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 10:03 AM, Domenic Denicola wrote: > From: Tab Atkins Jr. [jackalm...@gmail.com] >> The need for this will decrease now that DOM Futures exist, and libraries >> switch to using those (or a subclass of them) rather than rolling bespoke >> promises. > > Last I heard, jQuery

Re: additional Math function

I landed support for Math.imul in JSC yesterday as well. Can't find actual documentation on the expected behavior so just copied what mozilla does. --Oliver On Apr 26, 2013, at 10:58 AM, Rick Waldron wrote: > > On Apr 26, 2013 8:42 AM, "Tom Schuster" wrote: > > > > Math.imul support was jus

Re: additional Math function

On Apr 26, 2013 8:42 AM, "Tom Schuster" wrote: > > Math.imul support was just added to the v8 trunk: > https://code.google.com/p/v8/source/detail?r=14450. > Is there any ongoing effort to standardize it? > As with Firefox, which you actually implemented :) https://bugzilla.mozilla.org/show_bug.c

Re: Futures

On Fri, Apr 26, 2013 at 9:01 AM, David Sheets wrote: > Domenic points out > > that DOM Futures currently do a recursive resolution which seems to > violate these equivalences. I also don't see anything about these > equ

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

From: Tab Atkins Jr. [jackalm...@gmail.com] > The need for this will decrease now that DOM Futures exist, and libraries > switch to using those (or a subclass of them) rather than rolling bespoke > promises. Last I heard, jQuery has committed to never switching their promises implementation to

Re: A Challenge Problem for Promise Designers

Le 26/04/2013 17:25, Tab Atkins Jr. a écrit : On Fri, Apr 26, 2013 at 3:19 AM, David Bruant wrote: Your abstract example was: If Future> can exist, then you'll have to write this boilerplate code in a lot of places: f.then(function res(v){ if(Future.isFuture(v)){ v.th

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 8:45 AM, David Sheets wrote: >>> Could you point me to some code that needs dynamic flattening? >> >> From >> https://github.com/promises-aplus/promises-spec/issues/101#issuecomment-16657518 >> >>> ```js >>> var promise = getDataFromServerUsingQ().then(function (data) { >>

Re: Futures (was: Request for JSON-LD API review)

On Apr 24, 2013, at 9:17 PM, Ron Buckton wrote: > Be it Promise or Future, instanceof won’t work across frames. It would likely > still require a Future.isFuture/Promise.isPromise just as we need to have > Array.isArray now. That is, of course, unless we can use symbols for branding > in a fas

Re: Promises in E (was Re: A Challenge Problem for Promise Designers)

Hi Bill, I think I know what you mean by these terms, and what I think you mean is correct ;). But given the history of promises and futures, you make two unfortunate and confusing terminology choices: "forced" and "wait". Instead, E promises, like all JS promises, are inherently non-blocking. The

Re: Futures

On Tue, Apr 23, 2013 at 11:30 PM, Tab Atkins Jr. wrote: > On Tue, Apr 23, 2013 at 11:25 AM, David Sheets wrote: >> On Tue, Apr 23, 2013 at 7:02 PM, Tab Atkins Jr. wrote: >>> On Tue, Apr 23, 2013 at 6:12 AM, David Bruant wrote: Anyway, my point was that there exist libraries in which "then"

What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg wrote: [...] > Let me note that this is not the fundamental controversy (not for me, > anyway). The fundamental controversy is whether there should be any > irregularity at all, as is unavoidably introduced by implicit > flattening. The problem y

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 4:03 PM, Domenic Denicola wrote: > From: David Sheets [kosmo...@gmail.com] > >> Why is there a semantic distinction between my thenables and your thenables? > > Because your thenables are not to be trusted! They could do pathological > things like jQuery, or conceptually i

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 3:19 AM, David Bruant wrote: > Le ven. 26 avril 2013 11:43:35 CEST, Andreas Rossberg a écrit : >> On 26 April 2013 10:54, David Bruant wrote: >>> The Priority of Constituencies [1] asks us to be remain careful about >>> theoretical standpoints. How does the theoretical par

Re: A Challenge Problem for Promise Designers

On 26 April 2013 16:25, Dean Landolt wrote: > The fundamental controversy, as Juan just noted, is how to precisely > identify a promise in order to do either of these two things. This problem > isn't quite so clean cut, but it's much more important to solve. I've been > trying to bring some attent

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

From: David Sheets [kosmo...@gmail.com] > Why is there a semantic distinction between my thenables and your thenables? Because your thenables are not to be trusted! They could do pathological things like jQuery, or conceptually incoherent things like thenables-for-thenables. Sanitation at the b

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 3:27 PM, Domenic Denicola wrote: > From: David Sheets [kosmo...@gmail.com] > >> From my reading, DOM Futures doesn't state anything about resolution >> semantics, to its detriment, but abstracts those semantics behind >> `FutureResolver`. > > This is not correct. See "Let

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

> > > Promise/A+ does not prohibit promises for promises. But in practice the > problem is recognizing what is a promise. > I would say rather that we have two orthogonal, but highly interfering issues: 1. Do we allow promises-(for-promises)+? 2. How do we recognize a promise type within the "res

RE: Module naming and declarations

From: Kevin Smith [zenpars...@gmail.com] > 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 working? From a namespace perspective, how is that any different than > hanging identifiers o

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

From: David Sheets [kosmo...@gmail.com] > From my reading, DOM Futures doesn't state anything about resolution > semantics, to its detriment, but abstracts those semantics behind > `FutureResolver`. This is not correct. See "Let resolve be a future callback for the context object and its resol

Re: Module naming and declarations

Hi Sam, Thanks for this long explanation. I have several thoughts, but I'd like to ask one thing in particular. 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 working? From a namespace per

Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 9:36 AM, David Bruant wrote: > Le 26/04/2013 14:54, Kevin Smith a écrit : > >> What exactly is the controversy here? >> >> I think we all agree with the semantics of "then" as specified in >> Promises/A+. (If not, then we have a really big problem!) >> >> If so, then the

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 3:20 PM, David Sheets wrote: >> 2013/4/26 Kevin Smith >>> >>> What exactly is the controversy here? > > I believe the controversy is over the number of resolution iterations > for a given wrapped value. > >>> I think we all agree with the semantics of "then" as specified i

Re: Module naming and declarations

You argue for a two-level system of non-lexical names to support configuration - okay. But why does that imply you have to drop the lexical naming altogether, instead of using a three-level system (from external to internal to lexical names)? You don't, it's an orthogonal concern. Note that Sam

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

> 2013/4/26 Kevin Smith >> >> What exactly is the controversy here? I believe the controversy is over the number of resolution iterations for a given wrapped value. >> I think we all agree with the semantics of "then" as specified in >> Promises/A+. (If not, then we have a really big problem!)

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

From: David Bruant [bruan...@gmail.com] > Thoughts? Since this entire problem seems predicated on Claus's misunderstanding of the term "thenable," which apparently has no basis in real libraries but instead entirely in wishful thinking, it might be more prudent for him to use the term "monad"

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Le 26/04/2013 15:47, Claus Reinke a écrit : My own argument is not for nested futures themselves, but (1) for futures to offer the same interface (.of, .then) as other thenables, which (2) implies that there is to be no implicit lifting or flattening in .then. For promises, I don't expect to u

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

So there are no such libraries, and you are just wishing that they existed and that they took over the meaning of `then` from promises? From: Claus Reinke [claus.rei...@talk21.com] Sent: Friday, April 26, 2013 10:11 To: Domenic Denicola; Mark Miller; David

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Can you point to any code in wide use that makes use of this "thenables = monads" idea you seem to be implicitly assuming? Perhaps some of this "generic thenable library code"? I have never seen such code, whereas the use of "thenable" to mean "object with a then method, which we will try to tre

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

I'm still wading through the various issue tracker threads, but only two concrete rationales for flattening nested Promises have emerged so far: 1 "library author doesn't want nested Promises." 2 crossing Promise library boundaries can create unwanted nesting Perhaps you didn't read my post then?

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

2013/4/26 Kevin Smith > What exactly is the controversy here? > > I think we all agree with the semantics of "then" as specified in > Promises/A+. (If not, then we have a really big problem!) > Promise/A+ does not prohibit promises for promises. But in practice the problem is recognizing what i

Re: A Challenge Problem for Promise Designers

On 26 April 2013 14:29, David Bruant wrote: > Le 26/04/2013 13:24, Andreas Rossberg a écrit : >> I'm not sure if your description of E is accurate -- I'd find that >> surprising. It _is_ a perfectly sensible design to have transparent >> futures that you can just use in place of the value they eve

Re: A Challenge Problem for Promise Designers

Le 26/04/2013 14:54, Kevin Smith a écrit : What exactly is the controversy here? I think we all agree with the semantics of "then" as specified in Promises/A+. (If not, then we have a really big problem!) If so, then the only real controversy is whether or not the API allows one to create a

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 9:28 AM, Alex Russell wrote: > Yes, you do. > Mark or Domenic, is the point about Q true as well? (That it could, in principle, provide something like Future.accept, but it chooses not to.) Just wanted to check before I say somethin' foolish : ) { Kevin } ___

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Yes, you do. On Apr 26, 2013 2:54 PM, "Kevin Smith" wrote: > What exactly is the controversy here? > > I think we all agree with the semantics of "then" as specified in > Promises/A+. (If not, then we have a really big problem!) > > If so, then the only real controversy is whether or not the API

Promises in E (was Re: A Challenge Problem for Promise Designers)

Let me take a crack at describing E's support for promises. E has two modes for sending a message to an object. There is the immediate send and the eventual send. If the Object is an unresolved promise the immediate send will trap. (A promise can be forced to resolve using the "when" construct

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

What exactly is the controversy here? I think we all agree with the semantics of "then" as specified in Promises/A+. (If not, then we have a really big problem!) If so, then the only real controversy is whether or not the API allows one to create a promise whose eventual value is itself a promis

Re: additional Math function

Math.imul support was just added to the v8 trunk: https://code.google.com/p/v8/source/detail?r=14450. Is there any ongoing effort to standardize it? On Fri, Nov 2, 2012 at 9:24 PM, Brendan Eich wrote: > David Herman wrote: >> >> On Nov 2, 2012, at 12:05 PM, Yehuda Katz wrote: >> >>> Seems like a

Re: A Challenge Problem for Promise Designers

Le 26/04/2013 13:24, Andreas Rossberg a écrit : On 26 April 2013 12:19, David Bruant wrote: In particular, irregularity and exceptions become a pain when you start building abstractions, or plug together abstractions. In other words, regularity is a prerequisite for what some people (including

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On 26 April 2013 12:19, David Bruant wrote: >> In particular, irregularity and exceptions become a pain >> when you start building abstractions, or plug together abstractions. >> In other words, regularity is a prerequisite for what some people >> (including me) like to call "compositionality". >>

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

[adding public-script-coord and Anne] Le ven. 26 avril 2013 11:43:35 CEST, Andreas Rossberg a écrit : On 26 April 2013 10:54, David Bruant wrote: The Priority of Constituencies [1] asks us to be remain careful about theoretical standpoints. How does the theoretical part translates into helpin

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On 26 April 2013 10:54, David Bruant wrote: > The Priority of Constituencies [1] asks us to be remain careful about > theoretical standpoints. How does the theoretical part translates into > helping users? authors (more than what I described at [2] which is derived > from my own experience)? imple

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Le 26/04/2013 03:39, Tab Atkins Jr. a écrit : On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble wrote: So what's an example that motivates you to want to build a tower of promise types? The main one I know of is the implementation (not use of) higher-order collection constructs that use promises i

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

A Future for a Future seems like a corner case compared to the broader simplicity of an implicit unwrap. The argument is not about whether Future> is a common case. The Argument is that Future<...> and Array<...> and Optional<...> and things that may raise catchable errors and other types have

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Le 26/04/2013 00:21, Claus Reinke a écrit : I'm still wading through the various issue tracker threads, but only two concrete rationales for flattening nested Promises have emerged so far: 1 "library author doesn't want nested Promises." 2 crossing Promise library boundaries can create unwanted

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Something that wasn't clear to me personally until reading the last few posts: I suspect that some of the negative reaction to unwrapping/wrapping, and the suggestion that Future> is a meaningful construct, comes from the mindset of static typing - not in the sense that static types themselves are