Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

make-doc-pro: how to handle tables?

 [1/28] from: robert::muench::robertmuench::de at: 21-Sep-2001 15:59


Hi, I'm going to add table support to make-doc-pro. I'm interested in your opinion how to do it and what syntax to use. Currently I'm thinking about something like this: first cell | second cell | last cell second line| ... What do you think? Robert

 [2/28] from: joel:neely:fedex at: 21-Sep-2001 10:29


Hi, Robert, Robert M. Muench wrote:
> Hi, I'm going to add table support to make-doc-pro. I'm > interested in your opinion how to do it and what syntax > to use. Currently I'm thinking about something like this: > > first cell | second cell | last cell > second line| ... >
I used a slightly different approach in a "wiki-like" script that I wrote a while back. ~|first cell|second cell| ... |last cell| ~!cell first!cell second! ... !cell last! ~:primo cell:secundo cell: ... :ultama cell: ~$unum$ duo$ ... whatever$ In other words, the tilde as a first character identified the line as beginning another row of the table. The character immediately following the tilde was taken as the cell delimiter *for*that*row*only* so that the writer could use whatever punctuation made sense relative to the actual content (even if it needed to change from row to row within a single table). The table was terminated by the appearance of an empty line. The combination of the two rules above meant that a line that began with a tilde, along with all subsequent non-empty and non-tilde-beginning lines, together made up a single row. This allowed the author the option of entering the cells in a row vertically instead of horizontally, a convenience in some cases. -jn- -- This sentence contradicts itself -- no actually it doesn't. -- Doug Hofstadter joel<dot>neely<at>fedex<dot>com

 [3/28] from: greggirwin:starband at: 21-Sep-2001 11:08


Robert, Joel, et al << ~|first cell|second cell| ... |last cell| ~!cell first!cell second! ... !cell last! ~:primo cell:secundo cell: ... :ultama cell: ~$unum$ duo$ ... whatever$
<snip>
...The combination of the two rules above meant that a line that began with a tilde, along with all subsequent non-empty and non-tilde-beginning lines, together made up a single row. This allowed the author the option of entering the cells in a row vertically instead of horizontally, a convenience in some cases. >> I've done simliar things myself (not quite as cool...<g>) but, to me, the make-doc format should be as simple as possible to write, even at the expense of flexibility. What if you started off with a familiar idiom, as used for notes (bear in mind that I've only glanced at the make-doc format so I'll undoubtedly post some bad suggestions here). E.g. \table <<table data goes here>> /table Now, what else do we need for a table, besides data? A heading: \table "Table 1" <<table data goes here>> /table What if you have a table that makes more sense to enter as columns, rather than rows? How about a /pivot refinement. Are there any other refinement type things used in make-doc? Not sure how usefult this would be, but it's along the lines of "how would we extend the syntax?" Other example extensions would be things like column widths and cell alignments. Maybe a table gets a header block with extra data. \table "Table 1" /pivot <<table data goes here>> /table Data: I'm very fond of whitespace, and I like it when things line up. When using a delimiter, such as a pipe, it sometimes isn't clear if whitespace is significant, or if the delimiter is the only thing that matters. I.e. can you pad your cell data with spaces so they line up nicely or will those extra spaces go into the table? Can we do it with a minimal syntax of tab separated values? If tabs aren't used, can a minimum number of spaces be substituted in their place? For example, cell data is only allowed to have a single space between words, any more than that and the next bit of data is considered to be in the next cell. 1 2 3 4 5 6 7 8 9 Item 1 Item 2 Item 3 Item 4 Item 5 Item 6 Item 7 Item 8 Item 9 How would you insert a newline in a cell? Just some thoughts, FWIW. Thanks for your work on make-doc Robert! Ultimately, wouldn't it be great to write a human friendly RebTeX dialect? PDFMaker might be a good start on something like that. --Gregg

 [4/28] from: robert:muench:robertmuench at: 21-Sep-2001 20:30


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 8>>
> <<table data goes here>> > /table
Hi, that's exactly what I implemented: \table first cell | second cell /table
> Now, what else do we need for a table, besides data? A heading:
This is on the todo for tables as I have to think about how to implement the heard with HTML.
> ...
Wow, thanks for all those thoughts about tables. I think I will need some time to make it through them.
> Just some thoughts, FWIW. Thanks for your work on make-doc Robert!
:-)
> Ultimately, wouldn't it be great to write a human friendly RebTeX > dialect? PDFMaker might be a good start on something like that.
I hope make-doc-pro is quite human friendly. Yes, and the PDFmaker stuff is still on my todo list. First I wanted to make make-doc-pro mostly feature complete before moving on for a new output format. Robert

 [5/28] from: al:bri:xtra at: 22-Sep-2001 8:21


