I've been thinking about the separation of logic, language and layout [1] and decided to mock up a demonstration [2] of what I want. And because it's just a quick mock-up, and one written primarily for me, I'm not guaranteeing it'll even work in your browser—it does in mine (Firefox [3]) and that's all I've tested it under.
Now, assuming the mock-up even works for you, what you'll see is a sample PHP page to process a rather complicated form (taken from another project I'm slowing working on, and I skimped out on fully processing the form, as I didn't want to get sidetracked—as it was, I had to write quite a bit of code just to process the page into the form you see). Along the right side you'll see a small box where you can turn various parts of the code on and off.
The “logic” is PHP code that does the processing. The “layout” is the HTML (HyperText Markup Language) that actually forms the display and the “language” is that part of the HTML that is actually presented to the user on their browser. The final part is a bit of JavaScript embedded in the HTML—it's kind of a “miscellaneous section” that doesn't quite fit into any of the other parts (although given a significant amount of JavaScript, it too could probably be broken up into a logic, layout and language portion, thus falling further into self-referential madness (Gödel, Escher, Bach: An Eternal Golden Braid) [4]). Each section retains its own line numbering as an attempt to show how each section might maintain its own revision control within the page.
I'm using color to show the different sections, but this is more than just syntax highlighting (which I don't do as you can see), it's using color to add more to the program structure than just individual elements like comments and variable declarations. It's more like colorForth [5] where color plays a syntactical role in the language.
Hey, if Python can use significant whitespace, then why not a language (or language tool) with significant color? True, those who are colorblind (or just blind) might complain about the significant use of color, but all it's doing is hiding some syntax. For instance, this bit of colorForth:
>
```
IDE hard disk driver
bsy 1f7 p@ 80 and if bsy ; then ;
rdy 1f7 p@ 8 and if 1f0 a! 256 ; then rdy ;
sector 1f3 a! swap p!+ /8 p!+ /8 p!+ /8 e0 or p!+ drop p!+ drop 4 * ;
read 20 sector 256 for rdy insw next drop ;
write bsy 30 sector 256 for rdy outsw next drop ;
```
Is equivelent to the following Forth code:
>
```
( IDE hard disk driver )
: bsy 1f7 p@ 80 and if bsy exit then ;
: rdy 1f7 p@ 8 and if 1f0 a! 256 exit then rdy ;
: sector 1f3 a! swap p!+ /8 p!+ /8 p!+ /8 e0 or p!+ drop p!+ drop 4 * ;
: read 20 sector 256 for rdy insw next drop ;
: write bsy 30 sector 256 for rdy outsw next drop ;
```
All the color does is remove the need for certain Forth words (in colorForth, the green words are compiled into a new word whose name is in red, while black text is treated as a comment; in Forth, “( )” defines a comment, and “:” define a new word to be compiled). Now, from what I understand of Chuck Moore [6], the creator of both Forth and colorForth, the colors defined are cast in stone—that is, the color “red” will always mean “define this word” whereas the color “black” will always mean “this is a comment.”
But that's Chuck Moore. Were I to design a language with color significant syntax, I would definitely make it configurable as to which color means what, with the fallback of additional syntax when color can't be used for whatever reason.
Now, getting back to the mock-up.
Each time there was a transition, say, from “layout” to “language,” I started the next section on its own line. Doing the mock-up I realized that this won't necessarily work all that well. Something simple like:
>
```
<input name="name" value="<?php echo $name;?>" type="text">
```
would get split into multiple lines:
>
```
15 | <input name="name" value="
27 | echo $name;
16 | " type="text">
```
But then keeping track of revisions per section becomes a lot harder. Heck, keeping track of what goes where becomes non-trivial I would think, even in a line-by-line basis per the mock-up. Although as a visualization technique of PHP code, this might have some promise …
And if I can inspire someone else to make the tool I'm envisioning, then all the better.
[2] /boston/2008/02/10/sample.html
[3] http://www.mozilla.com/firefox/
[4] http://www.amazon.com/exec/obidos/ASIN/0465026567/conmanlaborat-20
[5] http://www.colorforth.com/cf.html