beef with sharp-expressions?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

beef with sharp-expressions?

Dave Herman
I hear people grumble about SpiderMonkey's sharp-expressions and even express the desire to eliminate them. I've never understood this -- I think they're great, although I'd like to see them grow up a little.[*]

What I want to know is, what's wrong with sharp-expressions? Is it just because they're indexed by integers instead of names? (I'd be very much in favor of extending them to take identifiers instead of or in addition to integers.) Or is it because of the implementation/maintenance burden of representing cyclic data in the decompiler? Or something deeper?

Thanks,
Dave

[*] Briefly, the reason I think they're important are they're a declarative syntax for sharing, which could become more important as we try to add more immutable constructs to JS. If we are going to try to pull JS kicking and screaming into the era of parallelism, and we're serious about avoiding shared mutable state, we're going to need better constructs for working with immutable data. And sharp-expressions are a good way to create cyclic data structures that could still be immutable to user code (the VM would of course use mutation to construct them). I could say more, but I should probably blog about it...

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: beef with sharp-expressions?

Wes Garland
Dave;

I don't know what the status is from JSAPI-implementor point of view, but,
from a user's POV -- sharp objects are *grrrrrrrr-reat*!  The only problem
is that they are not universally supported, and not part of JSON. So we
don't use them in the browser.

That said, when doing things like serializing complex application state to
disk, sharp variables are a must.  It allows my developers the freedom to
create human (programmer)-oriented object graphs without worrying about
accidentally creating a graph with cycles.

On a slightly related topic, in order to allow us to serialize state with
custom, C-language objects ("host objects" per tc39?) we add .toSource()
methods on those objects' prototypes which output source code something like

(new (require("binary").ByteString)([0x68, 0x65, 0x6c, 0x6c, 0x6f]))

..this in turn means that, combined with sharp notation, our only limitation
on ability to serialize state is that the state must be represented by an
object graph where all objects in the graph have the property that it is
possible recreate all relevant internal state via the constructor, and that
we emit appropriate toSource() output.

So, this creates much happiness.   Back in our C days, we had to write a
mark-and-sweep serializer for each type of struct that could be made into a
(possibly cyclic) state tree in our apps  (we do transactional
state-snapshot to help with cluster node migration).   Now we just write
code which boils down to

function snapshot(session) {
  require("fs-base").open("filename", { write: true, create: true
}).write(session.toSource());
}

function restore() {
  return eval(require("fs-base").open("filename", { read: true
}).readAll());
}

How great is that?!

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: beef with sharp-expressions?

Dave Herman
Jason CC'ed me on a bug that helped me understand the problems better. I did a little digging into other languages, too, so I'm getting a better idea of how others deal with this. I'll leave it at that for now, in the interest of not generating too much noise. But thanks, Jason -- that was helpful.

Dave

On Feb 14, 2011, at 10:42 AM, Wes Garland wrote:

> Dave;
>
> I don't know what the status is from JSAPI-implementor point of view, but, from a user's POV -- sharp objects are grrrrrrrr-reat!  The only problem is that they are not universally supported, and not part of JSON. So we don't use them in the browser.
>
> That said, when doing things like serializing complex application state to disk, sharp variables are a must.  It allows my developers the freedom to create human (programmer)-oriented object graphs without worrying about accidentally creating a graph with cycles.
>
> On a slightly related topic, in order to allow us to serialize state with custom, C-language objects ("host objects" per tc39?) we add .toSource() methods on those objects' prototypes which output source code something like
>
> (new (require("binary").ByteString)([0x68, 0x65, 0x6c, 0x6c, 0x6f]))
>
> ..this in turn means that, combined with sharp notation, our only limitation on ability to serialize state is that the state must be represented by an object graph where all objects in the graph have the property that it is possible recreate all relevant internal state via the constructor, and that we emit appropriate toSource() output.
>
> So, this creates much happiness.   Back in our C days, we had to write a mark-and-sweep serializer for each type of struct that could be made into a (possibly cyclic) state tree in our apps  (we do transactional state-snapshot to help with cluster node migration).   Now we just write code which boils down to
>
> function snapshot(session) {
>   require("fs-base").open("filename", { write: true, create: true }).write(session.toSource());
> }
>
> function restore() {
>   return eval(require("fs-base").open("filename", { read: true }).readAll());
> }
>
> How great is that?!
>
> Wes
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: beef with sharp-expressions?

Brendan Eich-2
In reply to this post by Dave Herman
I commented in the bug. The way to manage a long-lived platform, where inevitably some ideas don't pan out as hoped (even if useful to many), is

1. Add extension mechanism sufficient for users to self-host.

2. Deprecate the to-be-removed extension.

3. Obsolete via removal.

For sharp variables, (1) is Harmony WeakMaps, which should be prototyped after Firefox 4 and pretty quickly (there's a patch already):

https://bugzilla.mozilla.org/show_bug.cgi?id=547941

With WeakMaps, you can write your own object graph codec. No need to put the sharps in the main language syntax. The uneval | eval names would change but otherwise the functionality would remain.

/be
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: beef with sharp-expressions?

Jim Blandy-3
In reply to this post by Wes Garland
On 02/14/2011 04:31 PM, David Herman wrote:
> Jason CC'ed me on a bug that helped me understand the problems better. I did a little digging into other languages, too, so I'm getting a better idea of how others deal with this. I'll leave it at that for now, in the interest of not generating too much noise. But thanks, Jason -- that was helpful.

What was the bug number?

See also bug 633278. I totally agree that sharp notation is necessary,
but ours is a little out of control.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: beef with sharp-expressions?

Wes Garland
Jim;

On Fri, Feb 18, 2011 at 4:29 AM, Jim Blandy <[hidden email]> wrote:
>
> What was the bug number?
>

Bug in question is *Bug
566700*<https://bugzilla.mozilla.org/show_bug.cgi?id=566700>- remove
sharp variables

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: beef with sharp-expressions?

Jean-Marc Desperrier-4
In reply to this post by Dave Herman
Wes Garland wrote:
> (new (require("binary").ByteString)([0x68, 0x65, 0x6c, 0x6c, 0x6f]))
> [...]
> require("fs-base").open("filename", { write: true, create: true

Reading this I really wondered if a stock Spidermonkey could do that,
and my search lead me to http://code.google.com/p/gpsee which I feel I'm
going to take some further interest into.

I'd love to see a CommonJS compatibility-layer implemented on top of
just js-ctypes so it's usable in the browser (even if only some of the
most important modules, binary, fs-base).
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine