[Jscheme-user] Re: trimming listener output

[Robert M. <rma...@bb...>]

Hi, Tim,

Sorry I've let this languish so long.  Basically, I went off and did
something quick that worked for me, but now Rusty wants it too so it's
time to think about folding back in my changes, if the community likes
them.

Tim wrote:
> The easiest thing to do as a first step is to create a public static int
> variable to that gives the global print depth (zero for infinite depth?
> zero by default?) The REPL could set it to a reasonable value for
> interactive sessions. We could specify an interactive session on
> the command line:
> 
>    % java -cp jscheme.jar jscheme.REPL -interactive
> 
> One could also change the depth at runtime:
> 
>    > (set! jsint.Scheme.printDepth$ 10)

I like this, and it's pretty much what I had started to implement on
my own before writing to you, but I'd rather have the REPL assume
interactive by default, if it won't break too much legacy stuff out
there.  My current solution is somewhere in between -- I hush errors
by default (actually, based on nameResults, which is on by defaul) but
set a very high limit (Integer.MAX_VALUE) for list-print length.

I've made three changes in my version I'd like to propose to share:

1. When nameResults is on in readEvalWriteLoop, just return the
   Throwable object when eval throws an exception.  The user can then
   call printStackTrace for more information, but in most cases the
   toString you get is all you need.

2. Remove special toString from BacktraceException.  The current
   toString prints a whole stack trace.  If I'd wanted that, I
   woulda called printStackTrace.  The default toString (class name
   and message) tells you plenty, most of the time.  (Sometimes the
   message comes out blank, but I don't have a great fix for that
   yet.  Currently, I just call printStackTrace or getBaseException,
   but I'd rather fix the constructor to avoid them.)

3. Change stringifyPair to have a maximum print length.  This is sort
   of like the printDepth variable Tim proposed, but more limited in
   scope.  In my current implementation, I have to set the max length
   manually (set! Pair.maxlistprint$ 10).

What do you (all) think?

Robert