able faster enqueuing on newer
browsers.
On 10/21/2011 10:34 AM, John J Barton wrote:
Can anyone summarize how these proposals relate to Kris Kowal / Kris
Zyp / Mark Miller Q library:
https://github.com/kriskowal/q
The proposal was designed such that it should work smoothly with Kowal's
On 10/19/2011 12:29 PM, Dean Landolt wrote:
This is a really great idea, Kris! A few comments inline...
[snip]
If the value is not an object with a "then" property that is a
function, the operand value is the immediate result of the
evaluation of the "yield" expression and executio
The topic of single-frame continuations has been discussed here before,
with the current state of ES.next moving towards generators that are
based on and similar to Mozilla's JS1.7 implementation. Generators are a
powerful addition to the language and welcome (at least by me). However,
I believ
On 1/28/2011 8:43 PM, Mark S. Miller wrote:
> On Fri, Jan 28, 2011 at 6:05 AM, Kris Zyp <mailto:k...@sitepen.com>> wrote:
>
>
> Exactly. On the NodeJS mailing list there is constant,
> never-ending stream of messages from (generally new users) who are
> co
On 1/27/2011 10:37 PM, Mark S. Miller wrote:
> On Thu, Jan 27, 2011 at 8:23 PM, Kris Zyp <mailto:k...@sitepen.com>> wrote:
>
> This looks like a case of creating in-language for a library. This
> was done with json2.js because it was one of the most widely us
This looks like a case of creating in-language for a library. This was
done with json2.js because it was one of the most widely used libraries
in existence and similar JSON handlers were used in numerous libraries.
The ref_send library and sibling Q style implementations are not
anywhere close to t
aScript object
> model it enables JavaScript programmers to create a number of
> different information hiding abstractions.
>
> Please read the proposal and let's start the discussion.
>
> Allen
>
>
>
>
> ___
> es
>>
>> The special behavior is that in between each part/expression of
>> the statement, evaluation of the statement itself (NOT the rest
>> of the program) may be "suspended" until the previous
>> part/expression is fulfilled. This would conceptually be like
when the
JS VM requests a module needed by the loading module?
- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzUVkkACgkQ9VpNnHc4zAxkxQCeM5mIrcgpa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/5/2010 12:31 PM, Sam Tobin-Hochstadt wrote:
> On Fri, Nov 5, 2010 at 2:25 PM, Kris Zyp wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> Another idea that might provide the extensibility to d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Another idea that might provide the extensibility to deal with loading
various resources and alternate/older modules, what if we added the
ability to specify the loader to use for a module:
module myApp {
module Template = load "template.html" wit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/2010 11:42 AM, Brendan Eich wrote:
> On Nov 4, 2010, at 10:20 AM, Kris Zyp wrote:
>
>> the entire design space. If that is incompatible, so be it. But
>> if the current proposal can desugar and provide a smooth
>> t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/2010 11:13 AM, Alex Russell wrote:
>
> On Nov 4, 2010, at 6:22 AM, Kris Zyp wrote:
>
>>
> I've been meaning to make some comments about simple modules and
> in last minute with Brendan, he noted that he wanted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/2010 8:02 AM, Sam Tobin-Hochstadt wrote:
> On Thu, Nov 4, 2010 at 9:22 AM, Kris Zyp wrote:
>
>> I believe it should be a requirement that harmony
>> modules (or at least a subset of them) should be desugarable into ES5
these thoughts, if more formal
proposals on anything would help, I'd be glad to put something together.
[1] http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition
- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-BEGIN PGP SIGNATURE-
Version:
I am opposed to the notion of appending the continuation resume
>> function on to the list of arguments.
>
> I pretty much agree with this point. But the bigger fish to fry is the
basic control flow story.
Cool, then I think we are mostly in agreement on how ->
it shifts all the other arguments. If we are going to be passing
the continuation function to the yielding callee function, lets drop
the whole notion of trying to make it look like a call, and have the
yielding call operator take a single value for the right operand
rather than an argument list
as possible, anyway.
In addressing your other issues, like I said to Waldemar, would it be
reasonable to start with a definition and sample translation of JS1.7
generators (since I believe we all understand those) and then look at
possible incremental changes to make it more broadly useful
port that we want, they just need
a more generalizable API, so they can be used for more than just
generators.
- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEA
ng = false;
return handleResult(resume());
});
}
else{
return handleResult(controller.resume(function(){
return value;
}));
}
}
return handleResult(controller.resume());
}
And the library functions defined above (Continuation
ibility
check that single-frame continuations should be simpler and more general
than generators, and likely compatible with them.
Yes, I believe that should work.
Do you prefer basing single-frame continuations on new non-latin
character syntax instead of using the "yield" keyword (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Herman's comment about JS1.7 generators spurred me to consider
if we could achieve the goals stated for single-frame continuations as
a broadly useful mechanism for replacing CPS code with more natural
flow for constructs like promises and one-t
pression).
>>>
>>> Is this supposed to fall through?
>>>
>> Yes
>
> That can't be true, can it? If step 6 continues to step 7 then we
> get:
>
> // step 5 if (!($result && typeof $result.continueWith ===
> "function")) { // d
at could be called to signal an exception
to be thrown (at least in the case of the yielding operator being
called within a try block). And with this correction, this change
isn't really much simpler, I don't think.
Also, just to be clarify the behavior of NarrativeJS, it uses a much
!== returnValue){
throw StopIteration;
}
}
// return the iterator for this generator
return {
send: send,
next: function(){
return send();
},
&qu
tructure,
>except for the important issue of reduced memory usage.
>
> - processes can have shared access to declarative structures --
>that is, structures that can be extended but not mutated.
>This is in practice relatively easy to reason about, and does
>not introd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
>
>> You are saying there latent hard-to-find bugs because people believe
>> that JSON somehow implies that the sum of {"p":1.1, "q":2.2} must be
>> 3.3003 ?
>
> I never wrote any such thing.
>
> Please look at the previous messages aga
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brendan Eich wrote:
> On Jan 15, 2009, at 10:46 AM, Kris Zyp wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> Brendan Eich wrote:
>>> On Jan 15, 2009, at 9:47 AM, Kris Zyp wrote:
>&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brendan Eich wrote:
> On Jan 15, 2009, at 9:47 AM, Kris Zyp wrote:
>
>> Where is the loss coming from?
>
> Decimal-using peer S1 encodes
>
> {p:1.1, q:2.2}
>
> Double-using peer C1 decodes, adds, and returns
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Ippolito wrote:
> On Thu, Jan 15, 2009 at 5:49 AM, Kris Zyp wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>>
>>
>> Bob Ippolito wrote:
>>> On Wed, Jan 14, 2009 at 9:32 PM, Kris Z
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Ippolito wrote:
> On Wed, Jan 14, 2009 at 9:32 PM, Kris Zyp wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>>
>>
>> Brendan Eich wrote:
>>> On Jan 14, 2009, at 7:38 PM, Kris Zyp wrote
y be considered in the decision process.
As far as JSON goes, Dojo will encode decimals to numbers, there is
really no coherent alternative (encoding to strings would be even more
bizarre, and I can't think of any other option).
Kris
Brendan Eich wrote:
> On Jan 14, 2009, at 9:32 PM, Kris
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brendan Eich wrote:
> On Jan 14, 2009, at 7:38 PM, Kris Zyp wrote:
>
>>>>> You need to change this in any case, since even though the
>>>>> JSON
>>>> RFC allows arbitrary precision decimal literals
rs.
> That's life in the big Dojo city.
If that's true, that's fine, I have no problem with Dojo feeling the
pain for the sake of others, but I still find it very surprising that
Dojo code would be so misrepresentative of real code out there today.
Dojo covers a very broad swath
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brendan Eich wrote:
> On Jan 9, 2009, at 3:08 PM, Kris Zyp wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>> The counter-argument is strong:
>>>
>>> typeof x == typ
; mailing list Es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkluHzcAC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> The counter-argument is strong:
>
> typeof x == typeof y => (x == y <=> x === y)
>
> but 1.1 != 1.1m for fundamental reasons.
I understand the counter-argument, but with such an overwhelming
number of typeof uses having far easier migration with
what that would look like in the
>> context of a 3.1 edition.
>>
>> From where I sit, I find myself in the frankly surreal position
>> that we are in early December, and there are no known issues of
>> consensus, though I respect that David-Sarah claims that there is
>
sible to define types for local
variables, typing local variables rarely adds useful information to
the analysis and integrity of a program, most type information can be
inferred. The unification of classes and typing greatly reduces the
overall complexity of the language.
4. Interactive pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arg, I responded to wrong email :/, I meant to reply to the one on
catchalls, that is the one I think is a very valuable feature.
Kris
Kris Zyp wrote:
> +1, I think this was one of the most valuable features from ES4.
> Kris
>
> Peter M
not just call them Symbol objects? There is
> precedence for "symbol" in many languages and "symbol" is far less
> overloaded in the programming world than "name".
>
> Peter
> ___
> Es-discuss mailing list
> Es-discuss@mozilla.org
> h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
FWIW, a little empirical data:
>
>> I think we should even consider banning local eval from strict
>> mode.
>
> In light of the examples I gave above, and more that are pretty
> easy to find, I think this would make strict mode unused in
> practice.
>
>> +1 for typeof 1m === 'number'. As an example of breakage, I believe
>> Crockford's current version of his JSON library would not do as I would
>> desire with decimals:
>>
>> JSON.stringify({foo:1m}) -> "{\"foo\":undefined}"
>
> Why is that worse than producing '{"foo":1}'?
The fact that you kn
>> * Like Crock, I prefer that typeof 1m === 'number'. However, unlike
>> Crock's
>> and Brendan's agreement, I think this should be unconditional. I think it
>> would be horrible for 'typeof X' to depend not only on the value of X but
>> also on the mode of the program unit in which the typeof ap
A lot of Ajax widgets, e.g. Dojo, use their own inheritance models, often
based on copying properties (sometimes based on prototypes; in the case of
Dojo's MI, both!). Copying is fine for a zero-inheritance classes-as-sugar
proposal. The prototype stuff, as Kris points out, is different.
T
>> I am surprised this is up for debate, I would also think that we would
>> want
>> instance-private by default.
>
> We can debate lots of things, some that might actually be in play. AFAIK
> this one is not decided in the committee (it's way too early), but IP
> does have some strong propon
> On Sun, Aug 24, 2008 at 5:10 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
>> [...] I believe it is still possible to emulate private instance
>> variables with prototypes (although much more awkward than with a
>> "private"
>> attribute). I could demo
>> I don't see why it is better to have classes be sugar for closured object
>> literals rather than prototype based structures. It seems the benefits
>> that
>> are being sought after are auto-binding on method extraction and private
>> method creation.
>
> I'm not sure what you mean by "private
.
Thanks,
Kris
> On Tue, Aug 19, 2008 at 9:15 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
>> Why do you freeze the functions? Is this just to cater to mutable
>> function
> > critics, or is there actually a reason tied class semantics?
>
> It is to cater to mutable functi
> function Point(x, y) {
>const self = Object.create(Point.prototype, {
>toString: {value: Object.freeze(function() ('<' + self.getX()
> + ',' + self.getY() + '>'))},
>enumerable: true},
>getX: {value: Object.freeze(function() x),
>enumerable: true},
>
50 matches
Mail list logo
