Re: Suggestion for pretty_print()
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?
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
