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