OpenEuphoria

Re: Suggestion for pretty_print()

• Posted by Juergen Luethje <j.lue at gmx.de> Dec 04, 2005
• 494 views

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.

Oh, I see. I didn't think of that.
However, the interpreter has some additional information about what is a
string. I think it can safely consider any sequence as string, that is
defined in the source code by using quotes. When the programmer writes:
   sequence s
   s = "red"

s/he wants to deal with a string. When s/he writes:
   sequence s
   s = {114,101,100}

then s/he wants to deal with three numbers.
But currently I think both expressions are exactly the same for Euphoria
internally. Immediately after reading the source code, the interpreter
'forgets' about the fact, that "red" and {114,101,100} are intended to
express different things.
Also e.g. lines that are read from a file by gets() are strings, of
course.

> 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?

Did it warrant a new language feature just to allow us to replace
"x[length(x)]" with "x[$]"? My personal answer clearly is "Yes".
You know that in the past many people have asked for a readable ex.err
dump. As Jason wrote, this also affects the output of trace().

I am pretty sure that such "ugly spots on the beautiful face" of
Euphoria must be removed, when you want Euphoria to get a considerably
larger number of users.

Regards,
   Juergen

-- 
Have you read a good program lately?