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

"While this is more expressive, it is not clear that it pays for
 itself, in terms of the maintenance burden it puts on tool authors."

Yes, and I understand that it is more complex to maintain; but the point
is that languages should be designed at the convenience and pleasure
of its users, not necessarily the authors convenience; if the latter were
the primary goal I'm sure most languages could be simplified substantially
to the point of near uselessness.

> From: Robby Findler <robby at cs.uchicago.edu>
> Date: Tue, 29 Jan 2008 22:15:57 -0600
> To: Richard Cleis <rcleis at mac.com>
> Cc: Paul Schlie <schlie at comcast.net>, John Clements
> <clements at brinckerhoff.org>, PLT Scheme Mailing List
> <plt-scheme at list.cs.brown.edu>
> Subject: Re: [plt-scheme] Help with #0 and #0# notation in the REPL
> 
> Ha! I see I'm not helping with that, am I! :) Let me try to explain.
> 
> When you write
> 
>   (define x (shared ((x (cons 1 x))) x))
> 
> you are actually creating a cycle that does not exist until the code
> is actually evaluated. That is, the cycle creation is part of the
> process of the evaluation of your program.
> 
> On the other hand, when you write:
> 
>   (define x '#1=(1 . #1#))
> 
> the cycle exists *before* your code is evaluated. The cycle is, in
> fact, created as part of the process of parsing (technically,
> 'read'ing) your code. What you are saying, in effect, is "mr.
> compiler, please create an abstract syntax tree for my program such
> that the ast itself has a cycle in it".
> 
> While this is more expressive, it is not clear that it pays for
> itself, in terms of the maintenance burden it puts on tool authors.
> That is, every tool you might run on a program (check syntax,
> profiler, debugger, type checker, etc etc etc) all now have to cope
> with inputs that aren't just trees, but are cycles. On the other hand,
> you can still certainly create cycles (using `shared' or, if
> appropriate, mutation) but those cycles won't actually exist until
> your code is evaluated. So, while we have taken something away, we
> haven't take very much away, and we have bought ourselves something.
> (Indeed, an early version of check syntax failed to terminate on such
> programs; it went into an infinite loop coloring those cycles ...)
> 
> Hopefully that's a little more clear.
> 
> Robby
> 
> On Jan 29, 2008 9:43 PM, Richard Cleis <rcleis at mac.com> wrote:
>> 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
>>