Fundamental Problems of Lisp

alright, as a consequence of the current thread “Xah on Lisp�, i took
some time to clean up my essay.

here's what i have so far on the syntax irregularity subsection:

----------------------------------------------

Fundamental Problems of Lisp

Xah Lee, 2008-07

In this article, we discuss 2 problems that are rooted in lisp. One is
the irregularity in its often cited regular syntax. The other is the
language's use of “cons� for list.

SYNTAX IRREGULARITIES

Lisp family of languages, in particular, Common Lisp, Scheme Lisp,
Emacs Lisp, are well know for its syntax's regularity, namely,
“everything� is of the form “(f x1 x2 ...)�.. However, it is little
talked about that there are several irregularities in its syntax. Here
are some examples of the syntax irregularity.

* The comment syntax of semicolon to end of line “;�.

* The dotted notation for cons cell “(1 . 2)�.

* The single quote syntax used to hold evaluation, e.g. “'(1 2
3)�.

* The backquote and comma syntax used to hold but evaluate parts
of expression, e.g. “(setq x 1) (setq myVariableAndValuePair
`(x ,x))�.

* The “,@� for inserting a list as elements into another list.
e.g. “(setq myListX (list 1 2)) (setq myListY (list 3 4)) (setq
myListXY `(,@ myListX ,@ myListY))�

In the following, we detail how these irregularities hamper the power
of regular syntax, and some powerful features and language
developments that lisp have missed that may be caused by it.

--------------------
Confusing

Lisp's irregular syntax are practically confusing. For example, the
difference between “(list 1 2 3)�, “'(1 2 3)�, “(quote (1 2 3))� is a
frequently asked question. The use of “`�, “,�, “,@� etc are esoteric.
If for all these special syntactical elements use the regular form “(f
args)�, then much confusion will be reduced and people will understand
and use these features better. For example, The “'(1 2 3)� might be
changed to “(' 1 2 3)�, and

(setq myListXY `(,@ myListX ,@ myListY))

could have been:

(setq myListXY (eval-parts (splice myListX) (splice myListY)))

or with sugar syntax for typing convenience:

