[plt-scheme] Help with #0 and #0# notation in the REPL

I apologize, however:

I can't quite see the benefit of requiring:

 (require scheme/shared)
 
 (shared ([a (cons 1 a)]) a))

 => #0=(1 . #0#)

vs. simply specifying it directly:

 #0=(1 . #0#)

if write broadly supports cyclic graphs, so too then should read.

as although the following works as expected:

   (define x (read (open-input-string "#0=(1 . #0#)"))) x
   => #0=(1 . #0#)"

then so should seemingly:

   (eval (read (open-input-string "(define x #0=(1 . #0#))"))) x
   => datum->syntax: cannot create syntax from cyclic datum:
      (define x #0=(1 . #0#))

> From: John Clements <clements at brinckerhoff.org>
> Date: Tue, 29 Jan 2008 17:08:08 -0800
> To: Paul Schlie <schlie at comcast.net>
> Cc: PLT Scheme Mailing List <plt-scheme at list.cs.brown.edu>
> Subject: Re: [plt-scheme] Help with #0 and #0# notation in the REPL
> 
> 
> On Jan 29, 2008, at 4:44 PM, Paul Schlie wrote:
> 
>> "It only ever worked for quoted cyclic data (and that's what's gone
>> now)."
>> 
>> (sarcasm on) by what logic was this determined? personally I've used
>> cyclic
>> data to describe many things, inclusive of syntax, semantic, and state
>> transition information, and can see no obvious benefit to having to
>> construct such information programmatically, not to mention that
>> once it
>> was so constructed, it can't be easily written to a file, and then
>> correspondingly easily restored via read with out such a
>> capability); of
>> course with immutable lists, programmatic construction, isn't the
>> easiest
>> either, so might as well eliminate any vestiges of enabling lists as
>> the
>> basis of a flexible variable data structure. As after all, scheme
>> wasn't
>> ever known to be a powerful friendly flexible programming language
>> (sarcasms
>> off).
> 
> Hang on... to the best of my knowledge, (shared ...) allows you to
> define circular data without multi-step programmatic construction, and
> read/write _do_ support writing and reading of cyclic data.  No?
> 
> BTW, it's hard to understand you with sarcasm on.  I would leave it off.
> 
> All the best,
> 
> John
>