Re: Are ES Modules garbage collected? If so, do they re-execute on next import?

ePea > > On Wed, Jul 1, 2020 at 6:16 AM Mark S. Miller wrote: > > > > No, definitely not. The table from specifiers to module instances is > indexed by specifiers. Specifiers are strings, so this table is not weak. > It is not a "cache" in the sense that it is allow

Re: Are ES Modules garbage collected? If so, do they re-execute on next import?

No, definitely not. The table from specifiers to module instances is indexed by specifiers. Specifiers are strings, so this table is not weak. It is not a "cache" in the sense that it is allowed to drop things. Rather it is a registry of module instances. Only a registry as a whole can be gc'ed,

Realms and Compartments

At TC39, the EcmaScript standards committee, Caridy Patiño gave a great talk on Realms https://docs.google.com/…/1umg2Kw18IlQyzrWwaQCAkeZ6xL…/edit…

Re: syntax for case ranges

a "chain" of > comparisons. > > > > > > Would this be acceptable to introduce into JavaScript (just curious)? > > > > > > I've probably missed your point entirely, because I saw a short > message "3 > > > < 2 < 1 //tru

Re: syntax for case ranges

3 < 2 < 1; // true On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla wrote: > Certain languages allow the expression 0 would be syntactically possible in JavaScript? Of course this would only > apply for "if"/"while" statements. > > On Fri, 31 Jan 2020 at 22:41, Isiah Meadows > wrote: > >> Still

Re: Proposal: strict built-in functions

Thanks Claude, I agree. I have added it to the agenda as well. https://github.com/tc39/agendas/blob/master/2020/02.md On Mon, Dec 9, 2019 at 12:45 AM Claude Pache wrote: > > > Le 8 déc. 2019 à 15:39, Mark S. Miller a écrit : > > Wow, Edge is definitely in violation of the int

Re: Proposal: strict built-in functions

Wow, Edge is definitely in violation of the intent of the spec, and the intent of the history of treatments of .caller in previous discussions and specs over the years. The Edge behavior is grossly unsafe. Hi Jack, thanks for catching this and raising it!! It does need to be fixed. I do think it

Meetup: "Making Javascript Safe and Secure" Thursday 5 Dec, 6pm San Francisco

https://www.eventbrite.com/e/making-javascript-safe-and-secure-tickets-81435250025 On Thursday evening after the tc39 meeting, Agoric, Moddable, and MetaMask are organizing a meetup on *Making Javascript Safe and Secure*

Re: Observable GC

On Fri, Oct 20, 2017 at 10:52 AM, Filip Pizlo wrote: > > > On Oct 20, 2017, at 10:29 AM, Mark Miller wrote: > > There is a glaring inconsistency in the criteria we use to evaluate these > issues. While we are understandably reluctant to admit more

Re: Proxy performance: JIT-compilation?

