OpenEuphoria

1. Suggestion for pretty_print()

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

Hello Rob,

the following code snippet:

include misc.e
constant text =
               {
                 "This is\tline 1.\n",
                 "Here comes\tline 2.\n"
               }
pretty_print(1, text, {3})

prints (Eu 2.5):
{
  {'T','h','i','s',' ','i','s',9,'l','i','n','e',' ','1','.',10},
  {'H','e','r','e',' ','c','o','m','e','s',9,'l','i','n','e',' ','2','.',
10}
}

But using the option {3}, pretty_print IMHO should output a string
_whenever possible_. Of course sometimes it's not possible, but special
characters that may be entered using a back-slash (as described in
refman_2.htm#char), should be displayed by pretty_print() in the same
way, and not cause an output as shown above. The output in this case
should be identical to the data, i.e.
{
  "This is\tline 1.\n",
  "Here comes\tline 2.\n"
}

Regards,
   Juergen

3. Re: Suggestion for pretty_print()

• Posted by Juergen Luethje <j.lue at gmx.de> Dec 02, 2005
• 511 views
• Last edited Dec 03, 2005

Robert Craig wrote:

<snip>

> I guess that would make sense, since the programmer
> who uses option 3 probably believes that all his data is string data. 
> I'll include \t \n \r as "ASCII" characters for that option.

Thanks.

> For the other options, low integers such as 9, 10, 13 would be
> quite common, and I suspect would not be considered to be characters
> in most cases.

I agree.

Regards,
   Juergen

5. Re: Suggestion for pretty_print()

• Posted by Robert Craig <rds at RapidEuphoria.com> Dec 03, 2005
• 522 views

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.

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

7. Re: Suggestion for pretty_print()

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

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.

9. Re: Suggestion for pretty_print()

• Posted by Robert Craig <rds at RapidEuphoria.com> Dec 03, 2005
• 493 views
• Last edited Dec 04, 2005

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

11. Re: Suggestion for pretty_print()

• Posted by Ryan W. Johnson <ryanj at fluidae.com> Dec 03, 2005
• 500 views
• Last edited Dec 04, 2005

Juergen Luethje wrote:
 
> 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.

Yes, i agree. We have "atom" and "integer", why not "sequence" and "string"?
~Ryan W. Johnson

[cool signature here, if i ever think of one...]

13. Re: Suggestion for pretty_print()

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

D. Newhall wrote:

> Ryan W. Johnson wrote:

<snip>

>> Yes, i agree. We have "atom" and "integer", why not "sequence" and "string"?
> 
> Because "string" is a common variable name and would break a large body of
> code.

You can now even use "sequence" as variable name (tested with Eu 2.5):

sequence text
atom sequence

text = "Huhu"
sequence = 3
puts(1, text & "\n")
? sequence

After exchanging the first two lines, you'll get an error, though.

However, it shouldn't be too hard to rename variables from "string" to
"String" or whatever. In the archives, there are alpha versions from
the year 2000 or so. I think it's time to revise these programs anyway.


Regards,
   Juergen

15. Re: Suggestion for pretty_print()

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

Vincent wrote:

> Robert Craig wrote:
> 
>> It's a bit cluttered, but does it warrant a 
>> new language feature just to reduce the clutter?
> 
> No it doesn't, because we can just use Juergen's error dump library to
> disambiguate ACSII characters from their numeric values.

Thanks.   However ...

... we also need e.g.
- my "Lfn.zip" library to use long file names on DOS
- Greg's "win_dir.zip" library for a good dir() function on Windows
- Matt's "32bits.zip" library to be able to pass 32-bit parameters to
  routines in a DLL
- a library to have something like 'profile_time' on Windows
- a library with memory routines such as poke2() etc.
- one out of about half a dozen 'record' libraries

... and so on. Every experienced Eu programmer can continue the list
her/himself. Please note that I'm only talking here about very basic
features, that are part of the standard distribution of many or most
other general purpose programming languages nowadays. Using user
contributions for all this is far too much patchwork concerning to my
taste.

Please allow me to quote myself:
| For several years, many Euphoria programmers have written a total of
| more than 1400 user contributions, which can be downloaded from the
| archives at RDS's website. Almost all of them are written by a single
| person. Their quality varies from contributions by highly qualified I.T.
| professionals and university research scientists, to the first
| programming steps of beginners. Sometimes looking in the archieves for a
| certain module is like searching for a needle in a haystack, and after
| having found something, it might be hard to consider especially for
| inexperienced programmers, whether or not that code is reliable.
| 
| Since the system of unrelated individual user contributions is just
| "patchwork", several routines (e.g. for reading a null-terminated string
| from memory) are contained in many contributions, and maybe the user
| also has written such a function himself. This is a common source for
| naming conflicts. This also means re-inventing the wheel several times,
| which is an unnecessary waste of time and efforts.

> Plus we can often use crash_routine for runtime errors, and have it
> write important string values to screen or file. In both cases, it can
> be formatted "pretty" with pretty_print.

BTW, as Jason wrote, not "only" the ex.err dump is cluttered, but also also
the output of trace(). This can't be changed by my 'errconv.zip' library.

Regards,
   Juergen

-- 
Have you read a good program lately?

17. Re: Suggestion for pretty_print()

• Posted by Jason Gade <jaygade at yahoo.com> Dec 04, 2005
• 513 views
• Last edited Dec 05, 2005

Juergen Luethje wrote:
> 
> 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.

The thought of strings and data mixed in sequences did occur to me, but I still
think that a "string" type is a good idea.

I think you found the solution above: the interpreter should remember if a
sequence or subsequence is assigned using quotes instead of braces. Or if a
subsequence is assigned the value of a "string" variable or a function that
returns a "string". The interpreter could flag whether something was a string or
not by using these cues.

> 
> > 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().

The problem is deciding whether a sequence or subsequence of small integers
(0-255) is a string or just numbers. By having a "string" type and by remembering
whether something was assigned using quotes or a "string" variable/function may
solve that ambiguity.
 
> 
> 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.

The interpreter automatically promotes sequences of integers to atoms internally
when necessary, and keeps track of that. It may be a lot of work to do the same
thing with strings, but I think it makes sense.

One thing I love about Euphoria is the nearly typeless system. I wouldn't want
to see it polluted with a lot of unnecessary built-in types. However, I think a
built-in string type makes sense, is orthogonal with the way the language handles
integers, atoms, and sequences, and could improve the language.

I know one forum poster who often deals with multi-megabyte text data files who
would probably appreciate it if strings were more optimized internally and took
up less than 4 bytes per character...

> 
> Regards,
>    Juergen
> 
> -- 
> Have you read a good program lately?


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

j.

19. Re: Suggestion for pretty_print()

• Posted by Jason Gade <jaygade at yahoo.com> Dec 04, 2005
• 501 views
• Last edited Dec 05, 2005

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.