Robert wrote:
> Hi, I'm going to add table support to make-doc-pro. I'm interested in your
opinion how to do it and what syntax to use. Currently I'm thinking about something like this:
> first cell | second cell | last cell > second line| ... > > What do you think?
I quite like: first cell second cell last cell second line where the large spaces are tab characters. Which can be expressed in a eText rule much like: Table: make object! [ Type: 'TH Mark: #"|" NonBar: exclude Printable charset to-string Mark Cells: make block! 10 BarCell: [Mark Align copy Line some NonBar] TabCell: [copy Line some Printable Line] Append-Cell: does [ repend Cells [make path! reduce [Type Align!/Type] Inline Line] ] Row: [ [ [ opt [some [Mark some #"-"] opt Mark newline] some [BarCell (Append-Cell)] opt Mark ] | Align TabCell (Append-Cell) some [ tab Align TabCell (Append-Cell) ] ] newline ] Rows: make block! 10 Rule: [ opt Empty ( Type: 'TH Rows: make block! 10 Cells: make block! 10 ) some [ Row ( repend Rows ['TR Cells] Type: 'TD Cells: make block! 10 ) ]( repend Block ['Table Rows] ) ] ] and seems to work quite well for me. Andrew Martin ICQ: 26227169 http://zen.scripterz.org

 [6/28] from: al:bri:xtra at: 22-Sep-2001 9:52


It's amazing how those little bugs creep in...
> TabCell: [copy Line some Printable Line]
should really be: TabCell: [copy Line some Printable] Andrew Martin Red-faced Rebol scripter... ICQ: 26227169 http://zen.scripterz.org

 [7/28] from: robert:muench:robertmuench at: 22-Sep-2001 11:06


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 6>>
> second line > where the large spaces are tab characters.
Hi, I don't like using white-spaces as formating rules because not so experienced users don't understand the difference between usig space, tab etc. These people need a visual feedback, that's why I used the | character, which is IMO quite logical. Robert

 [8/28] from: cybarite:sympatico:ca at: 22-Sep-2001 7:14


Robert, \my $0.02 I like the REBOL approach for "tables" table: [ [r1c1 r1c2 r1c3] [r2c1 r2c2 r2c3] [r3c1 r3c2 r3c3] ] which is just a REBOL definition that allows access to the cells: table/1/3 table/3/1 If it was just one row then it would be table: [c1 c2 c3] With this approach, the table can be manipulated by REBOL for doing things like pivot which might be a "reverse" which handles all rows. The reason for using a REBOL format is that I want to be able to generate a document that uses data that is in the REBOL script or accessible via the REBOL script such as extracts from internet sites. i.e it is not just text. You might be doing this in make-doc-pro but I didn't think so from what I read. i.e. I want the option to make a cell's value to be executable REBOL code. And I wanted it evaluated at document generation time. Then this would be a table to me: table: [ ["The time is" (form now)] ["The extract is" (copy/part read http://www.rebol.com 10)] ["The extract file was updated at" (modified? %\c\extract.r)] ] And I could display this in an html table by linking the data definition part of above to some presentation specification. So this is like the data part of the SUPPLY approach used in VID. And it looks like the spreadsheet that Carl did. In a make-doc version, I would then want to: a. define a table with a do block as was done in vid layout ===ISO Currency Codes do [iso-codes: [ "USD" "US Dollars" "GBP" "Great Britain Pounds" ] ] b. use the table in the make-doc text portion by referencing the REBOL name of the block. c. if the data was not re-usable then defining it inline using the block structure makes sense. \table ["USD" "US Dollars" "GBP" "Great Britain Pounds" ] presentation-style-definition /table I think the data definition part of it is the easier part. That "presentation-style-definition" is the hard part. /my $0.02

 [9/28] from: joel:neely:fedex at: 22-Sep-2001 3:23


Robert M. Muench wrote:
> > -----Original Message----- > > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 13>>
> These people need a visual feedback, that's why I used the | > character, which is IMO quite logical. Robert
Whitespace is also ambiguous (even for more experienced eyes, IMHO). When using whitespace one must address the issue of how much whitespace is considered a column break (since it also may appear *within* a column, e.g. between words). Tabs do not solve this problem, as one cannot in general look at printed or displayed text and distinguish tabs from blanks. Using a distinct, visible character eliminates those issues. Since, in general, one does not know what data may appear in the content, any pre-selected character will eventually be wrong for some purpose. Therefore my preference for allowing the delimiter to vary. These observations are coming from my experiences with mailing list management and conversion, data transformations in a variety of application areas, and developing pre-press software for book production. Although YMMV, I've always found it very useful to be as explicit as possible. And I must give credit to a saying I learned from my father, during his career as an aerospace engineer, quoted in my sig block below. -jn- -- Communicate not so that you MAY be understood, but so that you MUST be understood. --James Neely joel&dot&neely&at&fedex&com

 [10/28] from: robert:muench:robertmuench at: 22-Sep-2001 16:42


> -----Original Message----- > From: [jn--inet01--prod--fedex--com] [mailto:[jn--inet01--prod--fedex--com]]On
<<quoted lines omitted: 7>>
> wrong for some purpose. Therefore my preference for allowing > the delimiter to vary.
Hi, I know why to use this approach ;-) but it might not so easy to be included in the parsing rules. I think about it.
> And I must give credit to a saying I learned from my father, > during his career as an aerospace engineer, quoted in my > sig block below.
Well said! I only can second this. Robert

 [11/28] from: robert:muench:robertmuench at: 22-Sep-2001 16:42


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 6>>
> REBOL script or accessible via the REBOL script such > as extracts from internet sites. i.e it is not just text.
Hi, that's where I want to go to but step by step. Simple things first and than the rest. My goal is to expand make-doc-pro to handle blocks for rebol code that will produce an output string which is than substituted for the rebol code. This would give you the most flexible solution.
> i.e. I want the option to make a cell's value to be executable REBOL code. > And I wanted it evaluated at document generation time.
Yep, and not only for cell values but everywhere in a make-doc-pro text.
> And I could display this in an html table by linking the data > definition part of above to some presentation specification.
Referencing text/code blocks by name is something I'm going to add too. This enables you to use predefined content, layouts etc. Something like the template idea of word-processors.
> \table ["USD" "US Dollars" "GBP" "Great Britain Pounds" ]
I like this for headings but without the [] braces. I think I will add this. Robert

 [12/28] from: greggirwin:starband at: 22-Sep-2001 14:17


Joel, Robert, et al I have to disagree with you guys. I'll pick a couple points of contention and then give some thoughts and excercises. << not so experienced users don't understand the difference between usig space, tab etc. >> And they shouldn't have to. Now, there is going to be the challenge on the parsing side of making the distinction, but even that shouldn't be too tough using alternation of tab or multi-space. Do these two lines look the same to you? Do you care if one uses tabs and the other spaces? Tab Spaces Tab Spaces << These people need a visual feedback >> Whitespace *is* visual feedback. Do we need delimiters, beyond whitespace, in our REBOL code? Would we want them? Whitespace is the normal, human, delimiter that people are familiar with. Non-programmers are easily confused and frustrated by any kind of "syntax" in my experience. If the goal is to keep the make-doc format as human-friendly as possible, all extraneous syntax should be kept out of it. Variable syntax is very flexible, but it's even more confusing than static syntax to regular people. << Whitespace is also ambiguous (even for more experienced eyes, IMHO). >> Is this table data ambiguous to you? (providing it doesn't get munged in the mail :)) Widget A Widget B Widget C 50% 10% 3% 500,000 100,000 3,000 Does this make the data more accessible? Widget A|Widget B|Widget C 50% |10% |3% 500,000 |100,000 |3,000 Using the two example tables above, try this little experiment. Count your keystrokes as you go and time yourself if you feel so inclined. 1. Add a new row with the following data for each column: Bob Jones Ford Prefect Mary Smith 2. Change Ford Prefect's name to "Ford Prefect III" What do your tables look like now? How many keystrokes did it take you for each one? (if you post your results, make sure to note whether data keystrokes were counted (35 data keystrokes are required)) How long did it take you for each? Now for some thoughts... If you require a delimiter, it has two impacts: 1. The user has to mentally switch from "data" mode to "format" mode, and back to "data" mode again every time they enter a delimiter. 2. The delimiter is a small shifted key, usually located near the larger Enter and Backspace keys, which are both potentially destructive; Backspace to the data and Enter to the location. If they Shift key is missed, you'll get a backslash instead of a pipe, which is easily overlooked.
>From my perspective, we're dealing with text tables, not data tables. I
should be able to read the data clearly whether it's been formatted in make-doc or whether it's just plain text. Now, if I add spaces to align the text and the formatting engine doesn't make sense of that, it's a different issue. Using a special delimiter adds an artifical element to the mix. I certainly think we could come up with a cool table formatting dialect to surpass TBL and rival TeX, but that's not the goal right now so I think we should strive to remove all extraneous demands placed on the user. OTOH, let's suppose the user *does* enter data that confuses the table generator. What is the result? They have to regenerate the doc when they see the problem. For ease of use on a per-keystroke basis, and clearer data representation, I'd be willing to accept that. Let me know what you think. --Gregg

 [13/28] from: al:bri:xtra at: 23-Sep-2001 9:15


Robert wrote:
> Hi, I don't like using white-spaces as formating rules because not so
experienced users don't understand the difference between usig space, tab etc. These people need a visual feedback, that's why I used the | character, which is IMO quite logical. If you look closer, my design also used "|" as an alternative separator. Andrew Martin ICQ: 26227169 http://zen.scripterz.org

 [14/28] from: al:bri:xtra at: 23-Sep-2001 9:28


Mike mentioned:
> That "presentation-style-definition" is the hard part.
That's right. Laying out HTML generated from eText is quite hard to get right. It's one of the problems I'm wrestling with along with generating a complete site from eText. Andrew Martin ICQ: 26227169 http://zen.scripterz.org

 [15/28] from: joel:neely:fedex at: 22-Sep-2001 19:14


Hi, Gregg, Gregg Irwin wrote: ...
> Let me know what you think. >
... OK. You asked for it. ;-)
> Joel, Robert, et al > > I have to disagree with you guys. I'll pick a couple points of > contention and then give some thoughts and excercises. > > << not so experienced users don't understand the difference > between usi[n]g space, tab etc. >> > > And they shouldn't have to. >
That one wasn't mine, so I'll pass.
> Now, there is going to be the challenge on the parsing side of > making the distinction, but even that shouldn't be too tough > using alternation of tab or multi-space. >
You seem to be glossing over to one of the points I raised: When using whitespace one must address the issue of how much whitespace is considered a column break (since it also may appear *within* a column, e.g. between words). When you say "multi-space" you seem to imply more than one, but without actually saying what you mean. How about two? What does that do to the poor user who accidentally bounces the space bar at a point where a single space between words (in one column) was intended?
> Do these two lines look the same to you? Do you > care if one uses tabs and the other spaces? > > Tab Spaces > Tab Spaces >
Same issue. Look at these lines: Employee ID First Name Last Name Phone Nr -------- -- ----- ---- ---- ------ ----- -- 1234 John Doe 555-1212 2345 Jane Doaks 555-1213 3456 Ferdinando Quattlebaum 555-1214 4567 Mary Ellen Van Der Lin 555-1215 Being an intelligent human, you probably guessed that there were four columns, but you had to look at the entire context to figure that out. IOW, from the first two lines (or the last two), it would not be obvious MERELY ON SYNTACTICAL GROUNDS which blanks (if any) were column delimiters instead of data within a column. Using multiple blanks as column delimiters requires humans to count spaces (to make sure that we don't have an accidental extra blank) and to type extra spaces (which take more effort) just to be sure. Too fragile! Consider this variation of the above table: Employee ID First Name Last Name Phone Nr -------- -- ----- ---- ---- ------ ----- -- 1234 Johannes Doe 555-1212 2345 Betty Sue Doaks 555-1213 3456 Ferdinando Quattlebaum 555-1214 4567 Sue Ellen Van Der Lin 555-1215 How hard is that to proofread? Are you sure there are only four columns? OBTW, tabs are of absolutely no use in solving this problem. If, for example, an item ends on column 14 (1-origin), then keying a tab only takes one to column 16, which is visually indistinguishable from the result of typing a single space in column 15.
> << These people need a visual feedback >> > > Whitespace *is* visual feedback. >
Bah! Humbug! Horsefeathers! See the proofreading exercise above. Counting nonprinting characters to figure out *what* *kind* of delimiter (between words *in* a column or between columns) is an awful burden to lay on a poor human (technical or not!). Bear in mind, as you look at the above examples, that most of us (I assume that you are included in this) read our mail via a user interface that uses a monospaced font. Try changing your default mail client font to Helvetica, Palatino, or Times Roman and see how much fun you have counting spaces! And, yes, I know of non-technical end users that type text in uSoft Word and then "Save as..." plain text, because they don't know any other way to edit text. Unless they bother to change the font to Lucida Console, Courier, etc. or know how to change their default font (even less likely) they'll be looking at the text in a proportional font, which makes counting spaces a REAL PAIN.
> Do we need delimiters, beyond whitespace, in our REBOL code? >
We certainly do. Including [ ] ( ) { } and " . Note that the reason we need them is to show structure; as long as you're just typing a long trivial expression a: b + c + d + e + f + g ;; ... they aren't too critical. However, try using IF, WHILE, FUNC, etc. without any delimiters but whitespace, please! We're talking about tables here, where structure (and how to represent it in a simple, obvious, non-error-prone way) is the very heart of the issue. REBOL certainly uses non-whitespace delimiters when structure is involved! And (in my experience) the "non-error-prone" issue in the long run is the most important one. After the first time someone struggles to find the extra/missing blank that made his nice long table go all goofy, he/she will usually realize that inserting commas, slashes, or vertical bars, provides a real ROI.
> Non-programmers are easily confused and frustrated by any > kind of "syntax" in my experience. If the goal is to keep > the make-doc format as human-friendly as possible, all > extraneous syntax should be kept out of it. >
In my book things such as \table /table or underlining with hyphens or equal signs are just as much syntax that has to be learned and understood for effective use as is ~|Employee ID|First Name|Last Name |Phone Nr ~|-------- --|----- ----|---- ------|----- -- ~|1234 |Johannes |Doe |555-1212 ~|2345 |Betty Sue|Doaks |555-1213 ~|3456 |Ferdinando|Quattlebaum|555-1214 ~|4567 |Sue Ellen|Van Der Lin|555-1215 Now imagine that the list is not something as obviously interpretable as names and phone numbers, but is an inventory list with product codes, warehouse IDs, rack/shelf locations, and various quantities (on hand, on order, backordered, etc.) some of which may be omitted! What if some of our people have pagers and some do not? Nicknames or not? ~|Emp#|First Name|Last Name |Nickname|Pager Nr|Phone Nr ~|----|----- ----|---- ------|--------|----- --|----- -- ~|1234|Johannes |Doe |Jake |888-1001|555-1212 ~|2345|Betty Sue|Doaks | | |555-1213 ~|3456|Ferdinando|Quattlebaum|Ferdy | |555-1214 ~|4567|Sue Ellen|Van Der Lin| |888-1002|555-1215 That's a perfectly readable chunk of plain ASCII above, and can trivially be parsed into a perfectly legal HTML table. How does the old "whitespace is all we need" strategy deal with: Emp# First Name Last Name Nickname Pager Nr Phone Nr ---- ----- ---- ---- ------ -------- ----- -- ----- -- 1234 Johannes Doe Jake 888-1001 555-1212 2345 Betty Sue Doaks 555-1213 3456 Ferdinando Quattlebaum Ferdy 555-1214 4567 Sue Ellen Van Der Lin 888-1002 555-1215
> Variable syntax is very flexible, but it's even more > confusing than static syntax to regular people. >
Which is why I start off telling them only about a single delimiter (such as vertical bar). I don't make an issue of the option to use other delimiters until someone needs it (at which point he/she is usually delighted to find that their worrisome data can actually be handled easily). IOW, simplicity is achieved by controlling the rate at which features are discussed with the user, not by making a limiting choice that actually causes subtle problems (like remembering to count spaces).
> << Whitespace is also ambiguous (even for more experienced > eyes, IMHO). >>
<<quoted lines omitted: 7>>
> 50% |10% |3% > 500,000 |100,000 |3,000
The examples I provided earlier more fully discuss what I meant by "ambiguous". The "widget" example (as typed) doesn't address those issues. Again, do you have any trouble reading this table? Widget A Widget B Widget C 50% 10% 3% 500,000 100,000 3,000 How many columns are in each row in THIS version? Now answer the same question with the following one. ~| Widget A | Widget B | Widget C ~| 50% | 10% | 3% ~| 500,000 | 100,000 | 3,000 Now, since you want to take up keystroke counting next, answer the same question with this version. ~|Widget A|Widget B|Widget C ~|50%|10%|3% ~|500,000|100,000|3,000 How many keystrokes did we save by not fooling ourselves into believing that we had to make the columns line up? By using an explicit delimiter, the typist gets to choose whether to do so or not, and to choose to save the maximum number of keystrokes if she/he wishes to do so.
> Using the two example tables above, try this little experiment. > Count your keystrokes as you go and time yourself if you feel
<<quoted lines omitted: 3>>
> Ford Prefect > Mary Smith
35, if I'm in keystroke-saving mode. ~|Bob Jones|Ford Prefect|Mary Smith 12345678901234567890123456789012345
> 2. Change Ford Prefect's name to "Ford Prefect III" >
Only 4 more data keystrokes are required (" III") if I choose to optimize in favor of saving keystrokes. (How many keys must be pressed -- or mice must be clicked -- to position the cursor in the right place to perform the insertion is clearly dependent on one's choice of text editor...)
> What do your tables look like now? >
It depends on whether I (as the typist) make the choice to create tidy-looking source text or just get the data in with the fewest keystrokes.
> How many keystrokes did it take you for each one? (if you > post your results, make sure to note whether data > keystrokes were counted (35 data keystrokes are required)) >
See answers above.
> How long did it take you for each? >
I can't type and look at my watch at the same time. Suffice to say that I type somewhere in the 50-60 wpm range.
> Now for some thoughts... > > If you require a delimiter, it has two impacts: > > 1. The user has to mentally switch from "data" mode to > "format" mode, and back to "data" mode again every time > they enter a delimiter. >
I totally disagree. Literate humans (whether "users" or not) are completely familiar with using punctuation as a way of showing the structure of text. Periods at the ends of sentences, commas between elements of a list, horizontal rules between sections of a document, etc. are all well within their comfort zone.
> 2. The delimiter is a small shifted key, usually located > near the larger Enter and Backspace keys, which are both > potentially destructive; Backspace to the data and Enter > to the location. If they Shift key is missed, you'll > get a backslash instead of a pipe, which is easily overlooked. >
Which delimiter? Which brand of keyboard? Which key is the any key? If you can choose for yourself, this is a total red herring! ~;Emp#;First Name;Last Name ;Nickname;Pager Nr;Phone Nr ~;----;----- ----;---- ------;--------;----- --;----- -- ~;1234;Johannes ;Doe ;Jake ;888-1001;555-1212 ~;2345;Betty Sue;Doaks ; ; ;555-1213 ~;3456;Ferdinando;Quattlebaum;Ferdy ; ;555-1214 ~;4567;Sue Ellen;Van Der Lin; ;888-1002;555-1215
> From my perspective, we're dealing with text tables, not > data tables. >
What does that mean? I really have no clue! (Especially since your next sentence talks about reading "the data"!)
> I should be able to read the data clearly whether it's been > formatted in make-doc or whether it's just plain text. >
~| Emp# | First Name | Last Name | Nickname | Pager Nr | Phone Nr ~| ---- | ----- ---- | ---- ------ | -------- | ----- -- | ----- -- ~| 1234 | Johannes | Doe | Jake | 888-1001 | 555-1212 ~| 2345 | Betty Sue | Doaks | | | 555-1213 ~| 3456 | Ferdinando | Quattlebaum | Ferdy | | 555-1214 ~| 4567 | Sue Ellen | Van Der Lin | | 888-1002 | 555-1215 I can read the above quite clearly.
> Using a special delimiter adds an artifical element to the mix. >
No more so that the borders in an HTML table! Most people don't bother to say ... border="0" ..., so their tables have vertical and horizontal rules all over the place. All we're talking about here is letting someone indicate in a simple, obvious, non-error-prone way where he/she wants those boundaries to appear.
> I certainly think we could come up with a cool table formatting > dialect to surpass TBL and rival TeX, but that's not the goal > right now so I think we should strive to remove all extraneous > demands placed on the user. >
I agree. I consider the effort of counting spaces to be a very subtle and error-prone demand, and therefore extraneous. I also disagree, at least with the implication that anything other than plain text is "extraneous". We're in a trade-off zone where we're balancing the added power of structured formatting (such as tables) against the cognitive and typing efforts required to access such power. Having been at this game since the late 60's, I've seen more than my share of line-printer-generated documents that used such devices as +------------+-----------------------+---------------------+ | Style | Pros | Cons | +============+=======================+=====================+ | Whitespace | Easier for hunt-and | Counting whitespace | | (multiple) | -peck typists who | is difficult and | | | don't know the | error-prone for | | | keyboard? | | +------------+-----------------------+---------------------+ | Explicit | Less ambiguous, both | One minute required | | delimiters | to human readers and | to explain the rule | | | text processing | to typist; no time | | | software | required for reader | +------------+-----------------------+---------------------+ | ASCII Art, | About as well as one | Very tedious to | | such as | can do with plain | create and maintain | | this table | (monospaced) text | | +------------+-----------------------+---------------------+ | HTML, Tex, | Tremendous power and | Tremendous learning | | LaTex, or | sophisticated control | curve and effort | | SGML | over resulting docs | to use | +------------+-----------------------+---------------------+ Why did people do such things? Because there was a perceived value in enhancing the appearance of the text. One could certainly argue (and some typographers do) that the borders in such tables are extraneous and bad. However, most people of my acquaintance are accustomed to such extraneous decoration of the content and are willing to invest a small effort to achieve it. OTOH, if you really want to be consistent with the philosophy of letting the human type for human consumption and requiring the formatting program to figure out what was meant, I'd love to see some code that can handle the following (exactly as it appears below, of course). Back in the day, I spent quite a bit of time trying to come up with a bit of AI that could take a flat file or printout image such as the following and infer where the columns were intended, whether each column was to be left-justfied, right-justified, or centered, and what type of data should appear in each. It's non-trivial IMHO, but YMMV. Emp# First Name Last Name Nickname Pager Nr Phone Number ==== ===== ==== ==== ====== ======== ===== == ===== ====== 12 Johannes Doe Jake 888-1001 555-1212 3456 Ferdinando Quattlebaum Ferdy 800-555-1214 234 Betty Sue Doaks 555-1213 4567 Sue Ellen Van Der Lin 888-1002 888-555-1215 Thanks for listening/reading (if you get this far! ;-) -jn- -- You can love your job, but don't expect it to love you back. -- Aaron Watters joel;dot;neely;at;FIX;PUNCTUATION;fedex;d

 [16/28] from: robert:muench:robertmuench at: 23-Sep-2001 16:47


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 5>>
> space, tab etc. >> > And they shouldn't have to.
Hi, well Joel answered the other parts very broad and I agree with him on these. As the above one was my saying I'm going to answer this one: I'm using make-doc-pro within my current project and the project manager uses it too. It's not easy to get people used to the fact that they don't have a WYSIWYG program like Word anymore. It took me some time until he agreed to use make-doc-pro. I agree with you about the needed syntax and that it should be as small and easy as possible. On a daily base I can see how hard it is for those people to even remember the heading syntax, which you can see... using whitspaces might be more dumb-user compatible but as Joel wrote, IMO it's not possible to make it unambigous. So using a logical delimiter character it shouldn't be to hard to remember... Robert

 [17/28] from: greggirwin:starband at: 23-Sep-2001 11:18


Hi Joel, Great response! << You seem to be glossing over to one of the points I raised: When using whitespace one must address the issue of how much whitespace is considered a column break (since it also may appear *within* a column, e.g. between words). When you say "multi-space" you seem to imply more than one, but without actually saying what you mean. How about two? What does that do to the poor user who accidentally bounces the space bar at a point where a single space between words (in one column) was intended?
>>
Yes, I meant more than one. Spacing between columns should appear *visibly* different from spacing within a cell. If I type in a table for other people to read, I would naturally add extra space between columns. If I didn't, that would be a poor design choice on my part and people could very easily be confused by it. << Employee ID First Name Last Name Phone Nr -------- -- ----- ---- ---- ------ ----- -- 1234 John Doe 555-1212 2345 Jane Doaks 555-1213 3456 Ferdinando Quattlebaum 555-1214 4567 Mary Ellen Van Der Lin 555-1215
>>
This is a great example! I would consider this to be a bad table layout because it *is* confusing. Why would you build such a tightly spaced table (outside of being an example here)? If I use tabs, I get a wider spacing than I would like for this table, but it clearly delineates the columns. Employee ID First Name Last Name Phone Nr -------- -- ----- ---- ---- ------ ----- -- 1234 John Doe 555-1212 2345 Jane Doaks 555-1213 3456 Ferdinando Quattlebaum 555-1214 4567 Mary Ellen Van Der Lin 555-1215 << OBTW, tabs are of absolutely no use in solving this problem. If, for example, an item ends on column 14 (1-origin), then keying a tab only takes one to column 16, which is visually indistinguishable from the result of typing a single space in column 15. >> Right! Yes! Absolutely! So, naturally, you would type *another* tab to add space before the start of the next column. Type up a table of text in your favorite word processor. How do you do it? <<
> Whitespace *is* visual feedback. >
Bah! Humbug! Horsefeathers! See the proofreading exercise above. Counting nonprinting characters to figure out *what* *kind* of delimiter (between words *in* a column or between columns) is an awful burden to lay on a poor human (technical or not!).
>>
Right again! We're not counting characters at all, we never do. What we're doing is creating "visual groupings" of data in columns. They must be visually distinguishable for us to make sense of them. If they are laid out so that they might confuse a human reader, then I would expect a parser to get confused as well. Now, a human can take a few extra seconds to try and make sense of the data, as I did with your first example table. Can a program do the same thing? Sure. As you mention, this is no easy task, and beyond what make-doc-pro should be expected to do, but a program should be able to scan the data and take a few extra seconds to try and determine so heuristics that make the most sense of things. Worst case, it could ask. "Hey, are there 4 columns in this table (as in the example I'm displaying to you now in my disruptive dialog box)?" << Bear in mind, as you look at the above examples, that most of us (I assume that you are included in this) read our mail via a user interface that uses a monospaced font. Try changing your default mail client font to Helvetica, Palatino, or Times Roman and see how much fun you have counting spaces! >> Right once more! I think people use tabs to build tables. If you try to build tables using spaces with proportional fonts you're setting yourself up for an ulcer. :) <<
> Do we need delimiters, beyond whitespace, in our REBOL code? >
We certainly do. Including [ ] ( ) { } and " .
>>
Sorry, my meaning wasn't clear. Here's an example of what I meant. Using only whitespace, we can type this: emit: func [data] [append out reduce data] Using another delimiter (|), we get this: emit:|func|[data]|[append|out|reduce|data] That's the simple case I wanted to make. << We're talking about tables here, where structure (and how to represent it in a simple, obvious, non-error-prone way) is the very heart of the issue. REBOL certainly uses non-whitespace delimiters when structure is involved! And (in my experience) the "non-error-prone" issue in the long run is the most important one.
>>
Agreed. However, as you point out, we're talking about tables here. If REBOL only dealt with tables, how much of its already minimal syntax would go away? It's much more complex, which is why it has more delimiters and operators. I think Carl eliminated everything he possibly could while still achieving his goals. << In my book things such as \table /table or underlining with hyphens or equal signs are just as much syntax that has to be learned and understood for effective use as is ~|Employee ID|First Name|Last Name |Phone Nr ~|-------- --|----- ----|---- ------|----- -- ~|1234 |Johannes |Doe |555-1212 ~|2345 |Betty Sue|Doaks |555-1213 ~|3456 |Ferdinando|Quattlebaum|555-1214 ~|4567 |Sue Ellen|Van Der Lin|555-1215
>>
I disagree...somewhat. Some of this has to be couched in the context of the make-doc discussion. If I were just typing a document, I would probably do something like this: Table 1. --------------------------------------- NAME PHONE E-MAIL --------------------------------------- Bob Jones 000.0000 [Bob--Jones--com] Mary Smith 111.1111 [Mary--Smith--com] Can make-doc make sense of this? Let's see...blank line, then a line is indented and starts with the word "table", then a line of dashes, words in all caps (make note of what character column they fall on), another line of dashes (if last line wasn't all caps then we'll pretend it was), more lines of stuff, and finally another blank line. That's the syntax (well, roughly anyway <g>) I want because I can send this table to *anyone*, make-doc'd or not, and they can understand it. Even if I have an extra space or two somewhere. :) << Now imagine that the list is not something as obviously interpretable as names and phone numbers, but is an inventory list with product codes, warehouse IDs, rack/shelf locations, and various quantities (on hand, on order, backordered, etc.) some of which may be omitted! What if some of our people have pagers and some do not? Nicknames or not? >> Good points all. I contend that whitespace is easily the best delimiter in this case as you may have other, non-standard, characters contained in product codes and such. Regarding omitted items, the whitespace defense team calls to the stand; The Chicago Manual of Style (well, not really <g>). I believe the standard is just to leave the cell empty or to put an em dash in the cell. In our case, the latter seems the obvious choice for ease of implementation. << ~|Emp#|First Name|Last Name |Nickname|Pager Nr|Phone Nr ~|----|----- ----|---- ------|--------|----- --|----- -- ~|1234|Johannes |Doe |Jake |888-1001|555-1212 ~|2345|Betty Sue|Doaks | | |555-1213 ~|3456|Ferdinando|Quattlebaum|Ferdy | |555-1214 ~|4567|Sue Ellen|Van Der Lin| |888-1002|555-1215 That's a perfectly readable chunk of plain ASCII above, and can trivially be parsed into a perfectly legal HTML table. How does the old "whitespace is all we need" strategy deal with: Emp# First Name Last Name Nickname Pager Nr Phone Nr ---- ----- ---- ---- ------ -------- ----- -- ----- -- 1234 Johannes Doe Jake 888-1001 555-1212 2345 Betty Sue Doaks 555-1213 3456 Ferdinando Quattlebaum Ferdy 555-1214 4567 Sue Ellen Van Der Lin 888-1002 555-1215
>>
It deals with it the same way a human would, though it's obviously not as smart. It says "That's a really bad table layout. What were you thinking? I can't make sense of that, and neither will anyone else." :) You don't have to agree with my stance on this, to be sure it's not conventional. While I agree that the first one is trivially parsed by a machine, and also "parseable" by a human, it is not easily readable. I can't take it in at a glance, which is what tables are supposed to help us do, right? << IOW, simplicity is achieved by controlling the rate at which features are discussed with the user, not by making a limiting choice that actually causes subtle problems (like remembering to count spaces). >> This logic is somewhat counterfeit. A particular user may not know anything about advanced features, but that doesn't prevent them from getting a document containing them, which means they then have to understand them to understand that document. It could be argued that people should only care about distributing what make-doc spits out, but I like the idea of plain text distribution. << The examples I provided earlier more fully discuss what I meant by "ambiguous". The "widget" example (as typed) doesn't address those issues. Again, do you have any trouble reading this table? Widget A Widget B Widget C 50% 10% 3% 500,000 100,000 3,000
>>
None what-so-ever. 3 columns. Perfectly clear. Now, you're going to tell me that there are actually 4 columns because of the extra space in "Widget B". And you'd be right. No problem says I, it's easily fixed for make-doc generation and, for human consumption, it doesn't need to be fixed. That's my preference, though it may not be yours. It's going to be tough as long as each of us can come up with artificial examples that support our respective cases. Could some othe people send in some sample tables? Let's get as many as we can and see if that leads in a particular direction. << Now, since you want to take up keystroke counting next, answer the same question with this version. ~|Widget A|Widget B|Widget C ~|50%|10%|3% ~|500,000|100,000|3,000 How many keystrokes did we save by not fooling ourselves into believing that we had to make the columns line up? By using an explicit delimiter, the typist gets to choose whether to do so or not, and to choose to save the maximum number of keystrokes if she/he wishes to do so.
>>
Another valid case. Now, my *goal* is not to save keystrokes, that just comes along as a happy side-effect. I originally did some delimited layouts to post, showing the very issue you mention: a|b|c|d|e|f|g 12|23|34|45|56|67|78 acb|def|ghi|jkl|mno|pqr|stu $12.00|$24.50|$37.75|$1.00|$0.50|$0.25|$0.01 I didn't include them in my original post because this is so horrific, from a layout perspective, that I can't imagine anyone even considering it as an option and I didn't think it was fair to hit you with it. :) We can say that people should be free to format their data however they want, freedom of expression and all that, but I also think it's important to encourage good data hygiene. RE: Keystrokes and table formatting << It depends on whether I (as the typist) make the choice to create tidy-looking source text or just get the data in with the fewest keystrokes. >> I notice that none of the example tables you've posted to support the case for delimiters used the keystroke saving mode. For me, and I could be alone in this, creating delimited tables using ASCII chars as we are discussing, always has me playing the back and forth game to get my delimiters to line up, then that moves my data, so I have to readjust that, etc. Could just be that I haven't been forced to come up with a clever solution to my problem since I can avoid it. << Literate humans (whether "users" or not) are completely familiar with using punctuation as a way of showing the structure of text. Periods at the ends of sentences, commas between elements of a list, horizontal rules between sections of a document, etc. are all well within their comfort zone.
>>
Agreed. Those are conventions we are taught. Using a pipe symbol as a delimiter between pieces of text is not. This is where we diverge in our view as I consider this to be a computer/programmer's convention and not a normal language/grammar convention. << Which delimiter? >> Sorry for the confusion, I have been using the pipe symbol(|) as the basis for this discussion. << If you can choose for yourself, this is a total red herring! >> But that brings us back to the complexification of variable syntax! << ~;Emp#;First Name;Last Name ;Nickname;Pager Nr;Phone Nr ~;----;----- ----;---- ------;--------;----- --;----- -- ~;1234;Johannes ;Doe ;Jake ;888-1001;555-1212 ~;2345;Betty Sue;Doaks ; ; ;555-1213 ~;3456;Ferdinando;Quattlebaum;Ferdy ; ;555-1214 ~;4567;Sue Ellen;Van Der Lin; ;888-1002;555-1215
>>
Now don't tell me *that's* easily parsed by humans. <thrust parry thrust jab> :) <<
> From my perspective, we're dealing with text tables, not > data tables. >
What does that mean? I really have no clue! (Especially since your next sentence talks about reading "the data"!)
>>
Sorry, again, for the confusion. I meant to draw the distinction between the tabular presentation of data for human consumption versus the tabular presentation of data for computer processing (i.e. delimited data). << ~| Emp# | First Name | Last Name | Nickname | Pager Nr | Phone Nr ~| ---- | ----- ---- | ---- ------ | -------- | ----- -- | ----- -- ~| 1234 | Johannes | Doe | Jake | 888-1001 | 555-1212 ~| 2345 | Betty Sue | Doaks | | | 555-1213 ~| 3456 | Ferdinando | Quattlebaum | Ferdy | | 555-1214 ~| 4567 | Sue Ellen | Van Der Lin | | 888-1002 | 555-1215 I can read the above quite clearly.
>>
And so can I. Now, if you remove the delimiters... Emp# First Name Last Name Nickname Pager Nr Phone Nr ---- ----- ---- ---- ------ -------- ----- -- ----- -- 1234 Johannes Doe Jake 888-1001 555-1212 2345 Betty Sue Doaks 555-1213 3456 Ferdinando Quattlebaum Ferdy 555-1214 4567 Sue Ellen Van Der Lin 888-1002 555-1215 I can still read it just as clearly, if not more-so. The catch here is that make-doc may not be able to read it as clearly. Hmmm, force a fixed-pitch font and treat it as preformatted text in cases of confusion? << No more so that the borders in an HTML table! Most people don't bother to say ... border="0" ..., so their tables have vertical and horizontal rules all over the place. You make a great point by saying "Most people don't bother..." You're right. People will often do things in the most economical way possible and live with the results if they aren't oppressive. Press abandoned vertical rules as a standard feature of tables in the books and journals it published. More than two decades of this austerity have demonstrated that banishing vertical rules has not decreased the clarity of well-organized tables and that it has, on the other hand, increased their attractiveness. (Chicago Manual of Style, 14th edition, pg 410) << All we're talking about here is letting someone indicate in a simple, obvious, non-error-prone way where he/she wants those boundaries to appear. >> I'll nit-pick here. We're not "letting" them, we're "forcing" them. << I consider the effort of counting spaces to be a very subtle and error-prone demand, and therefore extraneous. >> So don't count spaces, just make things look right. :) << I also disagree, at least with the implication that anything other than plain text is "extraneous". We're in a trade-off zone where we're balancing the added power of structured formatting (such as tables) against the cognitive and typing efforts required to access such power.
>>
I couldn't agree more. In the context of a TeX/TBL dialect, the whitespace approach is probably not the right one. My opinion in this matter is based on my view that simpler is better and less is more. I'm willing to give up 99% of the power in return for a 50% effort reduction. << OTOH, if you really want

 [18/28] from: joel:neely:fedex at: 23-Sep-2001 22:53


Hi, Gregg, Gregg Irwin wrote:
> << > Employee ID First Name Last Name Phone Nr
<<quoted lines omitted: 6>>
> This is a great example! I would consider this to be a bad > table layout because it *is* confusing.
But it isn't confusing, is it? Since you're an intelligent human being, you understand enough about the *meaning* of the data in the columns (and about interpreting the rows of the table in the context of the entire table) that you could probably see four columns instantly.
> Why would you build such a tightly spaced table (outside of > being an example here)? >
This was only an illustration. I might need to use tight spacing because there's lots of data to get on each line and I'm trying to stay within narrow text margins. The rest of my answer would be very similar to your next comment.
> If I use tabs, I get a wider spacing than I would like for > this table, but it clearly delineates the columns. >
The more spaces I have to type, the more typing effort is involved. In addition, whether I use spaces or tabs, if I have lots of data to present, I want to waste as little space as possible. So, I agree with your comment that the example below is "a wider spacing than I would like", or than will fit on the page.
> Employee ID First Name Last Name Phone Nr > -------- -- ----- ---- ---- ------ ----- --
<<quoted lines omitted: 7>>
> a table of text in your favorite word processor. How do you do > it?
If I were using a word processor (or a desktop publishing program), I would type exactly one tab between successive columns. I would then adjust the positions of the tab stops to provide adequate horizontal separation between the columns. Unfortunately, simple text processors (and most utilities that just dump plain text files to screen or printer) have fixed tab stops (e.g., every 8 characters) which usually means that some tab positions are too wide and others are too narrow (when we're dealing with typical text/data).
> << > > Whitespace *is* visual feedback.
<<quoted lines omitted: 6>>
> >> > Right again! We're not counting characters at all, we never do.
Distinguishing one space from multiple spaces requires counting, even if it's only counting from 1 to 2. But this begs the question of what "multiple" means!
> What we're doing is creating "visual groupings" of data in > columns. They must be visually distinguishable for us to make
<<quoted lines omitted: 9>>
> there 4 columns in this table (as in the example I'm displaying > to you now in my disruptive dialog box)?"
What we *intend* to do is create visual groupings. What we actually do is type characters. What we must do if we want a program to read our minds and discover our intentions is to make precise statements about the rules of inference for deciding where the "visual groupings" are to be delimited. We certainly agree that writing such telepathic code in the absence of clear specifications "is no easy task, and beyond what make-doc-pro should be expected to do". However, this thread began with the question of how to incorporate tables into make-doc-pro or similar tools. So we seem to be agreeing that writing heuristic code that can make sense of our use of whitespace is beyond the scope of a make-doc-style program.
> << > > Do we need delimiters, beyond whitespace, in our REBOL code?
<<quoted lines omitted: 7>>
> emit:|func|[data]|[append|out|reduce|data] > That's the simple case I wanted to make.
But it illustrates the fallacy I was emphasizing. In the above example, the whitespace is ONLY used for a single "level" of logical grouping. All other structure is shown by means of the other delimiters. Using your example, we can agree that emit: func [data] [append out reduce data] and emit: func [ data ][ append out reduce data ] mean exactly the same thing, variations in whitespace being of no significance. As far as I can tell, a table has four levels (not counting the level of individual characters!): 1) individual tokens/words/symbols within a cell 2) a single cell, made up of such tokens/words/symbols 3) a single row, made up of cells 4) the entire table, made up of rows Using varying amounts of whitespace (horizontal or vertical) to distinguish among these levels seems to risk the same possible errors (of typing or reading) as if we used varying whitespace in the code example emit func data append out reduce data where appearing at the left margin makes a word a set-word, a gap of multiple spaces begins or ends a block, and single spaces separate words within a block. I hope none of us would argue in favor of such a "natural, punctuation-free" version of REBOL!
> << > In my book things such as
<<quoted lines omitted: 23>>
> line of dashes, words in all caps (make note of what character > column they fall on), ...
Now you're just making up another set of rules on the fly, with yet more opportunities for a poor human to make an error (typo, failing to remember a rule, etc.) What happens if the typist doesn't remember to put NAME, PHONE, and E-MAIL in all caps? Rules are still rules, regardless of which keys on the keyboard they require!
> I believe the standard is just to leave the cell empty or to > put an em dash in the cell. In our case, the latter seems the > obvious choice for ease of implementation. >
Leaving it empty creates ambiguous runs of whitespace unless there is a column delimiter. As for the alternative, my ASCII keyboard doesn't have an "em-dash" key. Requiring something (doubled hyphens, for example) to represent an empty cell is certainly plausable, but again constitutes yet another rule whose violation might have consequences. More rules again.
> << IOW, simplicity is achieved by controlling the rate at > which features are discussed with the user, not by making > a limiting choice that actually causes subtle problems > (like remembering to count spaces). >> > > This logic is somewhat counterfeit... >
You're entitled to your opinion, but I've actually deployed a system using this kind of approach and have had no problems with it (nor its users) to date.
> << > Now, since you want to take up keystroke counting next, answer
<<quoted lines omitted: 20>>
> anyone even considering it as an option and I didn't think it > was fair to hit you with it. :)
Since we're confessing... ;-) I had originally planned on including the following related issue (but had writtent too much already). Those who have data in spreadsheet or database format can easily export it to delimited text, then cut and paste the data into their document. Why should they have to do all of the manual effort to replace the explicit delimiters with varying amounts of whitespace just to make the columns line up? That's what we employ computers for! They can count columns and spit out "tidy text", HTML, RTF, PDF, TeX, or whatever, and save us the tedium.
> For me, and I could be alone in this, creating delimited tables > using ASCII chars as we are discussing, always has me playing > the back and forth game to get my delimiters to line up, then > that moves my data, so I have to readjust that, etc. Could just > be that I haven't been forced to come up with a clever solution > to my problem since I can avoid it. >
The solution is to have the program include a "tidy text" option to deal with all of that time-wasting character shuffling. Then you can 1) Type (or cut-and-past) minimal with minimal effort. 2) Convert to tidy-text for those (few?) cases where text is really the right medium. 3) Convert to HTML (etc.) for the other cases. ... and in all cases, let the computer do the tedious work of shuffling characters and counting columns.
> << > Literate humans (whether "users" or not)
<<quoted lines omitted: 8>>
> diverge in our view as I consider this to be a computer/programmer's > convention and not a normal language/grammar convention.
I think anyone who understands that commas separate words or phrases in a list can learn to use a column separator in a few seconds. They already understand the concept of delimiter; I'm just reusing it. That seems to be where we differ.
> Thanks for a fabulous discussion! Whatever the result, I'm always > energized by this kind of constructive discourse (I love that word). :) >
Thank you! I appreciate the exchange of ideas! -jn- -- ; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677 REBOL [] foreach [order string] sort/skip reduce [ true "!" false head reverse "rekcah" none "REBOL " prin "Just " "another " ] 2 [prin string] print ""

 [19/28] from: greggirwin:starband at: 24-Sep-2001 0:39


