Hi David, Am Donnerstag, 13. November 2014, 18:23:01 schrieb David A. Wheeler: > On Thu, 13 Nov 2014 21:56:19 +0100, Arne Babenhauserheide <arne_...@web.de> > wrote: > > I considered it, but decided against it, because in wisp that provides > > less advantages than in sweet expressions, while adding ambiguity (one > > more way to spell the same code). > > I don't think the ability to spell something more than one way is usually > termed "ambiguous"; > I don't know if there's a term for that; perhaps "multiple spellings"?
That sounds better, yes. > In any case, "multiple spellings" (or whatever it's called) is inherent in > Scheme and Common Lisp. > For example, 'x and (quote x) are already two ways to write the same thing. These are a bootstrap way and a reader way. 'x actually gets translated to (quote x). In wisp however, `a : b` and `a b()` would both be translated to `a (b)`. They are equivalent spellings which become a common lower-level spelling. I don’t mind having the possibility to write `a b()`, and since wisp requires SRFI-105 for curly-infix, all wisp users should have the option to enable neoteric expressions in any source-file without increasing the requirements for implementors. I just don’t think that it makes sense to push the added complexity on every wisp user *by default*. > Yes, it adds a different way to spell the same code, but in many > cases it would be the more common way to do it (e.g., the normal way > in math and other programming languages). I think that for neoteric expressions the cost outweights the gain while for curly-infix the gain is greater than the cost. A few months ago I had a collegue look at some wisp-code I wrote and he said “I forgot how ugly lisp is”. It turned out that with that he was referring only to prefix-math. > > That expression in wisp is simply > > stuff : cos a … > > In sweet that would be a problem, as far as I know, because if you want to > > do > > > > (stuff (cos a) b c d e) … > > Here neoteric experssions help a lot: > > > > stuff cos(a) b c d e > > That would be the normal way (and recommended) way to do it. > > There are alternatives if you hate neoteric expressions in sweet-expressions, > e.g.: > stuff > cos a \\ b \\ c \\ d \\ e This is part of what made me start to work on wisp in the first place ☺ Too many ways to express something, which I think mainly comes from not being able to continue the argument list easily. Yes, if you know all the sweet syntax, quite a few code snippets will likely look more readable than those in wisp. But the additional syntax elements provide a high barrier for learning, because they require retraining the eyes. > But it seems to that the "obvious" way is the right way: > stuff cos(a) b c d e > > But in wisp you’d just do > > > > stuff : cos a > > . b c d e > > which, though still harder to read than sweet-expressions, is less bad :-). > > "Less bad" is not exactly a high aspiration :-). It’s a different trade-off: Simplicity against less rough edges. > I think wisp is the wrong trade-off anyway, but since you're working on it, > contrast that to: > > > stuff cos(a) > > . b c d e > > which is still harder to read, but less harder :-). It actually looks pretty good, I think. But it does not need to go into the spec, because it is (and should remain) trivial to integrate it later, if it turns out to be needed: Just say “requires activation of neoteric expressions in the reader”. It’s a single line of code for the implementations, so I think it can be done later, if my intuition turns out to be wrong. > > On the other hand, this difference makes neoteric expressions much less > > elegant in wisp than in sweet. In sweet you can just to > > > > stuff > > cos(a) > > > > because a single element on a line is treated as that element, not as a > > function call. In wisp you’d have to do > > > > stuff > > . cos(a) > > > > because a line always begins a function call, except when started with a > > period. > > Of course, this why I decided to NOT have all lines begin a function call in > sweet-expressions. > Both sweet-expressions and I-expressions (SRFI-49) have a different semantic, > because it > seems to be "what humans assume" in practice. It’s what lisp and scheme do, but for example it isn’t what the shell does. I agree that lisp and scheme programmers tend to assume this, but I don’t think that it is right for indentation-based scheme. But since this is the main forking point between sweet and wisp, I guess it isn’t a point which can be changed by argument ☺ It comes down to personal preferences: The weight we give to different aesthetic aspects of programming languages. For me, the syntactic simplicity is one of the main selling points of lisp and scheme, and sweet departs from that by adding more than the absolute minimum of the required syntax elements for creating a general, indentation-based representation of scheme-code. The cost I pay for that is that there will be code snippets which will look less elegant in wisp than in sweet. You could say, that they look less sweet ☺ I think that for new code their number will be small, because programmers will instinctively write code which looks elegant. The programming style will evolve (and if no one but me will use it, then at least my style will evolve - it already does). I think that every language promotes its own style. Java programmers write very verbose programs with long variable and function names and deep nested package structures. Python programmers write concise programs with very short identifiers. From the scheme-code I already know I’d say that scheme-programmers often nest many functions on the same line (especially when using lambda). And lots of apply and map. I’m still learning there, though. Let’s see where it takes me :) Best wishes, Arne
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
