1. Suggestion for pretty_print()
- Posted by Juergen Luethje <j.lue at gmx.de> Dec 02, 2005
- 577 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
2. Re: Suggestion for pretty_print()
- Posted by Robert Craig <rds at RapidEuphoria.com> Dec 02, 2005
- 508 views
- 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
- 509 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
4. Re: Suggestion for pretty_print()
- Posted by Bernie Ryan <xotron at bluefrog.com> Dec 02, 2005
- 533 views
- 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()
- Posted by Robert Craig <rds at RapidEuphoria.com> Dec 03, 2005
- 520 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
6. Re: Suggestion for pretty_print()
- Posted by Juergen Luethje <j.lue at gmx.de> Dec 03, 2005
- 494 views
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()
- Posted by Juergen Luethje <j.lue at gmx.de> Dec 03, 2005
- 493 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.
8. Re: Suggestion for pretty_print()
- Posted by Jason Gade <jaygade at yahoo.com> Dec 03, 2005
- 511 views
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
- 491 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
10. Re: Suggestion for pretty_print()
- Posted by Vincent <darkvincentdude at yahoo.com> Dec 03, 2005
- 497 views
- 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
- 499 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...]
12. Re: Suggestion for pretty_print()
- Posted by D. Newhall <derek_newhall at yahoo.com> Dec 04, 2005
- 485 views
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()
- Posted by Juergen Luethje <j.lue at gmx.de> Dec 04, 2005
- 482 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
14. Re: Suggestion for pretty_print()
- Posted by Juergen Luethje <j.lue at gmx.de> Dec 04, 2005
- 493 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?
15. Re: Suggestion for pretty_print()
- Posted by Juergen Luethje <j.lue at gmx.de> Dec 04, 2005
- 484 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?
16. Re: Suggestion for pretty_print()
- Posted by Vincent <darkvincentdude at yahoo.com> Dec 04, 2005
- 485 views
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
- 512 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.
18. Re: Suggestion for pretty_print()
- Posted by Jason Gade <jaygade at yahoo.com> Dec 04, 2005
- 496 views
- 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
- 500 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.
20. Re: Suggestion for pretty_print()
- Posted by Vincent <darkvincentdude at yahoo.com> Dec 04, 2005
- 563 views
- 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