On Thu, 1 Sep 2016 19:37:43 -0400, luke wallace <lukewallace1...@gmail.com> 
> My idea is that by converting lisp into a simplified abstract syntax tree
> form, and then performing formatting options on that abstract syntax tree
> (such as prefixing parts of it with syntactic sugar, or compacting some
> levels of the tree, or reformatting the order of operators and operands, we
> are able to create human-readable formatting for conventional lisp code
> Below are two theoretical examples:
> http://i.imgur.com/JNOXQ4M.png

The pictures are fine representations of abstract syntax trees (ASTs).
You need to handle "lists of lists" (like let's first argument);
that can be tricky but is doable.
If you mean for people to view them directly (say auto-generated as you edit),
I'd be a little worried about screenspace - that's always limited compared
to the amount of code being managed.  If you only showed "the part you're
working on" that might not be bad.

Constantly updating a graphical AST representation
of "what I'm working on" might be snappy; if you just keep regenerating from the
text you completely eliminate the problem of selecting things, and you can
highlight "where the cursor is".

If you mean for people to *edit* those directly,
it can be tricky work out how to select the "right spot" for insertion, etc.
I think trying to edit that would be more work than useful.
It's been done for stuff like mathematics:
However, that presumes that you can know what a given operation is
given its name, and how many parameters that operation would take,
which is not true in Lisp.

I'm guessing that you really mean to show those final representations, though, 
sqrt(a+b*(c-d)) or whatever.  If you use a Lisp as a subset of Python
that can work out fine.... but Python is a better Python.
A key power of Lisp is that you can define your own languages (e.g., macros),
use templating (e.g., ","), and other powerful techniques that exploit 
The earlier AST is trivially homomorphic.  However, the "final" representation
shown does *not* appear to be homomorphic.  That's fatal.

Trivial example: the final version added a "then" and "else" after an "if".
But there's no reason to believe that the "if" is actually
the built-in Lisp "if". I could easily define a macro that rewrites "if" into
something else (and indeed, that's a common thing to do in packages).
For example, maybe "if" means "interface" at that point.
Similarly, "defun" (Common Lisp) or "define" (Scheme) might mean the
specific names predefined in the language.. or not.

If you just want a specialized language inside a larger Lisp program,
feel free to create it.  Many have.  But if you want to write Lisp programs in
a "more readable" way, your notation has to be homomorphic & handle
arbitrary s-expressions.  There's simply no way to know what the symbols
"mean" while you're editing them.

I'm *not* saying it's impossible.  It's doable.  Sweet-expressions are one 
and the wisp developers have created another.
But you have to consider the general case.  If you limit yourself to
symbols with fixed meanings, there are other languages that already do the job.
If you're going to use a Lisp, it should be because Lisp provides some
advantage to you.

--- David A. Wheeler

Readable-discuss mailing list

Reply via email to