Dumper does not handle cyclic object at all

[kchanqvq]

Realized this when I'm debugging my experimental JS object structures.lisp implementation (because I'm dumping DSDs).

This might need some major redesign yet again. Maybe in the end we will also solve the bundle size issue in #442 (comment).

[davazp]

I think this could be pretty easy to fix with the current design though. But maybe there are other benefits.

[kchanqvq]

I think this could be pretty easy to fix with the current design though. But maybe there are other benefits.

How do you think this could be fixed? Currently we emit var bindings for literal objects in one pass, but this emit invalid

var l100 = interals.Cons(l101, l2);
var l101 = internals.Cons(l100,l2);

for cyclic object (in this case car of l100 becomes undefined instead of l101). I think to fix it there has to be a two pass algorithm where the first pass creates the objects and second pass set the slots.

Or I can just copy what the standard says about make-load-form.

My main problem is where to do the two passes in our compiler. The first pass (what standard calls "creation forms") can be done as soon as we see a literal object like what we do now, but how about the second pass (what standard calls "initialization forms")?

[davazp]

It does require a second phase indeed, but that doens't have to be a huge change? Maybe I misunderstood the 'refactor' aspect.

My main problem is where to do the two passes in our compiler. The first pass (what standard calls "creation forms") can be done as soon as we see a literal object like what we do now, but how about the second pass (what standard calls "initialization forms")?

Can't we do like in convert where we separate toplevel from recursive like, dump-toplevel and dump, and dump does all the recursion? That way the recursive steps collect the 'resolutions'.

We do something very similar already in convert I think.

Maybe I am wrong but:

• As we dump values recursively. Keep an argument with the path to it. (mirrors the call stack basically)

• Once we get to the recursive call that would form a cycle, the path is checked. An we emit a placeholder and collect a resolution into some special variable. (effectively the second phase you describe).

• At the end of the recursion, (end of a dump-toplevel), the resolutions are executed to emit mutations in JS.

So we could end up with some JS code like

var l100 = interals.Cons(0 /* placeholder */, l2);
var l101 = internals.Cons(l100,l2);
l100.car = l101;  /* resolution emitted from *dump-resolutions* */

This requires a bit of special code for each different kind of compound structure though. JS proxies could avoid that but it has a performance penalty.

There might be an alternative implementation where we use some JS helpers to create cycles too.

But yeah, maybe it is not a very easy change after all :-)

[kchanqvq]

Mostly. Also the second pass can't just happen at the unit of top level form, it has to happen at the unit of files according to spec.

[davazp]

Can you make cyclical literal references across multiple top level forms ?

[kchanqvq]

Can you make cyclical literal references across multiple top level forms ?

Yes. And requirements like CLHS 3.2.4.4 is always defined at the unit of file.

[davazp]

Do you have an example out of curiosity? Not sure how I would do that