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 <arne_...@web.de> > 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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck® Code Sight™ - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
_______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
