Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.perl for self-referent structures #6

Open
coke opened this issue Oct 21, 2011 · 5 comments
Open

.perl for self-referent structures #6

coke opened this issue Oct 21, 2011 · 5 comments

Comments

@coke
Copy link
Contributor

coke commented Oct 21, 2011

Pulled from https://rt.perl.org/rt3/Ticket/Display.html?id=58922

Subject:        .perl for self-referent structures
Date:   Tue, 16 Sep 2008 17:17:27 +0200
To:     rakudobug@perl.org
From:   "Carl M�sak" <cmasak@gmail.com>
Download (untitled) [text/plain 631b]
Calling .perl on a self-referent structure makes Rakudo r31152 hang.

$ ./perl6 -e 'my @a = (1); @a[0] := @a; @a.perl'

<masak> pmichaud: what about @a[0] := @a ?
<pmichaud> masak: I don't know about that one. :-)
[...]
<masak> :)
[...]
<pmichaud> part of me thinks that ends up with a self-referential structure
<masak> I hope so
<masak> that seems to be what's happening in at least one case in
Rakudo right now
<masak> question is, should .perl be able to handle that, and if so, how?
<moritz_> masak: it should
<moritz_> perhaps it should emit something like 'do { my @x = (...);
@x[0] := @x; @x }'
* masak submits rakudobug

#       Fri Nov 07 15:01:43 2008         pmichaud - Correspondence added                 [Reply] [Comment]
RT-Send-CC:     perl6-compiler@perl.org
Download (untitled) [text/plain 193b]
I'm going to mark this ticket as stalled until we have a good idea of
how self-referent structures should be handled in the output, either
through the spec itself or the spectests.

Thanks!

Pm
@masak
Copy link

masak commented Jun 2, 2013

I see that this issue has been silent for two years. May I try to get the discussion unstuck by suggesting that .perl should handle circular references. We know it's eminently possible, because Perl 5's Data::Dumper already does this.

If people agree to that, the only remaining question is "how exactly should .perl display these circular references?" And that seems to me to be a question that need not block us — just do the simplest thing that works. It's more important in the short term that .perl not hang when presented with something circular.

@pmichaud
Copy link
Contributor

pmichaud commented Jun 2, 2013

I totally agree with making this issue unstuck. "Simplest thing that works" sounds good to me.

Pm

@moritz
Copy link
Contributor

moritz commented Jun 2, 2013

FWIW there is a significant difference between .perl methods and Data::Dumper; Data::Dumper has an obvious place to put the temporary data needed to find reference cycles (the Dumper sub itself). But as things currently stand in Perl 6 and the implementations, each .perl method only takes care about its own little invocant, recursively calls .perl on all members of its data structure.

So we need some kind of spec on where the cycle tracking data is stored, or how it is propagated from/by the individual .perl methods.

@pmichaud
Copy link
Contributor

pmichaud commented Jun 2, 2013

On Sun, Jun 02, 2013 at 11:51:03AM -0700, Moritz Lenz wrote:

[...] Data::Dumper has an obvious place to put the temporary
data needed to find reference cycles (the Dumper sub itself).
[...]

So we need some kind of spec on where the cycle tracking data is
stored, or how it is propagated from/by the individual .perl methods.

This is one of those areas where I think we want to create an
implementation that does what we want, from which a spec can then
be codified.

In particular, AFAIK there's nothing in the spec that says that
each object has to define "method perl" for its type...
the top level sub could be Mu.perl, which then passes contextual
data to the per-type .PERL methods .

Pm

@japhb
Copy link
Contributor

japhb commented Jun 3, 2013

On 2013-06-02 13:44, Patrick R. Michaud wrote:

On Sun, Jun 02, 2013 at 11:51:03AM -0700, Moritz Lenz wrote:

[...] Data::Dumper has an obvious place to put the temporary
data needed to find reference cycles (the Dumper sub itself).
[...]

So we need some kind of spec on where the cycle tracking data is
stored, or how it is propagated from/by the individual .perl
methods.

This is one of those areas where I think we want to create an
implementation that does what we want, from which a spec can then
be codified.

In particular, AFAIK there's nothing in the spec that says that
each object has to define "method perl" for its type...
the top level sub could be Mu.perl, which then passes contextual
data to the per-type .PERL methods .

For what it's worth, there may be some design and/or code that can be
stolen/borrowed from DUMP for this, since it has to solve a superset of
this problem: self-referential and mutually-referential data structures
that may not always be Perl 6 structures (but may instead be VM
structures).

I am not claiming bulletproof implementation in DUMP -- it's a
non-trivial problem -- but it could be a good start.

-'f

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants