1. Suggestion for pretty_print()
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
2. Re: Suggestion for pretty_print()
- Posted by Robert Craig <rds at RapidEuphoria.com>
Dec 02, 2005
-
Last edited Dec 03, 2005
Juergen Luethje wrote:
> the following code snippet:
>
> }}}
<eucode>
> include misc.e
> constant text =
> {
> "This is\tline 1.\n",
> "Here comes\tline 2.\n"
> }
> pretty_print(1, text, {3})
> </eucode>
{{{
>
> 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"
> }
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.
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.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Suggestion for pretty_print()
- Posted by Juergen Luethje <j.lue at gmx.de>
Dec 02, 2005
-
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
4. Re: Suggestion for pretty_print()
- Posted by Bernie Ryan <xotron at bluefrog.com>
Dec 02, 2005
-
Last edited Dec 03, 2005
Robert Craig wrote:
>
>
> 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.
> 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.
>
Rob:
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.
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.exw
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
5. Re: Suggestion for pretty_print()
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
6. Re: Suggestion for pretty_print()
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.
> 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.
Bernie:
Until there will be a better solution, you can use my contributiuon
<http://www.rapideuphoria.com/errconv.zip>. It makes it possible for
an Eu 2.5 program to convert its own "ex.err" file after a crash.
Regards,
Juergen
7. Re: Suggestion for pretty_print()
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.
8. Re: Suggestion for pretty_print()
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.
9. Re: Suggestion for pretty_print()
- Posted by Robert Craig <rds at RapidEuphoria.com>
Dec 03, 2005
-
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
10. Re: Suggestion for pretty_print()
- Posted by Vincent <darkvincentdude at yahoo.com>
Dec 03, 2005
-
Last edited Dec 04, 2005
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. 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.
Regards,
Vincent
11. Re: Suggestion for pretty_print()
- Posted by Ryan W. Johnson <ryanj at fluidae.com>
Dec 03, 2005
-
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...]
12. Re: Suggestion for pretty_print()
Ryan W. Johnson wrote:
>
> 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
>
Because "string" is a common variable name and would break a large body of code.
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
13. Re: Suggestion for pretty_print()
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
14. 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.
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?
15. Re: Suggestion for pretty_print()
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?
16. Re: Suggestion for pretty_print()
Juergen Luethje wrote:
>
> 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?
Yes I agree... I think there should be profile_time support on all platforms,
and the ability able to pass 32 bit integers to exported routines in
translated/compiled DLL/SOs. A Resource feature for the translator so we can add
our own icons, would also be helpful. Rob can consider some of these for the next
release. Later releases could have features I've talked about in great detail
many times 
.
I think we should fix up our useful "patchwork" libraries as part of the ESL
distribution. The ESL distribution could also include the original Euphoria
standard library, plus the new libraries being proposed and agreed upon.
Eventually the ESL project should completely replace the old Euphoria standard
library, and all the used "patchwork" libraries be removed from the archive. All
these libraries should follow the coding and commenting guidelines. Redundant
libraries should be excluded and micro-economy votes be rewarded toward future
purchases.
ESL could become a complete standardized library for use with Euphoria
development, that is public-domain and that offers us most of the basic features
we need. RDS could then include this library as part of the Euphoria package.
This would be alot of work, but would pay off in the future. I think ESL could be
the greatest thing we all could do for Euphoria!
ESL should not include Win32Lib, wxEuphoria, etc.. those should remain as
seperate packages.
Regards,
Vincent
17. Re: Suggestion for pretty_print()
- Posted by Jason Gade <jaygade at yahoo.com>
Dec 04, 2005
-
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.
18. Re: Suggestion for pretty_print()
- Posted by Jason Gade <jaygade at yahoo.com>
Dec 04, 2005
-
Last edited Dec 05, 2005
Vincent wrote:
>
> Juergen Luethje wrote:
> >
> > 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?
>
> Yes I agree... I think there should be profile_time support on all platforms,
> and the ability able to pass 32 bit integers to exported routines in
> translated/compiled
> DLL/SOs.
Supported by Matthew Lewis' library in the archive
http://www.rapideuphoria.com/32bits.zip
> A Resource feature for the translator so we can add our own icons,
> would also be helpful. Rob can consider some of these for the next release.
> Later releases could have features I've talked about in great detail many
> times
> .
>
> I think we should fix up our useful "patchwork" libraries as part of the ESL
> distribution. The ESL distribution could also include the original Euphoria
> standard library, plus the new libraries being proposed and agreed upon.
> Eventually
> the ESL project should completely replace the old Euphoria standard library,
> and all the used "patchwork" libraries be removed from the archive. All these
> libraries should follow the coding and commenting guidelines. Redundant
> libraries
> should be excluded and micro-economy votes be rewarded toward future
> purchases.
>
> ESL could become a complete standardized library for use with Euphoria
> development,
> that is public-domain and that offers us most of the basic features we need.
> RDS could then include this library as part of the Euphoria package. This
> would
> be alot of work, but would pay off in the future. I think ESL could be the
> greatest
> thing we all could do for Euphoria!
Vincent, I think you have the wrong idea about ESL. It is not supposed to
replace the Euphoria standard includes, but complement them. And I definitely
disagree with removing libraries of useful routines from the archive!
ESL should extend the Euphoria standard includes by having a collection of often
reimplemented routines. Stuff like a string library, a structure library, some
math routines, and better file handling. We look both at current programs and
features in other languages.
Someone else was writing an actual replacement for the Euphoria standard
includes; I don't think it ended up going anywhere.
> ESL should not include Win32Lib, wxEuphoria, etc.. those should remain as
> seperate
> packages.
>
>
> Regards,
> Vincent
--
"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
-
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.
20. Re: Suggestion for pretty_print()
- Posted by Vincent <darkvincentdude at yahoo.com>
Dec 04, 2005
-
Last edited Dec 05, 2005
Jason Gade wrote:
> Supported by Matthew Lewis' library in the archive
> http://www.rapideuphoria.com/32bits.zip
Yes I know, but it should be supported by translator without a library.
> Vincent, I think you have the wrong idea about ESL. It is not supposed to
> replace
> the Euphoria standard includes, but complement them. And I definitely disagree
> with removing libraries of useful routines from the archive!
>
> ESL should extend the Euphoria standard includes by having a collection of
> often
> reimplemented routines. Stuff like a string library, a structure library, some
> math routines, and better file handling. We look both at current programs and
> features in other languages.
>
> Someone else was writing an actual replacement for the Euphoria standard
> includes;
> I don't think it ended up going anywhere.
I dont have the wrong idea, if ESL eventually becomes bundled with the Euphoria
download packages, then it would have the RDS libs included with it, along with
new documentation and example programs. Until then though, I suppose we could
consider it an extention.
If ESL has improved versions of some libraries currently in the archive, it
would be pointless to keep the old ones there. Why would you want to have two
places to download the same library? That would waste webspace. We can just
download ESL from the archive, later also have it part of Euphoria. But there is
a good chance Rob will just leave them in the archive anyway, to keep you happy,
and for those who use old versions of Euphoria.
Existing "patchwork" libraries should be utilized in ESL, not completely
re-done from scratch; that only wastes time and re-invents the wheel. Only
libraries that do not already exist need to be written. This happens to be the
case for many of the proposed modules in ESL, which is fine.
Regards,
Vincent