Hi Joel, I've been long winded enough so I'll just clear up one thing from our last exchange. I said:
> ...If I were just typing a document, I would probably do something >like this:
<<quoted lines omitted: 4>>
> Bob Jones 000.0000 [Bob--Jones--com] > Mary Smith 111.1111 [Mary--Smith--com]
You said:
>Now you're just making up another set of rules on the fly,...
Confusion again. I hadn't intended for that example to be taken as a synactical model for the make-doc table discussion. It was just an example of how I would format a plain text table manually. If I could teach make-doc to parse what I would just naturally enter, then so much the better. Thanks again. I think this kind of discussion is really valuable considering the importance of dialecting in REBOL. I think well designed dialects may very well transform the way we work. --Gregg

 [20/28] from: robert:muench:robertmuench at: 24-Sep-2001 14:13


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 5>>
> considering the importance of dialecting in REBOL. I think well > designed dialects may very well transform the way we work.
Hi, I agree the discussion is very valuable. I have learned a lot. For make-doc-pro I will use the following conclusion: 1. Using \table and /table as begin/end delimiters. 2. Using | as column delimiter to make columns unambigous. Thing I might consider are: 1. Let the user specify the column delimiter 2. Use horizontal bars for seperation between header and table body Robert

 [21/28] from: lmecir:mbox:vol:cz at: 24-Sep-2001 20:36