(setq myListXY (` (,@ myListX) (,@ myListY)))�

--------------------
Syntax-Semantics Correspondence

A regular nested syntax has a one-to-one correspondence to the
language's abstract syntax tree, and to a large extent the syntax has
some correspondence to the language's semantics. The irregularities in
syntax breaks this correspondence.

For example, programers can pretty much tell what piece of source code
“(f args)� do by just reading the function's name. As a contrast, in
syntax soup languages such as Java, Perl, the programmer must be
familiar with each of its tens of syntactical forms. (e.g. “if (...)
{...}�, “for (...; ...; ...) {...}�, “(some? this: that)�, “x++�,
“myList = [1, 2, 3]� etc.) As one example, if lisp's “'(1 2 3)� is
actually “(quote 1 2 3)� or shortcut form “(' 1 2 3)�, then it is much
easier to understand.

--------------------
Source Code Transformation

Lisp relies on a regular nested syntax. Because of such regularity of
the syntax, it allows transformation of the source code by a simple
lexical scan. This has powerful ramification. (lisp's macros is one
example) For example, since the syntax is regular, one could easily
have alternative, easier to read syntaxes as a layer. (the concept is
somewhat known in early lisp as M-expression) Mathematica took this
advantage (probably independent of lisp's influence), so that you
really have easy to read syntax, yet fully retain the regular form
advantages. In lisp history, such layer been done and tried here and
there in various forms or langs ( CGOL↗, Dylan↗), but nevercaught on
due to largely social happenings. Part of these reasons are political
and lisper's sensitivity to criticism of its nested parens.

--------------------
Automatic, Uniform, Universal, Source Code Formatting

One of the advantage of pure fully functional syntax is that a
programer should never need to format his source code (i.e. pressing
tabs, returns) in coding, and save the hundreds hours of labor,
guides, tutorials, advices, publications, editor tools, on what's
known as “coding style convention�, because the editor can reformat
the source code on the fly based on a simple lexical scan.

Because lisp's syntax has lots of nested parenthesis, the source code
formatting is much more a labor intensive than syntax soup languages
such as Perl, even with dedicated lisp editor such as emacs that
contain large number editing commands on nested syntax.

The lisp community, established a particular way of formatting lisp
code as exhibited in emacs's lisp modes and written guides of
conventions. The recognization of such convention further erode any
possibility and awareness of automatic, uniform, universal,
formatting. (e.g. the uniform and universal part of advantage is
exhibited by Python)

As a example, the Mathematica language features a pure nested syntax
similar to lisp but without irregularities. So, in that language,
since version 3 released in 1996, the source code in its editor are
automatically formatted on the fly as programer types, much in the
same way paragraphs are automatically wrapped in a word processor
since early 1990s

--------------------
Syntax As Markup Language

One of the power of such pure nested syntax is that you could build up
layers on top of it, so that the source code can function as markup of
conventional mathematical notations (i.e. MathML) and or as a word-
processing-like file that can contain structures, images (e.g.
Microsoft Office Open XML↗), yet lose practical nothing.

This is done in Mathematica in 1996 with release of Mathematica
version 3. (e.g. think of XML, its uniform nested syntax, its diverse
use as a markup lang, then, some people are adding computational
semantics to it now (i.e. a computer language with syntax of xml. e.g.
O:XML↗). You can think of Mathematica going the other way, by starting
with a computer lang with a regular nested syntax, then add new but
inert keywords to it with markup semantics. The compiler will just
treat these inert keywords like comment syntax when doing computation.
When the source code is read by a editor, the editor takes the markup
keywords for structural or stylitic representation, with title,
chapter heading, tables, images, animations, hyperlinks, typeset math
expression (e.g. think of MathML↗) etc. The non-marked-up keywords are
shown as one-dimentional textual source code just like source code is
normally shown is most languages.)

---------------------

I spend about 4 hours on it today. The cleaning up is only about 20%
done. There's probably few days full time work. Above is what i have
so far on the part about irregularities of syntax problem. No editing
has yet done on the cons business section (e.g. the very phrase “cons
business� needs to be rephrased, depending on what kind of publication
it's gonna go to). Also, the postscript and addendum sections and
possibly the FAQ section, together currently constitute more that 50%
of the text, needs to be incorporated into the main text. The section
“Will Lisp ever be Popular� needs to be removed from this article.

the article as it currently stands is at:
http://xahlee.org/UnixResource_dir/w..._problems.html

In general, editing newsgroup posts into book quality publication is
quite a lot work... Though, having a draft to start with is perhaps
50% of the work.

Xah
∑ http://xahlee.org/

☄

On Aug 24, 1:42*am, "xah...@gmail.com" <xah...@gmail.com> wrote:
>
> (setq myListXY `(,@ myListX ,@ myListY))
>
> could have been:
>
> (setq myListXY (eval-parts (splice myListX) (splice myListY)))
>
> or with sugar syntax for typing convenience:
>
> (setq myListXY (` (,@ myListX) (,@ myListY)))”
>

No, it should be:

(setq myListXY (append myListX myListY))

Anyways the idea of the "reader shortcuts" is to remove extra braces,
your 3rd snippet, these reader shortcuts are simply re-definitions.

Cheers

leppie

On Aug 24, 1:42 am, "xah...@gmail.com" <xah...@gmail.com> wrote:
> alright, as a consequence of the current thread “Xah on Lisp�, i took
> some time to clean up my essay.
>
> here's what i have so far on the syntax irregularity subsection:
>
> ----------------------------------------------
>
> Fundamental Problems of Lisp
>
> Xah Lee, 2008-07
>
> In this article, we discuss 2 problems that are rooted in lisp. One is
> the irregularity in its often cited regular syntax. The other is the
> language's use of “cons� for list.
>
> SYNTAX IRREGULARITIES
>
> Lisp family of languages, in particular, Common Lisp, Scheme Lisp,
> Emacs Lisp, are well know for its syntax's regularity, namely,
> “everything� is of the form “(f x1 x2 ...)�. However, it is little
> talked about that there are several irregularities in its syntax. Here
> are some examples of the syntax irregularity.
>
> * The comment syntax of semicolon to end of line “;�.
>
> * The dotted notation for cons cell “(1 . 2)�.
>
> * The single quote syntax used to hold evaluation, e.g. “'(1 2
> 3)�.
>
> * The backquote and comma syntax used to hold but evaluate parts
> of expression, e.g. “(setq x 1) (setq myVariableAndValuePair
> `(x ,x))�.
>
> * The “,@� for inserting a list as elements into another list.
> e.g. “(setq myListX (list 1 2)) (setq myListY (list 3 4)) (setq
> myListXY `(,@ myListX ,@ myListY))�
>
> In the following, we detail how these irregularities hamper the power
> of regular syntax, and some powerful features and language
> developments that lisp have missed that may be caused by it.
>
> --------------------
> Confusing
>
> Lisp's irregular syntax are practically confusing. For example, the
> difference between “(list 1 2 3)�, “'(1 2 3)�, “(quote (1 2 3))� is a
> frequently asked question. The use of “`�, “,�, “,@� etc are esoteric.
> If for all these special syntactical elements use the regular form “(f
> args)�, then much confusion will be reduced and people will understand
> and use these features better. For example, The “'(1 2 3)� might be
> changed to “(' 1 2 3)�, and
>
> (setq myListXY `(,@ myListX ,@ myListY))
>
> could have been:
>
> (setq myListXY (eval-parts (splice myListX) (splice myListY)))
>
> or with sugar syntax for typing convenience:
>
> (setq myListXY (` (,@ myListX) (,@ myListY)))�
>
> --------------------
> Syntax-Semantics Correspondence
>
> A regular nested syntax has a one-to-one correspondence to the
> language's abstract syntax tree, and to a large extent the syntax has
> some correspondence to the language's semantics. The irregularities in
> syntax breaks this correspondence.
>
> For example, programers can pretty much tell what piece of source code
> “(f args)� do by just reading the function's name. As a contrast, in
> syntax soup languages such as Java, Perl, the programmer must be
> familiar with each of its tens of syntactical forms. (e.g. “if (....)
> {...}�, “for (...; ...; ...) {...}�, “(some? this: that)�, “x++�,
> “myList = [1, 2, 3]� etc.) As one example, if lisp's “'(1 2 3)� is
> actually “(quote 1 2 3)� or shortcut form “(' 1 23)�, then it is much
> easier to understand.
>
> --------------------
> Source Code Transformation
>
> Lisp relies on a regular nested syntax. Because of such regularity of
> the syntax, it allows transformation of the source code by a simple
> lexical scan. This has powerful ramification. (lisp's macros is one
> example) For example, since the syntax is regular, one could easily
> have alternative, easier to read syntaxes as a layer. (the concept is
> somewhat known in early lisp as M-expression) Mathematica took this
> advantage (probably independent of lisp's influence), so that you
> really have easy to read syntax, yet fully retain the regular form
> advantages. In lisp history, such layer been done and tried here and
> there in various forms or langs ( CGOL↗, Dylan↗), but never caught on
> due to largely social happenings. Part of these reasons are political
> and lisper's sensitivity to criticism of its nested parens.
>
> --------------------
> Automatic, Uniform, Universal, Source Code Formatting
>
> One of the advantage of pure fully functional syntax is that a
> programer should never need to format his source code (i.e. pressing
> tabs, returns) in coding, and save the hundreds hours of labor,
> guides, tutorials, advices, publications, editor tools, on what's
> known as “coding style convention�, because the editor can reformat
> the source code on the fly based on a simple lexical scan.
>
> Because lisp's syntax has lots of nested parenthesis, the source code
> formatting is much more a labor intensive than syntax soup languages
> such as Perl, even with dedicated lisp editor such as emacs that
> contain large number editing commands on nested syntax.
>
> The lisp community, established a particular way of formatting lisp
> code as exhibited in emacs's lisp modes and written guides of
> conventions. The recognization of such convention further erode any
> possibility and awareness of automatic, uniform, universal,
> formatting. (e.g. the uniform and universal part of advantage is
> exhibited by Python)
>
> As a example, the Mathematica language features a pure nested syntax
> similar to lisp but without irregularities. So, in that language,
> since version 3 released in 1996, the source code in its editor are
> automatically formatted on the fly as programer types, much in the
> same way paragraphs are automatically wrapped in a word processor
> since early 1990s
>
> --------------------
> Syntax As Markup Language
>
> One of the power of such pure nested syntax is that you could build up
> layers on top of it, so that the source code can function as markup of
> conventional mathematical notations (i.e. MathML) and or as a word-
> processing-like file that can contain structures, images (e.g.
> Microsoft Office Open XML↗), yet lose practical nothing.
>
> This is done in Mathematica in 1996 with release of Mathematica
> version 3. (e.g. think of XML, its uniform nested syntax, its diverse
> use as a markup lang, then, some people are adding computational
> semantics to it now (i.e. a computer language with syntax of xml. e.g.
> O:XML↗). You can think of Mathematica going the other way, by starting
> with a computer lang with a regular nested syntax, then add new but
> inert keywords to it with markup semantics. The compiler will just
> treat these inert keywords like comment syntax when doing computation.
> When the source code is read by a editor, the editor takes the markup
> keywords for structural or stylitic representation, with title,
> chapter heading, tables, images, animations, hyperlinks, typeset math
> expression (e.g. think of MathML↗) etc. The non-marked-up keywords are
> shown as one-dimentional textual source code just like source code is
> normally shown is most languages.)
>
> ---------------------
>
> I spend about 4 hours on it today. The cleaning up is only about 20%
> done. There's probably few days full time work. Above is what i have
> so far on the part about irregularities of syntax problem. No editing
> has yet done on the cons business section (e.g. the very phrase “cons
> business� needs to be rephrased, depending on what kind of publication
> it's gonna go to). Also, the postscript and addendum sections and
> possibly the FAQ section, together currently constitute more that 50%
> of the text, needs to be incorporated into the main text. The section
> “Will Lisp ever be Popular� needs to be removed from thisarticle.
>
> the article as it currently stands is at:http://xahlee.org/UnixResource_dir/w..._problems.html
>
> In general, editing newsgroup posts into book quality publication is
> quite a lot work... Though, having a draft to start with is perhaps
> 50% of the work.
>
> Xah
> ∑http://xahlee.org/
>
> ☄

I dont share your concerns described in your article.
'a is simply short for (quote a). For example:

(car ''a) = (car (quote (quote a))) --> quote (i.e. the car of (quote
a))

It is not clear to me why you would want to write (quote (1 2 3)) as
(quote 1 2 3).
What would in this case be the value of (quote quote 1 2 3)?

I find the quasiquote (and quasisyntax) notation very useful.
There is one nasty pitfall though:

(define *a 1)
(define *quasiquote 2)
(define *unquote 3)
`((a ,*a) (quasiquote ,*quasiquote)) ;--> ((a 1) (quasiquote (unquote
*quasiquote)))
`((a ,*a) (quasiquote ,*quasiquote) (unquote ,*unquote)); --> error:
unquote: not in quasiquote in: (unquote *unquote)
^^^^^^^^^
The correct way to introduce symbols "quasiquote" and "unquote" within
a quasiquote form is:

`((a ,*a) (,'quasiquote ,*quasiquote) (,'unquote ,*unquote)) ;--> ((a
1) (quasiquote 2) (unquote 3))
^^ ^^
Likewise for "unquote-splicing".

Jos

2008-08-25

On Aug 24, 12:23 am, leppie <xacc....@gmail.com> wrote:
> On Aug 24, 1:42 am, "xah...@gmail.com" <xah...@gmail.com> wrote:
>
>
>
> > (setq myListXY `(,@ myListX ,@ myListY))
>
> > could have been:
>
> > (setq myListXY (eval-parts (splice myListX) (splice myListY)))
>
> > or with sugar syntax for typing convenience:
>
> > (setq myListXY (` (,@ myListX) (,@ myListY)))�
>
> No, it should be:
>
> (setq myListXY (append myListX myListY))

The example is to serve the purpose of illustration the meaning of “`�
and “,@�. As such, the example i gave:

(setq myListXY (` (,@ myListX) (,@ myListY)))

is to the point.

In particular, the example is not used in the context of “How to join
2 lists�.

> Anyways the idea of the "reader shortcuts" is to remove extra braces,
> your 3rd snippet, these reader shortcuts are simply re-definitions.

Again, the example i gave:
«
(setq myListXY `(,@ myListX ,@ myListY))

could have been:

(setq myListXY (eval-parts (splice myListX) (splice myListY)))

or with sugar syntax for typing convenience:

(setq myListXY (` (,@ myListX) (,@ myListY)))�
»

is to illustrate a alternative syntax variation design that are
consistent with lisp's syntax philosophy of regularity. In particular,
the example is not in the context of how to redefine a variable.

ultimately, you have to ask why lisper advocate nested syntax in the
first place.

if lispers love the nested syntax, then, the argument that there
should not be irregularities, has merit. If lispers think occational
irregularities of non parenthesized syntax is good, then there's the
question of how many, or what form. You might as well introduce “i++�
for “(setq i (1+ i))�.

Xah
∑ http://xahlee.org/

☄

> * The comment syntax of semicolon to end of line “;”.

(defmacro comment (&rest args)
nil)

(comment "My amazing code")
(defun blah (x)
...)

Not an entire solution, but for global comments at least, you have the
syntax you wanted.
The compiler will ignore your comments, as it should do.

On Aug 25, 5:26 am, Ali <emailalicl...@gmail.com> wrote:
> > * The comment syntax of semicolon to end of line “;�.
>
> (defmacro comment (&rest args)
> nil)
>
> (comment "My amazing code")
> (defun blah (x)
> ...)
>
> Not an entire solution, but for global comments at least, you have the
> syntax you wanted.
> The compiler will ignore your comments, as it should do.

The essay is a criticism on the design, it is not about “what are some
workarounds?�.

If your post is to argue that the criticism is invalid because there
are easy workaround, then that is not a good argument. For example, if
you criticise that a particula model of car's wheel is too small.
Then, some fan retort that you can easily install larger wheels. But
for the public at large, they still suffer from the small wheel
problem. For each person to install larger wheel has multiple costs.
The awareness of the need to change wheel is a cost of knowledge
transmission. The actual replacement costs money and time. Also, each
person may use different sized wheels, and the replacement may not be
well done... so in general, such workaround although is satisfactory
for individuals who knows about the issue and takes time to fix it,
but on the whole does not invalidate the criticism.

I would recommend this article in Wikipedia on
http://en.wikipedia.org/wiki/Critical_thinking

Xah
∑ http://xahlee.org/

☄

So what?
a) Should all lispers see the errors of lisp as critical and recommend
people not start using it?
b) Start using a different language that does not come with these
built-in problems?
c) Create a new lisp, but without these problems, and follow b)?
d) Continue using lisp, but drag our heads in shame at the nasty
horrible terrible hacks we endure?

That's not rhetorical, please could you reply with an "a", "b", "c",
"d" or "other"?

On Aug 25, 6:09 am, Ali <emailalicl...@gmail.com> wrote:
> So what?
> a) Should all lispers see the errors of lisp as critical and recommend
> people not start using it?
> b) Start using a different language that does not come with these
> built-in problems?
> c) Create a new lisp, but without these problems, and follow b)?
> d) Continue using lisp, but drag our heads in shame at the nasty
> horrible terrible hacks we endure?
>
> That's not rhetorical, please could you reply with an "a", "b", "c",
> "d" or "other"?

A criticism is just a criticism. My criticism in particular, does not
mean lisp is bad. In fact, i recommend lisp as a language. I myself
love and use emacs lisp extensively. As for Scheme Lisp and Common
Lisp, i consider them better languages than, say, C, Java, Perl,
Pyhton, PHP.

> a) Should all lispers see the errors of lisp as critical and recommend
> people not start using it?

Of course not.

> b) Start using a different language that does not come with these
> built-in problems?

No.

The importance of criticism is that it serves a particular aspect of
in the benefits of communication. You as a lisp programer, may or may
not agree to the severity of the criticism. However, nevertheless it
serves a purpose as a minor form of knowledge, namely that of
awareness of some issues.

As a example of positive outcome of such awareness, perhaps someone
working on a lang with lisp syntax (such as liskell) would now avoid
syntax irregularities. Apparantly Qi and Arc also used irregular
syntax. But, if the criticism about lisp's syntax irregularities is
well known, and if known ten years ago, then just perhaps Qi and Arc
would stick to a pure nested syntax without any irregularities.

Even if someone does not agree with the criticism on lisp's syntax
after serious evaluation, nevertheless some issues discussed in the
article does serve some type of infomation communication and ideas;
such as regularity of syntax and consequences and its relation to XML
and its various transformation technologies, markup lang based on
regularities of syntax, etc.

> c) Create a new lisp, but without these problems, and follow b)?

Yes. That would be a very direct and positive consequence of the
criticism.

(Whether if such a lang would actually be beneficial as the criticsim
implied, we perhaps have to see it in practice.)

> d) Continue using lisp, but drag our heads in shame at the nasty
> horrible terrible hacks we endure?

No.

Of course, negative criticisms always have certain bad aura.
Particularly when power is involved in the subject such as stances and
beliefs in political factions. The essay receives a lot sneering
precisely because computer language communities are in fact highly
political.

Computer langs are not religions per se. People can be attached to a
lang, but a language is nevertheless not a set of dogma on
metaphysical issues that makes up religion. Sensible discussion of
computer languages, technical comparison, should be encouraged. Issues
like what lang should be more used, or which is more popular, or what
makes a lang better, are subject to study under various branches of
psychology, sociology.

> That's not rhetorical, please could you reply with an "a", "b", "c",
> "d" or "other"?

Happy to do so.

Xah
∑ http://xahlee.org/

☄

On Aug 25, 3:23*pm, "xah...@gmail.com" <xah...@gmail.com> wrote:
> On Aug 25, 6:09 am, Ali <emailalicl...@gmail.com> wrote:
> > c) Create a new lisp, but without these problems, and follow b)?
>
> Yes.

And one (hopefully last) question. Have you considered writing a lisp,
or other language, yourself without these irregularities?

On Aug 25, 9:01 am, Ali <emailalicl...@gmail.com> wrote:
> On Aug 25, 3:23 pm, "xah...@gmail.com" <xah...@gmail.com> wrote:
>
> > On Aug 25, 6:09 am, Ali <emailalicl...@gmail.com> wrote:
> > > c) Create a new lisp, but without these problems, and follow b)?
>
> > Yes.
>
> And one (hopefully last) question. Have you considered writing a lisp,
> or other language, yourself without these irregularities?

No. My knowledge and experience of parsers and compilers is basically
zero. Say, below any studious person who just graduated from college
with a computer science degree.

I have some interest in parsers, so this year i started to read and
learn tools about parsers. In particular, my interest in parsers is
writing tools for text processing, in particular processing nested
syntax such as lisp and xml. I have no interest in compilers though.

With the profileration of tools today... i probably can hackup a
interpreter for some new language in say, perl. Even that will take me
perhaps half a year or more, and when done, it'd be basically a
useless toy.

as for language's syntax, i do not find nested syntax ideal. I have
been programing elisp as hobby on and off for 2 years. For all my love
of uniformality, AI, functional programing, honestly i find the nested
syntax problematic. (not counting lisp irregularity since the few lisp
syntax irregularity doesn't matter that much in practice).

(i find nested syntax problematic for practical reasons. Namely,
reading the source code and typing it. The other major reason that
sting me as i start to write more complex programs, is that sequencing
functions forces me into so much nesting (i.e. several nested mapcar).
I have some detail in this article:
“The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations�
http://xahlee.org/UnixResource_dir/writ/notations.html
)

Recently i've been thinking, a ideal syntax that completely ditchs any
form of nesting in syntax. That is, the source code is just a bunch
of lines, each line is just a sequence of functions. For example,
Mathematica's prefix notation “f@g@x� or postfix notation “x//g//f�,
or unix pipe (e.g. “x | g | f�), and APL's syntax is similar idea.

The problem with such a syntax is that it limits functions to one arg
only. A solution might be that for any function that needs 2 or more
args, the lang makes everything as list. But then, this means simple
things like “1+2*3� becomes something like polish notation “[2 3] * 1
+�, which is quite unreadable and unatural. APL solves it by allowing
both binary and uninary functions ... but then i don't think that'd be
a perfect syntax.

another train of thought i had recently, is that, i think all langs
should have lisp's nested syntax (with no irregularities), then
another layer on top of it, whatever it may be. This is how
Mathematica's syntax is, and i presume also liskell. Since all textual
langs has a abstract syntax tree, and the nested syntax is isomorphic
to trees, so theoretically all langs could have a nested syntax like
lisp's. I'm not sure how difficult this actually is to do, or how
difficult for a existing lang to add such a layer. I guess its rather
trivial in the context of compiler science, but i don't know much
about parsers/compilers to be sure.

if all lang support the pure nested syntax, then it will have a major
impact on cross-lang understanding, usher practical major progress on
programer's understanding of the role of syntax in langs, and have
major impact on language translation (aka compiling). (after all,
theoretically, proper parser/compiler creates a AST in the parsing
stage anyway. A pure nested syntax could be made as a explicit stage.
That is, sugar syntax → nested syntax → AST)

btw, i have a question... are those AST created in the parsing process
as some kinda explicit datatype? Wouldn't it be easy to print them out
like lisp's nested paren?

it is my wild guess, that the idea all or almost all languages will
have a nested syntax like lisp (as a layer), might actually be a
reality say in maybe 20 or 50 years.

* * *

as for interests, i have much more interest in perfecting my expertise
in elisp, and learning Haskell, and learning a theorem proving lang
such as coq to enhance my understanding in mathematical logic.

I also have far more interest in many math subjects and geometry
programing subjects. I have much existing projects to be done in
geometry of plane curves, tiling theory, algorithmic mathematical art,
surface theory, etc. (you can find these on my website)

my interest in computational mathematics (computational logic,
programing geometry) outshine my interest in programing langs or
typical computer science issues. (am expert in programing geometry; am
newbie in computational logic)

Xah
∑ http://xahlee.org/

☄