[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sweet-expressions are not homoiconic

This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 contain all messages, not just those from before July 7th, 2015.

John David Stone <stone@xxxxxxxxxxxxxxx> wrote:
>         By adding markers.  That's my point.

I already know we add markers.  Your belief that
markers are somehow evil or unnecessary is unproven at best.

If you liked indentation (I know you don't) and the real problem
was the number of markers, you can look at SRFI-49's I-expressions
(which only has the "group" marker) or wisp
(which has ":" and ".").  But in both cases, there are a number
of serious weaknesses in terms of readability and usability,
some of which you've brought up yourself.

I think it's important to *minimize* the number of markers,
because each one must be learned and implemented.
Each one should be general and powerful, to justify themselves.
But there's no empirical reason that there must be 0 markers.
Heck, the ' mark in 'x is fundamentally a marker; some early Lisps
didn't have quote, and people HATED its omission.
(One Lisp book I have recommends that people avoid implementations
that don't implement '.  The fact that I have that book tells me I've
been at Lisp too long :-). )

I said:
>  > I view notations as an engineering exercise, ...

John David Stone:
>         Maybe that's part of the difficulty.  Certainly Wheeler has arrived
> at an engineering solution to the problems he encountered.  I view
> notations as ways of expressing and communicating ideas.

The two statements are not in conflict.

I *agree* that notations are ways of expressing and communicating ideas.
When you're simply a *user* of a notation, that's a perfectly fine way
to describe the purpose of a notation.

But someone has to *devise* those notations, and devising notations
is a design task (aka an "engineering" task) that involves tradeoffs
of efficiency, ease of understanding, flexibility, and so on .
This group is fundamentally about *creating* a notation, not merely
*using* one, so we've focused on the *engineering* of a notation.
I think everyone *assumes* that the resulting notation should be
useful for "expressing and communicating ideas".

For comparison, the history of mathematical notation
is a long and complicated one, with many major mathematicians spending
significant time working out how to notate constructs.
Leibniz, for example, "thought symbols were important for human understanding.
He attached so much importance to the invention of good notations
that he attributed all his discoveries in mathematics to this.
His notation for the infinitesimal calculus is an example of his skill in this regard."

>  > Do you have a specific recommendation instead?
>         No.

Okay then.  Those who only complain will have to step aside
for those who are actually solving the problem :-).

In all seriousness, if you can suggest a better approach, I'm listening.
But complaining that you don't like the solution, without finding anything
better to offer, is not really all that helpful.

>  I contributed to this discussion because I wanted to state the
> moral of the cautionary tale clearly and emphatically...

I think it's a cautionary tale only in your own mind.

It's fine if you don't like it personally, but that doesn't make it less effective.

I think the vast majority of software developers would prefer to use
sweet-expressions instead of traditional s-expressions.
I've been using Lisps for over 3 decades, and I know *I* do.

> If a programming language features syntactic constructions with varying numbers
> of components that are frequently deeply nested, you can't make programs
> written in that language more readable by replacing the grouping symbols
> with whitespace.  Whitespace is needed for other purposes that aren't fully
> consistent with grouping.

The "can't" is clearly false, and the rest of the claim is on very shaky ground:

1. Many people are quite satisfied with indentation-for-grouping . In particular,
Python *already* uses indentation for grouping, and Python
is widely-used (TIOBE ranking #8 this month) and is widely accepted as
one of the MOST readable programming language notations.  There are other
languages where indentation is relevant (e.g., Haskell); it's not unique to Python.

2. Indentation-for-grouping works fine for Scheme and Common Lisp, even with
deep nesting.  There are ALREADY programs written in sweet-expressions.
You keep saying that something "can't be done", but we are ALREADY DOING IT.
That is not helping your argument :-).

>         I'm hoping that programming language designers will eventually be
> able to anticipate that the use of whitespace for grouping is a bad idea,
> just as they have come to understand that the use of whitespace as a
> pattern-matching or concatenation operator (as in SNOBOL4) was a bad idea.

It appears to me that you just don't like indentation-as-grouping, period.
Which is fine, you have the right to your own preferences.

But claiming that your personal preferences prove that something cannot be
done simply doesn't follow.  And since Python etc. are widely used, your personal
preferences are clearly not equivalent to a vast number of other people's.

I don't believe that all languages or notations should be indentation-sensitive.
But John McCarthy, and most of the development world since then, believes that
current Lisp notation has serious problems.  After looking for various ways to
make things better, the best approach I've found includes the use of
syntactically-relevant indentation (like SRFI-49), combined with a
small set of markers to address the known problems of depending
*solely* on indentation.

--- David A. Wheeler