Hi Irwin, I would like to write my reaction to: ----- Original Message ----- From: Gregg Irwin <[greggirwin--starband--net]> To: <[rebol-list--rebol--com]> Sent: Monday, September 24, 2001 8:39 AM Subject: [REBOL] Re: make-doc-pro: how to handle tables? ...snip...
> Thanks again. I think this kind of discussion is really valuable > considering the importance of dialecting in REBOL. I think well > designed dialects may very well transform the way we work. > > --Gregg
I may be too strict on this, but (IMHO) this is not a Rebol dialect discussion. I would say, that the the Make-doc language is a "Yet another document description language". The fact, that its only existing interpreter is written in Rebol looks purely accidental to me. I would say that the properties of the Make-doc language have little in common with Rebol. Regards Ladislav

 [22/28] from: greggirwin:starband at: 24-Sep-2001 13:31


Hi Ladislav, << I may be too strict on this, but (IMHO) this is not a Rebol dialect discussion. I would say, that the the Make-doc language is a "Yet another document description language". The fact, that its only existing interpreter is written in Rebol looks purely accidental to me. I would say that the properties of the Make-doc language have little in common with Rebol. >> I'm posting lots of confusing messages lately.<g> I didn't mean that the make-doc discussion was dialect oriented, as it obviously was not. What I meant was that the discussion about the pros and cons of various syntactical design choices, what's good for humans versus what's easy for us to parse, etc. are applicable when designing dialects as well. Does that make more sense? --Gregg

 [23/28] from: lmecir:mbox:vol:cz at: 24-Sep-2001 22:27


