[racket] TR - Back patching avoidance in struct:

From: Eric Dobson (eric.n.dobson at gmail.com)
Date: Tue Aug 28 12:49:12 EDT 2012

You can get something like this with shared or make-reader-graph, but
not for custom structure types. Also I don't know how well they work
in TR. You could also use promises and then write a wrapper, that did
the forcing on every access.

http://docs.racket-lang.org/reference/shared.html?q=shared#(form._((lib._racket/shared..rkt)._shared))
http://docs.racket-lang.org/reference/pairs.html?q=make-placeholder&q=shared#(def._((quote._~23~25kernel)._make-reader-graph))

You could also do something like in
http://www.ccs.neu.edu/racket/pubs/stop09-ft.pdf, to ensure that the
only part of the code knows about the option value, and everyone else
does not.

On Tue, Aug 28, 2012 at 9:32 AM, Ray Racine <ray.racine at gmail.com> wrote:
> Is there a current cleverness in TR that allows for typesafe avoidance of
> back patching a self referential structure.
>
> Say one wants to construct a TOP-NODE where the parent field is itself.  I
> know I could make parent : (Option Node) and back patch with a set!.  But
> could one do better.
>
> The below type checks but of course fails on execution.  However some sort
> special post structure construction asserting "defined-ness" of the parent
> field triggered as a post operation after (atomic) structure creation
> assertion would get one there.
>
> #lang typed/racket/base
>
> (struct: Node ([parent : Node]))
>
> (: TOP-NODE Node )
> (define TOP-NODE
>   (letrec: ((self : Node (Node (assert self Node?))))
>     self))
>
> ;;;;;;;;;;
>
>  Anyway, just a random thought on a coffee break.
>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>

Posted on the users mailing list.