On Fri, Aug 4, 2017 at 2:52 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > On Aug 4, 2017, at 2:22 PM, Mark S. Miller <erig...@google.com> wrote: > > At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have an idea > (that we should turn into a pr

Re: Intercepting sets on array-like objects

Interesting. At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have been discussing a way to make Proxies cheaper, and Proxies that only override a few traps and let the rest default, much cheaper. On Thu, Jun 8, 2017 at 11:32 AM, Tab Atkins Jr. wrote: > Heya!

Re: Unicode non-character being treat as space on Firefox/Chrome

Allen, I'm very glad to hear that it is unambiguous after all. Gareth, could you file bugs against the non-conforming browsers? Thanks for finding this! On Thu, May 25, 2017 at 8:58 AM, Allen Wirfs-Brock wrote: > clause 10.1: > > ECMAScript code is expressed using

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

Take a look at Tom's explanation of the "shadow target" technique at https://research.google.com/pubs/pub40736.html section 4.3 On Tue, May 23, 2017 at 8:45 AM, Jason Orendorff wrote: > On Tue, May 23, 2017 at 2:44 AM, Alex Vincent wrote: > >>

Re: Re: Strict (non-coercing) expressions

On Thu, Apr 13, 2017 at 11:08 AM, Bruno Jouhier wrote: > I like the idea of a block level annotation. Lighter and more practical > than a new set of operators. Module level would be nice too. OTOH > expression level feels a bit like overkill. > > Why not turn this into a more

Re: Strict Relational Operators

Hi T.J., I do not recall such a discussion. Please do start one! Thanks. On Mon, Apr 10, 2017 at 2:47 AM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > I'm sure there must have been discussions of adding strict relational > operators (e.g., non-coercing ones, the `===` versions of

Re: Proxies fail comparison operator

The Left Hand of Equals https://research.google.com/pubs/pub45576.html is relevant to this discussion. The advice in this paper should be considered new languages that are not yet committed to an equality semantics. Frankly I have mixed feelings about it, but it is fascinating. OTOH, for

Re: A WeakMap where values (not keys) are weak references?

What you are asking for is sometimes called a "WeakValueMap". It is a very sensible abstraction and sometimes exactly what is needed. It is easy to build using Maps (or WeakMaps, depending) combined with < https://github.com/tc39/proposal-weakrefs>. The old wiki.ecmascript.org shows an

Re: How about awaiting Arrays ?

On Fri, Mar 3, 2017 at 12:27 PM, Mark S. Miller <erig...@google.com> wrote: > > > On Fri, Mar 3, 2017 at 8:51 AM, Michał Wadas <michalwa...@gmail.com> > wrote: > >> Actually I would go with >> >> await ...expr; >> > > I have not liked

Re: How about awaiting Arrays ?

On Fri, Mar 3, 2017 at 8:51 AM, Michał Wadas wrote: > Actually I would go with > > await ...expr; > I have not liked any of the prior suggestions on this thread. But this one is interesting. It has no compatibility problems, it composes nicely, and it suggests its meaning

Re: getOwnPropertyDescriptor side effects

On Thu, Jan 19, 2017 at 9:30 AM, Boris Zbarsky wrote: > On 1/19/17 12:24 PM, Isiah Meadows wrote: > >> 1. What does Firefox do with the getter on non-errors? >> > > Oh, I didn't make that clear, did I? On a non-error in the getter, we > have an Error object or Error.prototype

Re: Proposal: Symbol.templateTag

Hi Alexander, I have run into this myself. It is a real problem, and I like the nature of your proposed solution. But I don't understand how it might break the web. If Symbol.templateTag is a new symbol, guaranteed unequal to any prior value, how can introducing it, and new behavior conditional on

Re: JSON.stringify

On Thu, Sep 29, 2016 at 9:25 AM, Alexander Jones wrote: > Maybe we should just make U+2028 and U+2029 valid in JS then? What other > productions in JSON are invalid syntax in JS? IIRC, Doug Crockford, possibly Mike Samuel, and I (and perhaps others) advocated such a change to

Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

Besides those two, the only other reference to AddRestrictedFunctionProperties is < http://www.ecma-international.org/ecma-262/7.0/#sec-createintrinsics> step 12: 12. Perform AddRestrictedFunctionProperties

Re: Function constants for Identity and No-op

On Wed, Aug 10, 2016 at 7:33 AM, Mark S. Miller <erig...@google.com> wrote: > > > On Wed, Aug 10, 2016 at 7:25 AM, Eli Perelman <e...@eliperelman.com> wrote: > >> I can understand the sentiment of wanting brevity and avoiding >> unnecessary abstraction

Re: Function constants for Identity and No-op

tential benefits is avoidance of re-declaration > (DRY) and allocation. > > Just my thoughts. :) > > Eli Perelman > > > > On Wed, Aug 10, 2016 at 9:08 AM Mark S. Miller <erig...@google.com> wrote: > >> On Wed, Aug 10, 2016 at 2:10 AM, Isiah Meadows <isiahm

Re: Function constants for Identity and No-op

t.createElement('object'), any cross-realm function). > > Function.isFunction? :D > > On Wed, Aug 10, 2016 at 4:00 PM, Mark S. Miller <erig...@google.com> > wrote: > >> >> >> On Wed, Aug 10, 2016 at 4:53 AM, Andy Earnshaw <andyearns...@gmail.com> >&

Re: Function constants for Identity and No-op