Hi Gregg, have my apologies for incorrectly picking your name from the 2 (two) possibilities below. ----- Original Message ----- From: Gregg Irwin <[greggirwin--starband--net]> To: <[rebol-list--rebol--com]> Sent: Monday, September 24, 2001 9:31 PM Subject: [REBOL] Re: make-doc-pro: how to handle tables?
> I'm posting lots of confusing messages lately.<g> I didn't mean that the > make-doc discussion was dialect oriented, as it obviously was not. What I > meant was that the discussion about the pros and cons of various
syntactical
> design choices, what's good for humans versus what's easy for us to parse, > etc. are applicable when designing dialects as well. Does that make more > sense? > > --Gregg
I must confess, that I succeeded to convince a few people that i "designed" a "data description language for ... (a specific problem)", while in fact I used (a subset of) Rebol. It wasn't even a dialect of Rebol, but Rebol itself! It didn't need to use all dictionary words while using my "library" which was specified "inconspicuously" in "the header" of the description. When I told them the truth, they didn't want to believe, because I used czech words!

 [24/28] from: lmecir:mbox:vol:cz at: 24-Sep-2001 22:33


I was too quick at hitting the "send" button. What I want to add to my last post is, that the "data description language" I "designed" had a lot to do with tables, even the result had to be a table. Cheers Ladislav

 [25/28] from: greggirwin:starband at: 24-Sep-2001 15:32


