his choice, but was it intentional?
Nitpick: the '[ props, ...' notation could be misinterpreted as saying that
the previous 'props' list is the first element of the new list. It should be
something like 'props ++ [...'.
--
David-Sarah Hopwood ⚥ http://dav
On 2010-12-24 00:39, Brendan Eich wrote:
> On Dec 23, 2010, at 3:27 PM, David-Sarah Hopwood wrote:
>> On 2010-12-23 21:02, Brendan Eich wrote:
>>> On Dec 23, 2010, at 12:11 PM, Mark S. Miller wrote:
>>>
>>>> You've said this "apples to or
On 2010-12-24 00:11, David Herman wrote:
> On Dec 23, 2010, at 5:03 PM, David-Sarah Hopwood wrote:
>
>> On 2010-12-23 23:55, David Herman wrote:
>>> On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
>>>
>>>> We don't know whether [] will be
ng all properties as non-Configurable, and
marking all data properties as non-Writable.)
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
On 2010-12-23 23:55, David Herman wrote:
> On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
>
>> We don't know whether [] will be changed
>> at all. (In the proposal to add a @ or .# operator, it isn't.)
>
> Hm, this looks like a pretty serious mis
eople trying to tell me what "camp" I'm in, thankyou.)
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
;t see the relevance of that to the
'"apples to oranges" thing'. We don't know whether [] will be changed
at all. (In the proposal to add a @ or .# operator, it isn't.)
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digi
t "munches" the first dot before the '..' is tokenized.
Anyway, the use of '..' in E4X and as a range operator in other languages is
sufficient reason not to use it here.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: Open
bikeshed about this yet. Either .# or @ is fine
for discussion. ('.#' is perhaps more suited to being viewed as a
variant of '.' with a private field selector, and '@' as an operator
distinct from '.')
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.co
ies
effectively non-configurable and/or non-writable.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 2010-12-23 06:01, David-Sarah Hopwood wrote:
> On 2010-12-23 05:08, Brendan Eich wrote:
>> You seem to have problem owning up to mistakes.
>
> *I* have a problem owning up to mistakes?
>
> <https://secure.wikimedia.org/wikipedia/en/wiki/Psychological_projection>
I
On 2010-12-23 05:08, Brendan Eich wrote:
> On Dec 22, 2010, at 7:34 PM, David-Sarah Hopwood wrote:
>
>> As far as I can see, MarkM has not (at least, not on the wiki) proposed
>> any new syntax in this discussion that had not already been proposed in
>> one of Allen'
On 2010-12-23 05:14, Brendan Eich wrote:
> On Dec 22, 2010, at 7:49 PM, David-Sarah Hopwood wrote:
>
>> The constraint that the inspector be written in ES5 seems to be a purely
>> artificial one. All of the commonly used browsers have debugger extensions.
>
> Nope,
On 2010-12-23 02:48, Brendan Eich wrote:
> On Dec 22, 2010, at 6:39 PM, David-Sarah Hopwood wrote:
>
>> Inspectors can bypass encapsulation regardless of the language spec.
>
> The Inspector is written in ES5. How does it bypass soft field strong
> encapsulation?
I m
On 2010-12-23 01:11, Brendan Eich wrote:
> On Dec 22, 2010, at 3:49 PM, David-Sarah Hopwood wrote:
>
>>> In arguing about this, I have this bait-and-switch sense that I'm
>>> being told A+B, then when I argue in reply against B, I'm told "no, no!
>>>
On 2010-12-23 00:40, Brendan Eich wrote:
> On Dec 22, 2010, at 2:56 PM, David-Sarah Hopwood wrote:
>
>> What I said, paraphrasing, is that weak encapsulation favours code that
>> doesn't work reliably in cases where the encapsulation is bypassed.
>> Also, that
eclude also criticising the syntax.
If your criticisms of soft fields plus the change to [] depended on the fact
that the syntax change was layered on soft fields, then you might have a
point. But in fact those criticisms apply to the syntax change regardless
of which proposal it is layered on.
T
On 2010-12-22 07:57, Brendan Eich wrote:
> On Dec 21, 2010, at 10:22 PM, David-Sarah Hopwood wrote:
>> On 2010-12-21 22:12, Brendan Eich wrote:
>>
>>> It's tiresome to argue by special pleading that one extension or
>>> transformation (including generated s
ither the language's property
> access syntax
> ( . and []) as you have (perhaps reluctantly) proposed you have extended the
> conceptual object model.
Mark has criticized that syntax partly because it depends on extending the
object model, and so have I. I intend to propose
On 2010-12-21 22:12, Brendan Eich wrote:
> On Dec 20, 2010, at 11:05 PM, David-Sarah Hopwood wrote:
Please retain all relevant attribution lines.
>> Brendan Eich wrote:
>>> The new equivalence under private names would be x[#.id] === x.id.
You said "under private nam
e x.#foo to make it obvious that it's not
> the
> same as x.foo (also so you can write both in the same scope), and use
> "var bar = #foo /* or just foo */; x[#bar]" for computed private name lookup.
> I.e. effectively introducing
> ".#", "[#" as altern
On 2010-12-21 08:27, David-Sarah Hopwood wrote:
> The private names and soft field proposals are similar in the
> visibility mechanisms they can simulate, but soft fields are slightly
> more general. In either proposal, visibility can be restricted to a
> particular lexical scope.
at
<http://www.eros-os.org/pipermail/cap-talk/2007-June/007885.html>
uses WeakMaps to do this, and could just as well use soft fields if
transliterated to ECMAScript.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 2010-12-17 06:44, Brendan Eich wrote:
> On Dec 16, 2010, at 9:11 PM, David-Sarah Hopwood wrote:
>> On 2010-12-17 01:24, David Herman wrote:
>>> Mark Miller wrote:
>>>> Ok, I open it for discussion. Given soft fields, why do we need private
>>>> names?
s.
>
> Of these two use cases, the second may be the more important.
>
> Note that I emphasized "properties" rather than a new concept such as
> "private fields".
I think it is a mistake to emphasize that, since it overspecifies the
mechanism. In the sof
pecify the programmer's view of it. Of course the programmer's view needs
to be considered in the design, but as far as specification is concerned,
if a high-level feature cannot be specified by a fairly simple desugaring
to lower-level features, then it
eval should be specified from scratch, not based on what a
poorly thought-out vendor extension happens to do.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing lis
Brendan Eich wrote:
> On Jan 11, 2010, at 10:53 AM, David-Sarah Hopwood wrote:
>
>>> Who said primordial objects are shared between modules?
>>
>> Having separate copies of primordial objects for each module is not
>> sufficient to ensure isolation. If one module
Brendan Eich wrote:
> On Jan 11, 2010, at 4:37 PM, David-Sarah Hopwood wrote:
>> Kevin Curtis wrote:
>>> So, FF3.5 has resurrected the sandboxed eval with the second 'global'
>>> object parameter - as the closure peeking issue has been fixed. (The second
>
evelopers'
practice of adding unilateral language extensions without consulting anyone,
and in particular without consulting this list.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
__
David-Sarah Hopwood wrote:
> David-Sarah Hopwood wrote:
>> Brendan Eich wrote:
>>> On Jan 10, 2010, at 9:30 PM, David-Sarah Hopwood wrote:
>>>> Brendan Eich wrote:
>>>>> For many current applications, the frozen |this| object is not necessary
>
David-Sarah Hopwood wrote:
> Brendan Eich wrote:
>> On Jan 10, 2010, at 9:30 PM, David-Sarah Hopwood wrote:
>>> Brendan Eich wrote:
>>>> On Jan 10, 2010, at 1:14 AM, Kevin Curtis wrote:
>>>>
>>>>> From SecureEcmaScript proposal:
>>&
evaled code then it would avoid the closure
>> peeking issue.
>
> What's the "closure peeking issue"?
<http://code.google.com/p/google-caja/wiki/EvalBreaksClosureEncapsulation>
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich wrote:
> On Jan 10, 2010, at 9:30 PM, David-Sarah Hopwood wrote:
>> Brendan Eich wrote:
>>> On Jan 10, 2010, at 1:14 AM, Kevin Curtis wrote:
>>>
>>>> From SecureEcmaScript proposal:
>>>> 6. The top level binding of this in an evaled
mean no mutation of primordial objects.
On the contrary, it does necessarily mean that. If you can mutate
primordial objects, then there is no isolation of any module. There
may be a reduction in the possibilities for accidental interference
between modules, but that should be dis
I forgot the commas in the object literal:
David-Sarah Hopwood wrote:
> function makeGui(doc) {
> /*const*/ var title = doc.getElementById("title"),
> url = doc.getElementById("url"),
> input = doc.getElementById("input"
memo...@googlemail.com wrote:
> David-Sarah Hopwood wrote at 25th December:
>> and there is no need for a 'link' convenience function to be standardized
>> given that it is a 5-liner in terms of Object.defineProperty
>
> Just have a look at the following program
but not indefinitely. The feature is
already in ES5 for properties, it will not be added for local variables,
and there is no need for a 'link' convenience function to be standardized
given that it is a 5-liner in terms of Object.defineProperty.)
--
David-Sarah Hopwood ⚥ http://davids
Brendan Eich wrote:
> On Dec 15, 2009, at 11:18 AM, David-Sarah Hopwood wrote:
>> Brendan Eich wrote:
>>> In ES specs and real implementations, internal methods and various
>>> corresponding implementation hooks are called based on [[Class]] of the
>>> dir
o the dearth of short type-descriptive names
> available for use as local variable names. Consider: var html =
> html`...`;
One possibility is to make the tags uppercase by convention:
HTML`...`;
XML`...`;
SQL`...`;
Since language names are very often acronyms, this looks per
nternal method lookup; I don't know where you got that idea.
As for implementation, [[Class]] could be derived from some other type tag
that gives sufficient information to do such lookup, but [[Class]] by
itself is not sufficient.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.c
ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>.)
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
David-Sarah Hopwood wrote:
> Mark S. Miller wrote:
>> function isArrayLike(obj) {
>> var len;
>> return !!(obj &&
>> typeof obj === 'object' &&
>> 'length' in obj &&
>> !({}).
happen?
> And yes, I'm aware that this usage of Object.prototype.propertyIsEnumerable
> implies that catchalls must virtualize it in order for a proxy to be able to
> pass this test :(.
Same with Object.getPropertyDescriptor in the above.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
e message may not reach it).
This is probably a defect in E terminology that we shouldn't reproduce.
OTOH, the notification shouldn't be arbitrarily cancelled in situations
where events set using setTimeout wouldn't normally be cancelled.
--
side-effects (moving to the next element), it shouldn't
be a getter.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://ma
action described on the above page is ideal for
implementing caches. It doesn't require any extra work to explicitly remove
entries from the cache; they just go away when the key does.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signatur
oesn't get you anything substantial here as the
> hard part of all this is validation, not parsing.
That's not entirely accurate. In implementing Jacaranda, I estimate
the split of effort between validation/parsing has been about 60/40.
ECMAScript is really quite difficult to lex+parse
Breton Slivka wrote:
> On Tue, Dec 8, 2009 at 3:57 PM, David-Sarah Hopwood
> wrote:
>
>> That would however depend on an assessment of whether browser
>> implementors had succeeded in implementing secure and correct
>> ES5->AST parsers (with a mode that accepts ex
ce of that API (and the corresponding AST->source pretty-printing
API) is the main motivation for standardizing the format, AFAICS.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_
t and short-cuts for edge cases).
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ihab.a...@gmail.com wrote:
> On Mon, Dec 7, 2009 at 3:10 PM, David-Sarah Hopwood
> wrote:
>> ... programmers of AST-processing applications will see this
>> serialization when debugging, and it is likely to appear in test
>> cases for such applications and for parsers/emit
ations will see this serialization when
debugging, and it is likely to appear in test cases for such
applications and for parsers/emitters.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_
with?
Section 15,
# In every case, the length property of a built-in Function object
# described in this clause has the attributes [blah]. Every other
# property described in this clause has the attributes
# { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }
# unles
the other stuff they blacklist no longer
needs to be blacklisted in ES5-strict, but I'm not absolutely sure of that.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mai
be either Object Environment Records that each have
a prototype chain, or Declarative Environment Records.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
t a member
of TC39.
> -Original Message-
> From: es5-discuss-boun...@mozilla.org
> [mailto:es5-discuss-boun...@mozilla.org] On Behalf Of David-Sarah Hopwood
> Sent: Friday, November 20, 2009 7:18 PM
> To: es5-disc...@mozilla.org
> Subject: Re: ES5 left-to-right evaluation order issues
ures
or exceptional behaviour that users of the language could only find,
or even know to look for, by reverse engineering or guesswork. What's
the point? Doesn't it take more work to add all this stuff?)
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Descri
David-Sarah Hopwood wrote:
> Oliver Hunt wrote:
>> On Nov 5, 2009, at 10:14 PM, David-Sarah Hopwood wrote:
>>> Oliver Hunt wrote:
>>>> I disagree here -- i believe mutable vs. immutable data is different
>>>> from unfrozen and frozen objects
Oliver Hunt wrote:
> On Nov 5, 2009, at 10:14 PM, David-Sarah Hopwood wrote:
>> Oliver Hunt wrote:
>>> I disagree here -- i believe mutable vs. immutable data is different
>>> from unfrozen and frozen objects [...]
>>
>> Why? What would the hypothetical
Oliver Hunt wrote:
> On Nov 5, 2009, at 4:01 PM, David-Sarah Hopwood wrote:
>> Charles Jolley wrote:
>>> This looks like a good approach. I wonder if the Data/DataBuilder
>>> distinction could be handled better by using the Object.freeze()
>>> semantics.
not unreasonable
to require support for the ES5 APIs as a prerequisite for the Data type.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
:
>
> So you prefer ugly solutions, because the others are nasty?
Yes. Here "ugly" just means "verbose and inelegant", whereas "nasty"
means "having poorly understood and subtly error-prone consequences".
So ugly beats nasty every time :-)
- --
David-Sarah
t;IfStatement",
> ["CompareOperation",
> {"op":"GT"},
> ["VariableProxy",
> {"name":"x"}
> ],
> ["Literal",
> {"handle":0}
> ]
).
Well, JS doesn't have types in that sense. So, unless an implementation
were to exploit any internal optimizations it has for recognizing objects
of the same "shape" [*], it would indeed have to sort the keys of every
instance.
[*] Do any common implementations actually do tha
n general,
and the ones that it has, such as the get/set object literal syntax,
are taken unchanged from existing implementation precedent). I hope
that such a syntax will be included in Harmony, though, along with
more comprehensive Unicode library support.
--
David-Sarah Hopwood ⚥ http://dav
k that it is highly undesirable
to adopt an interpretation in which they can have arbitrary additional
inputs depending on the context in which they are used.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ogramming error. Programs without such
errors behave deterministically, and programs with such errors
deterministically fail, but the side-effects that occur before
they fail may be nondeterministic.)
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Maciej Stachowiak wrote:
> On Sep 27, 2009, at 11:14 AM, Brendan Eich wrote:
>> On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
>>> Brendan Eich wrote:
>>>> On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
>>>>
>>>>> This may p
; conversation. For example, the excellent posts by David-Sarah Hopwood <
> https://mail.mozilla.org/pipermail/es-discuss/2009-September/author.html#9879>
> have generally gotten responses only from the ECMA side. Some later messages
> from the W3C side seem to have missed some of [
Brendan Eich wrote:
> On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
>> Brendan Eich wrote:
>>> On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
>>>
>>>> This may provide a way to implement some of these behaviors in pure
>>>> ECMA
ndings to ECMAScript.
Some internal methods, like [[Call]] and [[Construct]], are relatively
safe to override, but for others the invariants that the ES spec depends
on are quite delicate.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discus
meToString(CurrentTime());
}
// constructor behaviour
...
}
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
; but if new APIs are equally problematic, they will be
unable to provide access to that functionality.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ood idea to define any new APIs similar to
HTMLCollection, that have the problem of names defined in HTML/XML/CSS
potentially colliding with ECMAScript method names (or method names in
other languages). Such APIs are confusing, error-prone, and detrimental
to forward compat
having it in Web IDL simplifies writing specifications for the (legacy)
> platform and removes room for error.
The suggestion was only to stop using the catch-all pattern for new APIs,
not to remove it.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
__
Brendan Eich wrote:
> On Sep 2, 2009, at 6:15 PM, David-Sarah Hopwood wrote:
>
>> Brendan Eich wrote:
>>> The spec can't yet define these "native wannabe" future standardization
>>> fodder objects, but clearly that's what Allen was thinking of, a
ined)
functions. I think it would be an overspecification to require any such
feature.
As Christian says, we might define a common interface for implementations
that do want to support this, but I don't think it requires changes to
language syntax. A
uch nicer without the T! And
> it would be a shame for ES to get stuck with the T while ISO and
> everyone who uses it moves away from the T.
+1. With a space instead of the T, the format is actually reasonably
pleasant to read.
--
David-Sarah Hopwood ⚥ http://dav
take over the world, right?
We security weirdos fully intend to take over the world.
You have been warned.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
var fn = evil('(function(event){' + attrValue + '})');
> return fn.call(element, e);
> }
> }
> }
> }
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
re highly error-prone, make too many assumptions about
implementation details (particularly memory management), and are not
suitable for wider use.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
number, something that is not
> true in reverse), users that desire different behavior can simply
> replace these operators. This could even be done globally (a big red
> switch, as Brendan seems to prefer).
It should be done within a specified
expansions, OTOH, this would probably
be adequate, assuming the check that the lambda is called from the body
of the generator function is applied *after* expansion.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing lis
gt; presence of it. Surely, this is not the first feature in ES that has
> that property - "if (0) var a;" is another example. But "if (0)
> yield;" sets a new record affecting the nature of the whole function.
A more explicit alternative is to require some
al experience).
>> Therefore, I argue that it would make sense to simplify a bit:
>> - the yield E form may be used when it is the entire expression of an
>> expression statement
>> - all other times it must be parenthesized
>
> Agreed; this closes the assignment ex
primitive value is accessed -- although I bet most
JS programmers don't even know that is happening.
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ch is used in extant web
> content, or was when we tried reserving it without opt-in versioning --
> the particular use was as a formal parameter name, used as a flag not a
> function).
Oh, right. We've been talking at cross-purposes. I assumed that you were
suggesting that 'yield
Brendan Eich wrote:
> This may be breaking a butterfly on a wheel, but I am game if it
> improves the state of the strawman proposals.
>
> On May 15, 2009, at 7:16 PM, David-Sarah Hopwood wrote:
>
>> My point was that the example of 'yield (foo)' (that is, yield
Brendan Eich wrote:
> On May 16, 2009, at 5:50 PM, David-Sarah Hopwood wrote:
>
>> Bear in mind, though, that adding message passing significantly
>> increases the expressiveness of the language, so we should take that
>> into account when comparing the complexity
Jason Orendorff wrote:
> On Thu, May 14, 2009 at 7:35 PM, David-Sarah Hopwood
> wrote:
>>> For instance, suppose that you have dataflow concurrency, as supported
>>> by Oz and by recent dataflow extensions for Ruby, Python, and Scala:
>>>
>>> <http://w
Brendan Eich wrote:
> On May 14, 2009, at 5:13 PM, David-Sarah Hopwood wrote:
>> Brendan Eich wrote:
>>> On May 14, 2009, at 1:14 PM, Neil Mix wrote:
>>>
>>>> I have this idea that it would be better for yield expressions to look
>>&
John Cowan wrote:
> David-Sarah Hopwood scripsit:
>
>> Then the functionality of a generator can be implemented using a
>> process/thread that extends a list or queue constructed from
>> dataflow variables.
>
> Quite so. How, if at all, do these dataflow variables
Brendan Eich wrote:
> On May 14, 2009, at 4:34 PM, David-Sarah Hopwood wrote:
>
>> This approach avoids any problems due to a generator being able
>> to interfere with the control flow of its callers.
>
> A generator can't interfere with the control flow of its
; and extra parens hurt (I know RSI sufferers who benefit from lack of
> shifting in Python and Ruby).
Yes, those are separate points that I am not arguing against here.
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
[I sent this to es5-discuss, when I intended es-discuss. Sorry for the
noise for people subscribed to both.]
David-Sarah Hopwood wrote:
> Jason Orendorff wrote:
>> On Thu, May 14, 2009 at 12:25 PM, Mark S. Miller wrote:
>>> Given both shallow generators and lambda, I don
unction "foo" declaration has no
> standard behavior:
>
> (function () {
>function foo() {
>}
> })();
No, that is perfectly standard (and implemented correctly cross-browser).
The body of the outer function is a sequence of SourceElements, which
allows a FunctionDeclaration. 'foo' is bound only within the outer
function's scope.
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
toNumber' a figment of the authors' imagination?
(This is unfortunately almost impossible to search for.)
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mark S. Miller wrote:
> On Sat, May 9, 2009 at 2:32 PM, David-Sarah Hopwood
> wrote:
>> [...] but the AST should preserve the associativity defined in the
>> language spec.
>
> But which language spec? Again, specs only traffic in observable
> differences. Since ES5 do
erve the associativity defined in the
language spec.
> I'm in favor of right association for these logical connective ops,
> since they short-circuit evaluation based on truthiness (||) or
> falsiness (&&) of the left operand. Thoughts?
Evaluating "a || b || c" always evaluates the left operand of the
outer '||', which is "a || b". This in turn always evaluates "a". But
the left operand of the outer expression is not "a", unless we also
want to change how '||' and '&&' are specified.
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
1 - 100 of 378 matches
Mail list logo
