Here is my new idea for an ideal lisp authoring format, which relies on an
html/css/js editor using pretty components around source lisp code. Source
lisp code is still saved as a text file, but is, upon loading into this
theoretical editor, "pretty formatted" as shown in the image below.

Inside this editor, creating parentheses in the right context would instead
create nested table cells as shown in the image. Instead of working with
parentheses, newbies might find it easier to look at tables like this,
which show the nested structure more visually. The example image uses the
factorial function from the readable website homepage. There is an extra
column with text in bold which are comments. Comments in this manner can be
put anywhere, and will always be bold so they are easily distinguished.
This allows newbies to document their code, or an editor to document their
code for them, for functions like "if" that the theoretical editor knows

Also, the "define" function is the parent function for this block, so it
has its text centered - an easy visual way to distinguish the parent
besides just the outer border.

Comments could be disabled by a menu option in the editor.
Specifically, these special comments which are generated by the editor
could be hidden at the users request, while keeping different types of
comments from the source file visible in some way.

So far, this just shows infix notation (taken from readable lisp) and a new
way to represent parentheses and comments/dynamic comments.

Using more html/css/js magic, it would be possible in such an editor to do
things like display a tooltip when a user hovered over recognized symbols
such as <= in the image. The tooltip could display an explanatory message
like "less than or equal to". While experienced programmers may not need
the <= symbol explained to them, by explaining every symbol, it should
become even more readable in the editor.

In this prototype image, the parentheses are shown as square table cells,
but they could be rounded, given line width, background colors, or change
colors on mouse-hover, keyboard focus, or when using a debugger to step
through code line by line (indicating what portion of the table is being
evaluated) etc. The possibilities are endless if we step out of the
shackles of needing to see source code as the language dictates it.
Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Readable-discuss mailing list

Reply via email to