On Wed, Aug 10, 2016 at 2:10 AM, Isiah Meadows wrote: > I'll note that it's longer than just typing them out manually (and close > if they're aliased): > > ```js > Function.IDENTITY > IDENTITY > x => x > > Function.NOOP > NOOP > () => {} > ``` > > Not sure if it adds

Re: Function constants for Identity and No-op

On Wed, Aug 10, 2016 at 4:53 AM, Andy Earnshaw wrote: > On Wed, 10 Aug 2016 at 12:42 Michał Wadas wrote: > >> Function.prototype is no-op (run Function.prototype.toString() for more >> information) >> > > That's true, but using `Function.prototype`

Re: Object.freezing proxies should freeze or throw?

On Mon, Aug 8, 2016 at 1:35 PM, Tom Van Cutsem wrote: > Claude's additional example is indeed evidence that Object.freeze is not > to blame, but rather that the invariant checks of > [[GetOwnPropertyDescriptor]] and [[DefineOwnProperty]] are too weak. The > culprit is, as far

Re: Object.freezing proxies should freeze or throw?

Hi Raul, yes it would. The invariants apply to all objects. If someone would like to write up the spec bug and fix, I'll happily represent and advance it at upcoming meetings. On Sun, Aug 7, 2016 at 6:49 AM, Raul-Sebastian Mihăilă < raul.miha...@gmail.com> wrote: > Would be a good idea to do

Bad advice on confirming the existence of bugs.

On Wed, Jul 27, 2016 at 10:20 AM, Alex Vincent quoted: > > -- > "The first step in confirming there is a bug in someone else's work is > confirming there are no bugs in your own." > -- Alexander J. Vincent, June 30, 2001 > I rarely comment on these incidental aphorisms,

Can strict parameters shadow strict function names?

var foo = function bar(bar) {'use strict'}; On all version of Safari/JSC I just tested, this code gives a SyntaxError: Invalid parameters or function name in strict mode. On all versions of Chrome/v8 and FF/SpiderMonkey I just tested, this code is accepted without error. Which behavior is

Re: Process of proposing targeted deconstruction

ES2015 was the last version for which the short for ("ES6") was also in common use. After that, there is only ES2016 etc. There is no such thing as ES7. On Wed, Jun 1, 2016 at 3:03 PM, John Gardner wrote: > I'd like to propose a simple yet potent syntax addition >

Re: Observing whether a function is strict

On Thu, May 26, 2016 at 1:23 PM, Mark S. Miller <erig...@google.com> wrote: > > > On Thu, May 26, 2016 at 11:25 AM, Claude Pache <claude.pa...@gmail.com> > wrote: > >> >> > Le 26 mai 2016 à 10:43, G. Kay Lee < >> balancetraveller+es

Re: Observing whether a function is strict

On Thu, May 26, 2016 at 11:25 AM, Claude Pache wrote: > > > Le 26 mai 2016 à 10:43, G. Kay Lee < > balancetraveller+es-disc...@gmail.com> a écrit : > > > > I was under the impression that strict mode is a (temporary) workaround > to get rid of unwanted bad parts of the

Re: Disabling nonstandard RegExp functionalities for proper subclasses of RegExp

Sorry, none of these examples are persuasive. Such non-local causality is a nightmare on many grounds. If we did want to provide equivalent functionality somehow, we should find a non-stupid way to package it. I like Claude's proposal as stated: Annex B normative *optional*, configurable and

Re: Do await statements unblock synchronously?

Not necessarily "the next tick", but some future tick. Definitely not in this tick or the tick in which the promise is resolved. Definitely in its own tick. And yes, engines can always do whatever unobservable optimizations they want. On Mon, Apr 11, 2016 at 6:00 PM, Jordan Harband

Re: Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

On Tue, Mar 29, 2016 at 7:02 AM, Mark S. Miller <erig...@google.com> wrote: > [...]The main reason for listing something in Annex B: > > * It is normative optional -- if the feature exists at all, it must > exist like so. > As the proposal says: Some of the element

Re: Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

On Tue, Mar 29, 2016 at 6:50 AM, Mark S. Miller <erig...@google.com> wrote: > Good question! > > Regarding the existing global, the frozen realm API proposal does not say > anything at all -- it is concerned only about TheFrozenRealm and realms > descendant from it. Outsid

Re: Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

for an Annex B entry. The main reason for listing something in Annex B: * It is normative optional -- if the feature exists at all, it must exist like so. Since the global object must exist, the normative optional rationale would not seem to apply. > > On Tue, Mar 29, 2016 at 8:

Re: Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

Good question! Regarding the existing global, the frozen realm API proposal does not say anything at all -- it is concerned only about TheFrozenRealm and realms descendant from it. Outside of the frozen realm proposal, I would indeed like us to pin this down better for globals in general. Why

Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

At https://github.com/FUDCo/ses-realm Since I last posted this, I have received much useful feedback of this proposal, especially from Daniel Ehrenberg, Ojan Vafai, Elliott Sprehn, Alex Russell, and Dave Herman. Thanks! This revision addresses this feedback in a variety of ways: * By

Re: Fwd: Are Zones Global State? Do they provide a dangerous communications channel?

On Mar 21, 2016 4:36 AM, "Raul-Sebastian Mihăilă" wrote: > Wouldn't it be enough to prevent access from normal SES realms to the > proto-SES realm's Zone primordial in order to keep SES as an ocap > environment (by having the global objects from normal SES realms inherit

Re: Proxy handler.has() does not have a receiver argument?

I agree with Allen. I am certainly willing -- often eager -- to revisit and revise old design decisions that are considered done, when I think the cost of leaving it alone exceeds the cost of changing it. In this case, the arguments that this extra parameter would be an improvement seem weak. Even

Draft Proposed Standard SES (Secure EcmaScript)

Chip Morningstar and I would like to announce a new proposal, on the agenda for the upcoming March meeting: Draft Proposed Standard SES (Secure EcmaScript) It is now ready for comments at https://github.com/FUDCo/ses-realm Feedback welcome, both here on this list and on that proposal's

Provide hooks for Content Security Policy (CSP)?

At https://github.com/tc39/ecma262/issues/450 we have started discussing whether a discussion is warranted. Perhaps a discussion is not warranted, in which case a thread on es-discuss is not needed, as some claim. However, since we are now discussing this very question, the question of whether we

Re: Why Proxy "apply" trap limited to function only?

We maintain the invariant that the typeof of an object is stable -- it never varies over time. An object is callable iff its typeof is 'function'. By making the callability *and* the typeof of the proxy dependent on its target, the two stay consistent. On Wed, Mar 2, 2016 at 6:51 AM, Олег

Re: Error stack strawman

On Thu, Feb 25, 2016 at 6:45 PM, Gary Guo wrote: > Things became more complicated when considering async & generators. For > async calls as mentioned before somewhere in the thread, only Firefox > Nightly build includes histories of the frame, while all other browsers >

Re: Error stack strawman

On Wed, Feb 24, 2016 at 2:37 PM, Boris Zbarsky wrote: > On 2/24/16 5:35 PM, Boris Zbarsky wrote: > >> Clearly this Just >> Works with a value property, across all browsers at that point, so we >> made it work with the accessor too. >> > > Oh, and we made it work the way

Re: Error stack strawman

ambient access to the stack. [1] For some reason the FF stack accessor has both getter and setter. I don't see any reason for a setter. [2] This solves only one of the cross-realm issue with stacks. It does nothing to address worries about cross-realm stacks. On Wed, Feb 24, 2016 at 12

Re: Error stack strawman

On Wed, Feb 24, 2016 at 11:40 AM, Steve Fink wrote: > On 02/19/2016 01:26 AM, Andreas Rossberg wrote: > > On 19 February 2016 at 03:13, Gary Guo wrote: > > If we are not going to indicate tail call some way, debugging might be >> extremely difficult, and

Re: non-self referencial cyclical promises?

On Wed, Feb 24, 2016 at 11:54 AM, Bergi wrote: > Bradley Meck wrote: > >> I was doing some recursive data structure work and ended up with a >> cyclical >> promise that did not use a direct self reference. It can be reduced down >> to: >> >> ```javascript >> var af, a = new

Re: Weak Reference proposal

On Fri, Feb 19, 2016 at 5:36 PM, John Lenz wrote: > The finalizer holdings, could itself could hold a reference to the > weakrefernce correct? > The holdings can certainly strongly point to the weakref itself, yes. There is no reason to think this is a mistake. By

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On Fri, Feb 19, 2016 at 1:17 AM, Coroutines wrote: > Hi - I hope I am not suggesting something that has been said before ~ > > Having Proxy and eventual Weak References makes it possible to build > Map/WeakMap in plain JS - nothing in hidden, 'native code' (C++). > Not

Re: Error stack strawman

On Thu, Feb 18, 2016 at 6:13 PM, Gary Guo wrote: > Andreas wrote: > > This would be fairly difficult to support by implementations. In V8, for > example, we currently have no way of reconstructing that information, nor > would it be easy or cheap to

Re: Error stack strawman

On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo wrote: > The strawman looks very old, so I've created a new one. > > Repo: https://github.com/nbdd0121/es-error-stack > > I've collected many information about current implementation from IE, > Edge, Chrome and Firefox, but missing

Re: Garbage collection in generators

Everyone, please keep in mind the following distinctions: General GC is not prompt or predicable. There is an unspecified and unpredictable delay before anything non-reachable is noticed to be unreachable. JavaScript GC is not specified to be precise, and so should be assumed conservative.

Re: Weak Reference proposal

What are the GC semantics specified for DOM? How are these observable? On Tue, Feb 16, 2016 at 7:04 PM, Isiah Meadows wrote: > I know this is only tangentially related, but I just remembered weak refs > are required for a fully conforming DOM implementation because of

Re: Weak Reference proposal

On Tue, Feb 16, 2016 at 4:26 PM, Kevin Smith wrote: > I have no problem with that, but do wonder, why? What is the downside of >>> proposals being on the tc39 hub starting at an earlier stage, if the >>> authors are so inclined? The upside is fewer broken links. >>> >> >

Re: Weak Reference proposal

I have no problem with that, but do wonder, why? What is the downside of proposals being on the tc39 hub starting at an earlier stage, if the authors are so inclined? The upside is fewer broken links. > > On 6:32PM, Tue, Feb 16, 2016 Mark S. Miller <erig...@google.com> wrote: > >>

Re: Weak Reference proposal

On Tue, Feb 16, 2016 at 2:02 PM, Daniel Ehrenberg wrote: > I think this proposal is currently at Stage 0, right? Right. It is stage 0. > Do we typically > put Stage 0 proposals on the TC39 GitHub? My understanding was that > proposals typically get moved after Stage

Re: Why are ES6 class methods not automatically bound to the instance?

Hi Jordan, this is an excellent point. I can't say I remember it being raised, but it would certainly have been adequate to kill any proposal that this be the default behavior. On Wed, Feb 10, 2016 at 8:22 AM, Jordan Harband wrote: > One of the wonderful features of many

Re: Why are ES6 class methods not automatically bound to the instance?

On Wed, Feb 10, 2016 at 7:11 AM, Sam Gluck wrote: > Hi all, > > Hope this is the right place for a purely out-of-interest query - if not, > apologies, please ignore! > > Why are methods on an ES6 class not automatically bound to their instance? > Is there any public

Re: `await null` to stay in the same tick?

On Sun, Feb 7, 2016 at 1:51 PM, Kris Kowal wrote: > Await yields to the event loop unconditionally. This is useful for > spreading CPU-bound work across multiple events. You can explicitly await > conditionally. > > ``` > if (guard) { await guard; } > ``` > Good example,

Re: monadic extension to do-notation

Since the non-monadic way won, I don't know that it is worth arguing about why. But it is ergonomic issues much deeper than convenience, and much more important than compatibility with existing libraries -- even if those two were adequate considerations by themselves. The behavior of promises was

Re: `await null` to stay in the same tick?

On Sun, Feb 7, 2016 at 1:38 PM, /#!/JoePea wrote: > I'm not sure where's the best place to ask, but if I > > ``` > await null > ``` > > in an async function does that guarantee that the following code will > execute immediately (control flow will not go anywhere else)? >

Re: Extending spread operators to work with numbers

The double dot ("..") is the traditional infix operator for inclusive,inclusive integer ranges, going back to Pascal (the language, not the mathematician). This has all the benefits you seek, including visual clarity, without overloading the meaning of an existing token. Whether double or triple

Re: Error stack strawman

ll happily help, advise, ensure that all requirements are met, and to champion this proposal on the committee. Volunteers? Jonathan? > Thanks > Jonathan > > On Tue, Jan 12, 2016 at 6:32 AM Mark S. Miller <erig...@google.com> wrote: > >> On Mon, Jan 11, 2016 at 10:0

Re: Annex B.3.3 substantially changes strict vs non-strict semantics

On Tue, Jan 19, 2016 at 9:54 AM, Kevin Gibbons wrote: > I'm not sure if this is well-known; it was certainly surprising to me. > > Consider the following program: > `let func = () => 0; > > (function(){ > { > function func() { > return 1; > } > } >

Re: Error stack strawman

On Mon, Jan 11, 2016 at 10:05 PM, Mark S. Miller <erig...@google.com> wrote: > I am very interested. See the extended Causeway stack format in > https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js > >From that page, the JSON Schema-ish in an ad-hoc nota

Re: Automatically giving symbols descriptions

Yup. Consider const foo = x(); where x happens to have the original value of Symbol. Or const foo = Symbol() where Symbol is not bound to the original value of Symbol. On Wed, Jan 6, 2016 at 4:44 PM, Jordan Harband wrote: > One difference is that functions are syntax

Re: [ small request - Javascript for javaing]

This discussion does not belong on this list. Please take it elsewhere. On Fri, Jan 1, 2016 at 10:42 AM, Sander Deryckere wrote: > There are also a lot of coders working in JavaScript (see > http://githut.info/), and JavaScript can also be used as a backend (see >

Re: Aren’t membranes incompatible with private data via WeakMaps?

Answering the question in the subject line, no. The key is the difference between a standalone proxy and a membrane. With a membrane, the key is that the: * Countdown class * Countdown.prototype * Countdown.prototype.dec * instances of the Countdown class * the WeakMaps used by the Countdown

Re: Is \u006eew a valid Identifier?

On Mon, Nov 9, 2015 at 12:05 PM, Allen Wirfs-Brock wrote: > > On Nov 9, 2015, at 6:55 AM, Andreas Rossberg wrote: > > Allen, what was the motivation for allowing random escapes in > identifiers but not in keywords? AFAICS, it would be simpler and more

Re: An update on Object.observe

On Tue, Nov 3, 2015 at 11:27 AM, lycheeJS Engine < lycheejs+esdisc...@gmail.com> wrote: > I think we still need Object.observe as a specification to implement > proper sandboxing of feature-detecting closures. > What do you mean by "sandbox"? (I was not able to make sense of the rest of this

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Mon, Nov 2, 2015 at 6:02 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > Not sure I've got your idea right but I think the main point of > WeakAnything is to forget about GC and have them **not** observable "at all > costs" > That is true of WeakMap and WeakSet. But there is a

Re: Calling toString on function proxy throws TypeError exception

Notice that whatever we decide on the issue, functionProxy.toString() will work regardless, since you'd be getting the toString method itself through the membrane. functionProxy.toString will be a function proxy for the target.toString method. The invocation on the toString proxy with

Re: Duplicate super call behaviour

On Sat, Oct 24, 2015 at 8:00 PM, Sebastian McKenzie wrote: > I was recently reading the specification on the behaviour of duplicate > super() calls in derived constructors. Reading the grammar the following is > valid: > > ``` > class Foo { > constructor() { >

Re: Calling toString on function proxy throws TypeError exception

I know that's true in general. But we made a few exceptions, especially for functions and arrays. I thought F.p.toString was one, but maybe not. I just don't remember. On Thu, Oct 22, 2015 at 2:36 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > On Oct 22, 2015, at 11:2

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

uses for > them. But they’re hardly the common use case, which is definitely string > interpolation > > On Oct 22, 2015, at 8:43 PM, Mark S. Miller <erig...@google.com> wrote: > > JavaScript does not have string interpolation. It has arbitrary value > interpolation. &

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

JavaScript does not have string interpolation. It has arbitrary value interpolation. On Thu, Oct 22, 2015 at 8:34 PM, Caitlin Potter wrote: > Okay, but usability wise, this kind of sucks. There's a reason it's not > what people expect, and why other languages with

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

e descent parser would. > > The main use is absolutely string interpolation. > > On Oct 22, 2015, at 8:56 PM, Mark S. Miller <erig...@google.com> wrote: > > > > On Thu, Oct 22, 2015 at 8:54 PM, Caitlin Potter <caitpotte...@gmail.com> > wrote: > >>

wiki.ecmascript.org

What's up, er down, with wiki.ecmascript.org ? http://downforeveryoneorjustme.com/wiki.ecmascript.org Still down. ETA? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Is anyone able to reach wiki.ecmascript.org ?

Seems to be down. Not answering pings. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

does make strong claims about limiting the listening to non-overt channels, by use of "fail-stop loggable non-determinism". I am becoming hopeful that JS may as well. But this is a topic for another day. > > Geoff > > On Sep 27, 2015, at 10:09 AM, Mark S. Miller <er

Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

before making a successful attack public. Thanks. > > More comments inline... > > On Sep 27, 2015, at 8:46 AM, Mark S. Miller <erig...@google.com> wrote: > > [-whatwg, +es-discuss] > Reposting to es-discuss, as Anne's more general question is best seen as a > JS issue

Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

[-whatwg, +es-discuss] Reposting to es-discuss, as Anne's more general question is best seen as a JS issue rather than a browser specific one On Sun, Sep 27, 2015 at 8:30 AM, Mark S. Miller <erig...@google.com> wrote: > On Sat, Sep 26, 2015 at 7:34 AM, Anne van Kesteren <ann.

Re: Exponentiation operator precedence

I like #4. Normally in a situation like this I would still argue for #1. #4 is a complicated special case that breaks the normal pattern of operator precedence elsewhere in the language. The need for ** is not great enough to justify introducing a new special case for users to learn. However, in

Re: Exponentiation operator precedence

I won't try to guess where the rendering problem is, but see the attached screenshots. This is how I'm seeing your page on my Chrome and Firefox. On Thu, Sep 24, 2015 at 8:19 AM, Brendan Eich wrote: > Even nicer: > > http://jsbin.com/baquqokujo > > I hate email. > > /be > >

Re: Exponentiation operator precedence

On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache wrote: > > Le 24 sept. 2015 à 16:11, Brendan Eich a écrit : > > And indeed apart from dot (a special form whose right operand must be a > lexical identifier-name) and square brackets (which isn't an

Re: Template strings as a template language.

that someone could still put something inside a template > string and do nasty stuff, but I'm not sure if that's a easily solved > problem. > > On 13 Sep 2015, at 10:08 PM, Mark S. Miller <erig...@google.com> wrote: > > On Sun, Sep 13, 2015 at 2:42 AM, Thomas <thomasj

Re: Template strings as a template language.

On Sun, Sep 13, 2015 at 2:42 AM, Thomas wrote: > I'd really like to use Template strings as a templating language, but > unless I include a lot of boilerplate code (export a template string > wrapped in a function from a file) Hi Thomas, could you give a concrete

Re: Template strings as a template language.

a strictness, like Python's. > > On 13 September 2015 at 15:15, Mark S. Miller <erig...@google.com> wrote: > >> >> >> On Sun, Sep 13, 2015 at 7:08 AM, Thomas <thomasjamesfos...@bigpond.com> >> wrote: >> >>> What I've been doing

Re: Template strings as a template language.

te string > is evaluated. > > Thomas > > On 14 Sep 2015, at 12:15 AM, Mark S. Miller <erig...@google.com> wrote: > > > > On Sun, Sep 13, 2015 at 7:08 AM, Thomas <thomasjamesfos...@bigpond.com> > wrote: > >> What I've been doing: >> >> expor

Re: Template strings as a template language.

On Sun, Sep 13, 2015 at 8:58 AM, Bob Myers wrote: > Templating languages typically "compile" templates into functions through > various lexical transformations. > > Consider a template file foo.tem: > > ``` > My name is ${this.name}. > ``` > > Lexically transform this into > > ```

Re: Object id, hash, etc?

See Labeler at http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps#unique_labeler On Tue, Sep 8, 2015 at 11:16 AM, joe wrote: > Didn't send to list, something is wrong with my reply all. Sorry about > that. Stupid mobile gmail. > -- Forwarded message --

Re: Object id, hash, etc?

ECT_ID; > Does not work on frozen objects. >} >return this[ identity ]; > } > } ); > > On Tue, Sep 8, 2015 at 1:44 PM, Mark S. Miller <erig...@google.com> wrote: > >> See Labeler at >> http://wiki.ecmascript.o

Re: Object id, hash, etc?

Hi Tab, then you get the Labeler, which this message is responding to. On Tue, Sep 8, 2015 at 2:12 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Tue, Sep 8, 2015 at 2:07 PM, Mark S. Miller <erig...@google.com> wrote: > > On Tue, Sep 8, 2015 at 1:57 P

Re: Weak References

one > > stream = null > > } > > }, interval) > > > > // Return a strong reference > > return res > > } > > ``` > > > > Sorry for the ambiguity. > > > > (edited out a few bugs from the origin

Re: Weak References

I also don't get the purpose of this code. What is it trying to achieve? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

  1   2   3   4   5   6   7   8   9   10   >