[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #1716: coops + s11n malfunction
From: |
Chicken Trac |
Subject: |
Re: #1716: coops + s11n malfunction |
Date: |
Mon, 24 Aug 2020 14:20:38 -0000 |
#1716: coops + s11n malfunction
---------------------------------------+------------------------
Reporter: Idiomdrottning | Owner: (none)
Type: defect | Status: new
Priority: major | Milestone: someday
Component: extensions | Version: 5.1.0
Resolution: | Keywords: coops s11n
Estimated difficulty: |
---------------------------------------+------------------------
Comment (by Idiomdrottning):
OK, so the following works in interpreted code and in compiled code up
to -O4 after deserialization:
(define (coops-restore! x)
(##sys#setslot x 1 (eval (class-name (class-of x)))))
After (coops-restore! nitfol) it behaves just like any other frotz,
and (name nitfol) returns "blue jeans".
(If frotz is defined in the continuation ofc.)
This isn't recursive so any other instances or class inside of the
deserialized object, including in lists, vectors, hashtables etc would
also have to be restored.
So the problem with the coops/s11n is with coops' fundamental design.
<standard-class> is defined as a recursive structure. The standard
class is also an instance of standard class. But, testing to see
whether something is the standard class tests for eq with
<standard-class> in the environment. That's an eq-relationship that
breaks on deserialization.
Deserialization can handle recursive structures (like circular lists)
just fine. The S11N egg uses a ref table. But it can't check for eq
with structs in the environment. It can handle symbols (somehow…) but
not just (eq? a b) where both a and b are names for the same
coops#coops-instance.
My idea for a workaround was to try to walk the deserialized
coops-instances and replace any references to the fake
<standard-class> (which still has the class name <standard-class>,
just not environment eq-equality) with the real one. But, all these
nonsense recursive structures is making that very difficult.
(The nonsense recursive structures being created by deserializing
<standard-class>)
The issue here is with using continuation eq-equality (to a completely
cockamamie recursive struct that it itself relies on the
aforementioned eq-equality) instead of a symbol in slot 0 like any
other datum.
The two solutions I can see is to either make s11n handle coops object
specially, by storing a <standard-class> as just a tag (tag number 21
perhaps) instead of as a recursive structure and then restoring it
from the environment. Or, ideally, by reworking coops so that
<standard-class> is based on having a specific symbol rather than a
specific eq-relationship with a structure defined or exported to the
continution.
--
Ticket URL: <https://bugs.call-cc.org/ticket/1716#comment:2>
CHICKEN Scheme <https://www.call-cc.org/>
CHICKEN Scheme is a compiler for the Scheme programming language.