Hi Ladislav, I was too quick in replying. :) Is what you did proprietary, or is it something you could share with us? --Gregg

 [26/28] from: greggirwin:starband at: 24-Sep-2001 15:30


Hi Ladislav, No problem on the name, Irwin is a valid first name so it can be easily confused. << I must confess, that I succeeded to convince a few people that i designed a "data description language for ... (a specific problem)", while in fact I used (a subset of) Rebol. It wasn't even a dialect of Rebol, but Rebol itself! It didn't need to use all dictionary words while using my "library" which was specified "inconspicuously" in "the header" of the description. >> Yes! Picking the right words, even if you just reference built-in words with them is a terrific, and simple, solution. --Gregg

 [27/28] from: lmecir:mbox:vol:cz at: 25-Sep-2001 0:09


Hi,
> Hi Ladislav, > > I was too quick in replying. :) > > Is what you did proprietary, or is it something you could share with us? > > --Gregg
unfortunately, I am not able to disclose the details of the problem. But, I can tell you some general info: it was a problem that has been solved using Excel before (about one day of table manipulation for pretty simple cases), because the job consisted from doing a huge amount of data comparisons and some statistic routines. I simplified the algorithm (used more efficient formula to compute the result, while getting more accurate result at the same time) and Rebol made the task trivial ("press a button and you get the result instantly"). The tables were "represented" as follows: uzly_a: -1,00E+00 -5,00E-01 0,00E+00 1,00E+00 -5,00E-01 0,00E+00 1,00E+00 5,00E-01 0,00E+00 -1,00E+00 5,00E-01 0,00E+00 -1,00E+00 -5,00E-01 5,00E+00 -1,00E+00 5,00E-01 5,00E+00 1,00E+00 -5,00E-01 5,00E+00 1,00E+00 5,00E-01 5,00E+00 ] where the set-word represented an appropriate name for the respective table, which could be then referred to in the next part of the data description and the space was used as a delimiter (tables contained only numbers in this case). Cheers Ladislav

 [28/28] from: lmecir:mbox:vol:cz at: 25-Sep-2001 0:45


Hi, sorry for any inconvenience, but my outlook express stripped off the opening square bracket of the block, as you might have guessed already...

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted