On Tables and Relations

The best tool we have in computing is the relation. We have exactly two ways of representing a relation. One is a function. The other is a table. What could be more clear than this:

Table 1: Cats
NameMarkingsDisposition
Abbyblack and whiteskittish
Happyblack and whitetalkative
Cookiecalicowarm
Benblackpaternal

The programming language Prolog is explicitly relational. We would represent the preceeding table in Prolog explicitly with the following code:

% cats(Name, Markings, Disposition)
cats(abby, black_and_white, skittish).
cats(happy, black_and_white, talkative).
cats(cookie, calico, warm).
cats(ben, black, paternal).

This is pretty close to the table, but with a little alignment we can get closer:

% Name         Markings         Disposition)
  cats(abby,   black_and_white, skittish).
  cats(happy,  black_and_white, talkative).
  cats(cookie, calico,          warm).
  cats(ben,    black,           paternal).

Or using commas to demarcate columns:

% Name         Markings         Disposition)
  cats(abby  , black_and_white, skittish).
  cats(happy , black_and_white, talkative).
  cats(cookie, calico         , warm).
  cats(ben   , black          , paternal).

A better approach would be to adopt elastic tabs, permitting a much more natural visual representation.

% NameMarkingsDisposition
cats(abby,blackandwhite,skittish).
cats(happy,blackandwhite,talkative).
cats(cookie,calico,warm).
cats(ben,black,paternal).

Another way of representing it:

%NameMarkingsDisposition
cats(abby,blackandwhite,skittish).
cats(happy,blackandwhite,talkative).
cats(cookie,calico,warm).
cats(ben,black,paternal).

I leave it to other developers to decide which of these is nicer to look at.

A clear side-benefit to using elastic tabs is that the alignment is not based on a stable uniform character width. This means you can use fonts intended for reading, rather than fonts made to waste space.

What's the downside? Apart from gedit, no editor implements elastic tabstops. The technology remains a good idea without meaningful implementations in common editors.

Why is this unused? I'm not sure. Reading about Emacs's “smart tabs” it sounds like Emacs itself doesn't have a good way to do an absolute positioning. Calculating the distance in spaces from one tab to one absolute position is arithmetic, but laying out the page according to regions is not easy. Moreover, the code won't render correctly in uninformed editors.

How important is correct rendering in other editors? Word documents don't render correctly in Pages and vice-versa. The more complex the editor, the more likely it is that similar software won't work identically. Yet programmers seem to hold beliefs that prevent the situation from getting better: we should be able to use any editor to edit the code, and the code should look the same in every editor.

Another thing that would greatly help: literate programming. Unfortunately, in this case, the elastic tabs have been simulated by an unbordered table. In order to export this properly to source code, the table would have to be eliminated in a syntactically acceptable fashion. Better would be writing literate tools that understand elastic tabs. Either way it's more stuff to code, and for a tiny audience.