Here's a similar but slightly different prototype
https://i.imgur.com/vApN1Yt.png
This prototype uses a flatter version of tables, and much more 'magic'
would have to be programmed into the editor
cells shaded grey are prefix-comments, in this case, for the function
'define'.
prefix-comments would have to be set up for each function for a given
language/variant, but would enable a form-filling experience resulting in
lisp code - and most near computer illiterates wouldn't mind coding if it
was mostly filling in forms.
cells with bold text are contextual-comments - the usage comment is
contextual to the 'factorial' function, and the 'then' and 'else' comments
are contextual to the 'if' function. these are set up for each function for
a given language/variant, just like prefix-comments.
The 'define' cell spans the whole table - therefore everything under it is
wrapped in its parens
The next part relies on a bit of magic, 'factorial' starts an open paren,
but does not close unless the 'Parameter(s)' box is left empty. If the
parameter(s) block is left empty, factorial will be a function without
arguments and close paren. The editor would have to handle these conditions
for the 'define' symbol (or any symbol used to create functions).
The 'usage' prefix-comment and its corresponding contextual-comment are
used for the tooltip in the editor wherever the function is used (including
in the definition code of this recursive function), and also as a readable
snippet when someone looks at the function definition, to understand what
it does. This might help libraries of functions be more understandable in
the long run, as they would be self documenting not just in how to use
them, but where and why to use them.
The 'code' prefix-comment uses special logic to open/close parens. The
first piece of actual code, the 'if' opens a parens and does not close
until a new symbol in the same column exists. Since 'then' and 'else' are
not symbols, but are comments, it doesn't close until the end of the table
(before the 'define' ends though).
'n <= 1' opens, then closes because '1' is on the same column, and is
actual code
'1' opens, then closes because 'n*' is on the same column, and is actual
code
'n* opens, then 'factorial' opens, then 'n-1' opens, from left to right,
and they all close at the end of the table, but before the 'if'.
The goal of doing it this way is to prevent excessive nesting of cells -
and use implied nesting through the logic of columns.
On Mon, Feb 20, 2017 at 1:03 PM, David A. Wheeler <dwhee...@dwheeler.com>
wrote:
> 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
