Re: Suggestion for pretty_print()

new topic     » goto parent     » topic index » view thread      » older message » newer message

Juergen Luethje wrote:
> 
> Me wrote:
> 
> > Robert Craig wrote:
> > 
> >> Bernie Ryan wrote:
> >>> While your at it; how about an option in the ex.err dump
> >>> to turn off the mixing of the numbers in a text sequence.
> >>> when I am looking at a crashed file I want to just see the
> >>> text in large sequences instead of spending a half hour
> >>> try to decipher character embedded with their numeric equivelents.
> >> 
> >> 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.
> > 
> > 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.

I like the idea of having a "string" type as a subclass of the "sequence" type.
Like integer as a subclass of atom, I think it would allow some internal
optimization of the interpreter, better readability of code, and as pointed out
better readability in ex.err and the tracer.

--
"Actually, I'm sitting on my butt staring at a computer screen."
                                                  - Tom Tomorrow

j.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu