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

Discussions like these explain why software is sometimes called  
'code' :)

RAC

On Jan 29, 2008, at 7:27 PM, Robby Findler <robby at cs.uchicago.edu>  
wrote:

> The two expressions you write below (the shared one and the #0= one)
> are not the same. At the risk of being offensive, that is the whole
> point. If the #0= one were the same, there would be no objections.
>
> Robby
>
> On Jan 29, 2008 8:25 PM, Paul Schlie <schlie at comcast.net> wrote:
>> 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
>>>
>>
>>
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme