ajvincent at gmail.com
Thu Dec 7 20:23:50 UTC 2017
TLDR: -1 is much more useful in mathematics than in expressing an opinion.
In this case I am the implementer, and I generally know what I'm doing
after well over fifteen years of working with the language, including the
membrane library we're talking about, and including writing an 1100+ page
book on the language. (The latter taught me a lot, by the way. You should
try it sometime. It's a very humbling experience, both at the time for
what you thought you knew that's actually quite wrong, and much later in
life, when you realize what you still got wrong. I only hope Martin Honnen
is still around for me to reiterate my thanks to...)
I shouldn't be worried about the garbage collector, and I'm not.
But I do know how my membrane can (a) create and (b) hold onto references.
This wasn't about the garbage collector at all. This was about avoiding
creating the proxy and thus, the reference, in the first place. I am
dealing with the concept of "when is wrapping something in the membrane
counter-productive in some way".
I said "essentially a memory leak", not meaning to be taken entirely
literally. It is a memory leak in the sense that unless somebody visits
that proxy again -- which no one will ever know if it's necessary or not --
the reference to the proxy will remain alive. For that proxy to exist
because of a simple filter function is possibly less than ideal, to put it
politely. Especially when said filter function can be called many times
for many different objects.
So yes, maybe it's premature optimization, and I'm always willing to admit
I'm wrong... when it's clear that I am. In my case, I'm not looking at
micromanagement of the gc, but to avoid certain work in the first place.
Now, parsing a function's source code to find out if that function will,
say, set a global variable that it shouldn't, is probably pretty expensive
and might have retained some useful metadata that the specification doesn't
expose.* Which is why I'm not particularly interested in adding esprima
and a bunch of code I don't understand for a small bit of metadata. It's
why I came to this mailing list today, to ask the experts, "Hey, is this a
good idea to look into? I actually have a use-case, and it's not something
that can be easily done in raw JS." That's my understanding of the general
requirements for adding new API.
I already explored at least two other ideas that turned into dead ends, and
it's quite possible (probable, given the feedback) that this one will be a
dead end too. I'm fine with that.
So sure, asking end users to micromanage or optimize their code is
irresponsible. But I'm writing a library for developers to use, and if I
can provide advice on the best way to use that library, I think it's worth
the time to think about how that library works, and how to be nice to the
machines that it will run on. So I'd better think a lot about optimizing *my
*code, and about helping *my* users get the best reactions from it.
On Thu, Dec 7, 2017 at 11:26 AM, kai zhu <kaizhu256 at gmail.com> wrote:
> This led down a long, rambling path  where I then realized: if the
> callback function is a pure function, then for the purposes of that
> callback, the arguments probably do not need to be wrapped in proxies at
> all. The big catch is that the callback can't store any of the arguments
> in variables external to the callback (a classic side effect). If the
> function really is pure, though, I can avoid the memory leak.
> users generally should not be encouraged to micro-manage/optimize the gc
> engine-implementers. making users think they can outsmart the gc (which
> they don't) will only encourage them to waste time writing
> “high-performance” code that is bike-shedding at best and tech-debt at
> worst (and my suspicion is membrane/proxy will suffer either of those fates
> with this feature).
> On Dec 8, 2017, at 2:22 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
> On Thu, Dec 7, 2017 at 1:11 PM, Alex Vincent <ajvincent at gmail.com> wrote:
> again, a
> > great idea and a lengthy essay of a post falls to a real-world situation.
> > Nuts.
> > What if there's a middle ground? In the case I was originally talking
> > about, the developer calling on my membrane controls how the callback
> > function executes. I just want to ensure that, when the callback is
> > controlled and trusted arguments (including possibly "this"), the
> > doesn't refer to anything outside those arguments and local variables
> > derived from them. Is that reasonable to ask for?
> Do you want the same kind of thing that Joe-E provides for Java?
> > Proving that particular methods within a code base are functionally
> > pure—deterministic and side-effect free—would aid verification of
> > security properties including function invertibility, reproducibility of
> > computation, and safety of untrusted code execution. Until now it
> > has not been possible to automatically prove a method is functionally
> > pure within a high-level imperative language in wide use, such as Java.
> Nothing that is well established really fits for JS, but there are some
> proposals and experimental features.
> The frozen realms proposal
> <https://github.com/tc39/proposal-frozen-realms> might also be of
> > Though initially separate, realms can be brought into intimate
> > contact with each other via host-provided APIs.
> In a browser setting, WebAssembly
> <http://webassembly.org/docs/js/#webassemblyinstance-constructor> might
> be your best bet.
> WebAssembly.instantiate(module,importsObj) runs a sandboxed binary
> that has access to functions and values in an importsObject, and
> takes care to prevent following backwards edges in the object graph
> (__proto__, .constructor and the like).
> es-discuss mailing list
> es-discuss at mozilla.org
"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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss