Comment on SRFI-110 and Comparison to Genyris xyzzy
Bill Birch
(22 May 2013 15:03 UTC)
|
Re: Comment on SRFI-110 and Comparison to Genyris xyzzy
David A. Wheeler
(23 May 2013 13:39 UTC)
|
sweet-expressions are not homoiconic
John David Stone
(23 May 2013 16:08 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(23 May 2013 16:19 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(23 May 2013 16:32 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 03:55 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 03:12 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(24 May 2013 15:34 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(24 May 2013 20:02 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 20:09 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(24 May 2013 21:35 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 22:40 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(24 May 2013 23:13 UTC)
|
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 03:43 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(25 May 2013 03:20 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 04:17 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 04:27 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(25 May 2013 04:55 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 18:14 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(26 May 2013 23:26 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 00:29 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(27 May 2013 15:51 UTC)
|
Re: sweet-expressions are not homoiconic
Alan Manuel Gloria
(28 May 2013 04:28 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(28 May 2013 18:34 UTC)
|
Re: sweet-expressions are not homoiconic
Beni Cherniavsky-Paskin
(26 May 2013 20:40 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(26 May 2013 22:43 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 00:00 UTC)
|
Re: sweet-expressions are not homoiconic
Alexey Radul
(27 May 2013 03:32 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 04:44 UTC)
|
Re: sweet-expressions are not homoiconic
Alexey Radul
(27 May 2013 05:50 UTC)
|
Re: sweet-expressions are not homoiconic
Alan Manuel Gloria
(27 May 2013 06:34 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 15:14 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 13:55 UTC)
|
Re: sweet-expressions are not homoiconic
Alexey Radul
(27 May 2013 16:27 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(27 May 2013 15:55 UTC)
|
RE: sweet-expressions are not homoiconic
Jos Koot
(27 May 2013 04:57 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 13:37 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(27 May 2013 15:50 UTC)
|
John David Stone <xxxxxx@cs.grinnell.edu> 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." (Wikipedia) > > 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