+1 for your reasoning. I feel the current wording is just a slip in order to tell 'display' should handle cyclic structures. Lazy infinite list is out of domain of r7rs, so what would happen when such structure is given should be left unspecified. Gauche already has auto-forcing lazy lists, so I cannot help but making display run infinitely...
If it is indeed the intention of the standard, can it be fixed by small editing? e.g. "However, display must always terminate even when the obj contains cycles"? On Thu, Nov 22, 2012 at 1:49 PM, Per Bothner <[email protected]> wrote: > The specification for display is: > > However, display must always terminate. Thus if the nor- > mal write representation is used, datum labels are needed > to represent cycles as in write. > > I think this is wrong, and (arguably) misunderstands what > display is about, which IMO is to produce plain unadorned > human-readable output without extra delimiters. Infinite > data structures *should* produce infinite output. Many > programs are intended to run "indefinitely", and so any > attempt to prohibit unbounded output is misguided. > > Consider for example an extension with infinite lists or strings, > with automatic forcing. The semantics of such a string is like > a regular string, but of unbounded length, with characters > calculated as needed. In that case the "correct" implementation > of display is to display each chunk of text as it becomes available. > > I.e. an infinite lazy data-structure should produce infinite > output - and therefore an infinite non-lazy cyclic data-structure > should produce infinite output, for consistency. > > I will not implement this rule in Kawa (unless I get around to > doing at as part of a "pedantic" mode), as it conflicts with > my conception of how to handle laziness. > -- > --Per Bothner > [email protected] http://per.bothner.com/ > > _______________________________________________ > Scheme-reports mailing list > [email protected] > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
