chicken-janitors
[Top][All Lists]
Advanced

[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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]