>At 09:01 AM 4/13/00 -0700, Dan Ingalls wrote:
>>"R. A. Harmon" <harmonra at webname.com> wrote...
>>>Evaluating:
>>>
>>>	ContextPart trace: [OrderedCollection new]
>>>
>>>cause a MNU error because index (= firstIndex = nil) <= lastIndex (= nil).
>>>
>>>My proposed fix is the following:
>>
>>	<Nil-tolerant code for OrderedCollection do:>
>>
>>I'm wondering if it wouldn't be better to wrap an exception around trace:'s
>> attempt to print.  Otherwise we might find ourselves sprinkling lots of code
>> around that wastes time just because of wanting to print things that are in
>> an inconsistent state.
>[snip]
>
>After I sent the fix, I got to wondering if I any of my stuff would work
>with trace.  I  suspect not, and don't relish the probably very ugly task of
>getting it to do so.
>
>The more I think about it the less sure I become either way.
>
>Other folks?

Well, I can tell you that trace was really only put there as an example of what context stepping (in ST-76!!) could do.  I suggest not trying to make trace work as it stands, for the reasons we have already discussed and others as well (many values are huge to print, for example, even when they are valid).

Instead I would eschew the printing of values, or allow it to be informed by the user (as in, "show me the range of every Interval").  This could be expressed as a block, as in
	ContextPart trace: [block with lots to do]
		printingValuesAs: [:v :strm | (v isKindOf: Interval) ifTrue: [strm print: v]]
This way any problematic case can be dealt with by appropriate degrees of circumlocution.  Moreover it would be simple to incorporate the exception wrapper in this protocol as a default implementation of the old trace: (but you still need to do something about big strings ;-).

Without printing, the context simulator is quite solid, as you can see from, eg, MessageTally>>tallySends:.

	- Dan