On Thu, 1 Sep 2016 19:37:43 -0400, luke wallace <lukewallace1...@gmail.com> wrote: > 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: http://icm.mcs.kent.edu/reports/2006/ICM-200601-0001.pdf 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, e.g., 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 homomorphism. 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 solution, 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
