On Mon, 20 Feb 2017 11:47:35 -0600, luke wallace <lukewallace1...@gmail.com>
wrote:
> 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.
Very interesting. Even if it's not used for editing, I can imagine something
like this as the output of a pretty-printing process.
I wonder about *editing* while doing this, though.
Perhaps entering "(" would automatically add a closing ")",
show the box (if not preceded by whitespace), and move the user inside.
> 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...
Newbies don't stay newbies. I'd like to think that any "readable Lisp"
would be just as useful to experts as to newbies. Experts have to read
a lot of code... making their lives easier is a good idea too :-).
> 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.
One challenge is that "<=" doesn't have a fixed meaning; it might mean the
underlying Lisp implementation, or the meaning of "<=" as redefined in
some other language you're defining there.
> 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.
Sure. You need to be cafeful, though; bugs are easy to hide if the developer
can't easily "see" what the code actually *is*. I think experimentation would
be necessary.
This probably wouldn't be too hard to prototype in an editor - I'd love to hear
if you give it a try.
--- David A. Wheeler
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
