Re: Suggestion for pretty_print()
Robert Craig wrote:
>
> Juergen Luethje wrote:
> > > Rob, how about this:
> > > You could ship Euphoria with the user defined type "string". In contrast
> > > to suggestions that had been made in the past concerning a "string"
> > > type, this would not mean any change of Euphoria's internal affairs
> > > during normal operation. People use a user defined "string" type anyway,
> > > and when using "without type check", there is no loss of speed.
> > > The advantage would be that in case of a crash, Euphoria knows what
> > > constants and variables are strings, and can display them accordingly.
> >
> > The following is probably even better:
> > Provide a new keyword "string", which is just handled as an alias for
> > "sequence" during normal operation. But the internal routine that writes
> > the ex.err dump can take advantage of the additional information which
> > sequence is a string.
> >
> > <snip>
> >
> > Regards,
> > Juergen
> >
> > PS: As a positive side-effect, declaring strings explicitely as "string"
> > rather than as "sequence" increases the readability of the code.
>
> It's an interesting idea, but most strings in an ex.err dump
> are probably elements of larger sequences. Most aren't aren't stored
> as simple strings in individual variables. For instance,
> a symbol table might contain a thousand entries, each represented by
> a sequence containing a mixture of string and numeric fields.
> Simply having a "string" type wouldn't let you define to the ex.err
> dumper which fields are string and which are numeric in a
> complicated sequence.
>
> Also, when I get an ex.err dump, I usually just check the
> statement where the error occurred, and the error message,
> and sometimes I look at the values of 2 or 3 variables that
> are used near the crash point. It's not that big a deal if
> I sometimes see a mixture of characters and numerics in a
> variable value. It's a bit cluttered, but does it warrant a
> new language feature just to reduce the clutter?
One thing that got me interested in this thread was what sounding like your
willingness to consider adding a flag in the interpreter:
> With pretty_print() the programmer gives me some idea of
> how he wants his output to look. With an ex.err dump,
> I don't know whether data should be displayed as a number
> or as a character, so when the value is in the range of
> an ASCII character, I display it both ways. This may be hard
> to read, but it's better than if I guess wrong and display
> a bunch of gibberish characters, or a bunch of ASCII codes,
> forcing the programmer to pull out an ASCII chart and
> decipher it.
>
> It might be possible for me in the future to add a field to
> the symbol table that says whether a variable is
> "almost certainly character", "almost certainly numeric"
> or "unknown", based on what I can tell from all the
> assignments to it. I don't know how well that would work though.
>
> In 2.5, you can create a crash routine. You could program it
> to display some of your major data structures in a nicely
> formatted way.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
This of course made me think that adding a "string" type and having the
interpreter remember wheter it was handling character data instead of integers
was a possibility.
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
--
"Actually, I'm sitting on my butt staring at a computer screen."
- Tom Tomorrow
j.
|
Not Categorized, Please Help
|
|
