Basically, I'm just suggesting that the xml package have sensible printing of its structures. I can't imagine any case where you really want the default printing of recursive structures of that complexity and potential size to be the visible behavior.
Where it was annoying me was in my inference engine when I was doing inference across very large xml documents. I have a trace feature in the inference engine to trace assertions that is very useful for debugging rules. You can imagine the output when I turned it on the first time with one of the large xml documents. Literally, one assertion was 100+ pages. I've pushed a new version of the inference engine that uses ~.s throughout. So, at least it prints it reasonable. But, it is still continually walking the structures and building a huge string (at least 10s of megabytes each at the highest levels). And, it has to do that for every assertion in a trace. At least I have a large memory machine with plenty of memory (and, thanks to you guys, a 64-bit windows version), so it does run. It's just annoying. On Mon, Oct 3, 2011 at 4:34 PM, Matthias Felleisen <matth...@ccs.neu.edu>wrote: > > Doug, does this concrete example concerning printing help: > > #lang racket/load > > (module a racket/base > (struct xml (bar) #:transparent) > > (define x (xml "bar")) > (displayln x) > > (provide (struct-out xml) x)) > > (module b racket/base > (require 'a) > > (struct my xml () #:property prop:custom-write (lambda (x p z) (displayln > "<my xml>" p))) > > (define y (my "bar")) > > (displayln y)) > > (require 'b) > > >
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
