Re: [Readable-discuss] spinoff wisp srfi

[Arne B. <arn...@we...>]

Hi David,

Sorry for answering so late. I already adjusted the draft according to some of your comments, but did not get out of the todo-torrent far enough to answer you and finish the rest…

Am Sonntag, 8. Juni 2014, 18:05:53 schrieb David A. Wheeler:
> On Sun, 08 Jun 2014 19:50:45 +0200, Arne Babenhauserheide <arn...@we...> wrote:
> > > > Also despite the different focus we chose, I consider you folks to be the experts on indentation-sensitive lisp, so I would be very happy to get your opinion.
> > > >
> > > >
> > > >     http://draketo.de/proj/wisp/srfi.html

> I don't think that wisp "supercedes" SRFI-105 or SRFI-110; I would instead say it describes an "alternative to".
> Indeed, I suspect a system could simultaneously use SRFI-105 and wisp.

For 105 the SRFi uses the wording “builds upon”: That’s what it actually does: I nowadays use SRFI-105 and wisp together. Sadly the integration isn’t quite as seamless as with SRFI-110, because curly infix and neoteric expressions as first element on a line have to be prefixed by a dot. I wish that were different, but to achieve this I would have to increase complexity quite a bit. And I guess an adaption to treat ({1 + 2}) as {1 + 2} (which would be a simpler version of SRFI-105) could disable some options (like using curly infix to chain functions).

For 110 I now use “alternative to” (which is much closer to what wisp actually is: A different style to achieve the same). Only SRFI-49 is really superceded by wisp.

> > "SRFI-110 improves a lot over the implementation of SRFI-49 and resolves the group-naming by introducing 3 different grouping-syntaxes ($, \\ and <* *>). These additional syntax-elements however hurt readability for newcomers a lot. They make some code written in SRFI-110 look quite similar to perl and bash:"
> I don't agree that they "hurt readability" at all, indeed, I think they help.  I suggest changing this (and elsewhere) to something like "The author believes that these additional syntax elements impede readability because...".  Also, I know both perl and bash, and the resulting code doesn't look anything like either.  The "$" stuff looks like Haskell, if anything.

To me they look very, very strange: They use rare characters (seldomly used in normal prose) which makes the code look alien to non-programmers. Even simple constructs like this->run() look strange to non-programmers - which is far too easy to forget when we’re deep in code.

Also they look like they were bolted on - not in the initial design - and as if they were taking over more and more of the code. In this they are similar to list comprehensions in Python: They are very convenient and powerful - too powerful to understand them easily. You show how 4 lines of code can be contracted bit by bit into 1 line with $. And this is 

> The spec overview in 4.1 needs to clearly define *what* each syntax element does, at least as a basic case.  Examples are great for clarifying definitions, but do not *replace* them.  E.G., "A lone period at the beginning of a line (after any indentation) causes that line to continue the previous line."  Or something like that.

I had expected that the headlines did that, but doing so used headlines for something out of their normal usecase - likely that’s a bad idea. Thanks for spotting it!

I now moved the rules from the headlines to the subsection body and used short headlines.

> s/synatx/syntax/

Thanks!

> I would move "justification" to separate section.  Users often don't care WHY something is so... they just need to know what it is.

Good idea.

> I obviously agree that a better homoiconic syntax is needed for Lisp.  I also obviously don't agree that the choices you've made are the best ones, since I made different choices :-).

Yepp.

> A few comments, though, besides ones already made.  I have concerns that lone ":" is actually *widely* used for other purposes, e.g., type declarations, that this syntax interferes with.  Similarly, "_" has many uses on its own.  I think it'd be wise to grab a bunch of code and try to reformat it this way.  I did that a *LOT* to create SRFI-110; a lot of syntax that SEEMS like a good idea doesn't actually work well with real code.  And while simplicity is a *great* goal, too simple is its own problem. 

I agree. It’s just that we don’t agree on the right degree of simplicity ☺

And I think that’s OK: It comes down to taste. I’m used to the mostly hidden syntax of Basic Python¹, so what I try to find is a syntax and semantic which combines the power of Scheme with the syntax of Basic Python. Seeing code with such little syntactic ballast impressed me so deeply that I actually wrote a song about it ☺ http://draketo.de/english/songs/light/with-python-from-the-shadows

¹:  With Basic Python I mean everything short of list/dict comprehensions. As soon as you throw in these advanced concepts, the syntax of Python actually shows more and more - which is a bad thing in my opinion. See py2guile for more arguments in that direction: http://draketo.de/proj/py2guile/#sec-4-1

> All we *really* need is 1 and 0; anything else is extraneous syntax :-).

☺

Differently put: All Turing complete languages differ solely on syntactic sugar. (Adventures of a Pythonista in Schemeland: http://www.phyast.pitt.edu/~micheles/scheme/scheme12.html#are-macros-just-syntactic-sugar)

Best wishes,
Arne
-- 
1w6 sie zu achten,
sie alle zu finden,
in Spiele zu leiten
und sacht zu verbinden.
→ http://1w6.org