Re: [Readable-discuss] Readable Lisp 2.0, brainstorming

On Mon, 20 Feb 2017 15:36:22 -0600, luke wallace <luk...@gm...> wrote:
> Here's a similar but slightly different prototype
> 
> https://i.imgur.com/vApN1Yt.png

Quick nitpick  - please use these terms:
() - parentheses
[] - (square) brackets
{} - (curly) braces

I realize that some people call *all* of the paired characters "brackets",
but since we have to talk about paired characters often around here, it's
helpful to be very precise about these terms :-).

> 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'.

There are bit minuses to this.  This assumes that the editor
"knows" what terms like 'define' and '<=' and 'if' mean.
I imagine there are some uses for it, primarily if you use Lisp
exactly the same way as you'd use a fixed-syntax language like Java.

But fixed-syntax languages are going to be much better at being themselves
than a Lisp ever could.  If you need a fixed-syntax language, there are
over a hundred of them.  A key advantage to Lisp is that you can
embed many different languages & can trivially create your own.
Mini-languages abound! There's no particular reason that "<=" or "define"
would have the same meaning each time even within one line,
and there's no way an editor could determine the meaning in general
(it would have to recursively expand macros across all files,
and even then, there's no mechanism for capturing this information in general).

That said, *displaying* boxes is a good idea.  I think it's been done before,
but it's fair to point out that modern systems make this *much* easier and
more practical.  And you don't need *any* magic to display the boxes.

So, when will you be implementing a prototype :-) ?

--- David A. Wheeler