Am Freitag, 21. November 2014, 19:31:54 schrieb David A. Wheeler: > David A. Wheeler: > > wisp: > > define : hello > > display "Hello World!" > > newline > > define : hello2 who > > format #t "Hello ~A!\n" who > > If you're using wisp you probably do *not* want to use > a neoteric expression as the *first* element on a line > (unless you're actually calculating what function/procedure to call). > So teach that style rule, and you avoid that (wisp) gotcha.
I don’t consider it a gotcha to always treat the first element on a line as a function call. But the elegancy of neoteric expressions only shows with seeing a single item on a line as variable an not as function call: Then defining a function and calling it becomes mostly symmetric. But only mostly. In wisp the inline colon provides a similar symmetry. > However, in *both* wisp and sweet-expressions there are MANY > uses for neoteric-expressions in the REST of the line. > For example, here's a line from math.slisp: > cons car(lyst) flatten-operation(op cdr(lyst)) For my taste of code, that already becomes too deeply nested: The last part is quite hard to parse. I had trouble keeping in mind that op is just a parameter. Alternative: cons : car lyst flatten-operation op : cdr lyst While car(lyst) looks very readable to me, flatten-operation(op cdr(lyst)) already looks complex. It looks as if op and cdr belong together. That might actually be one reason why C-like languages add a comma for separating arguments: flatten-operation(op, cdr(lyst)) Now op and cdr are clearly separated. But here, s-expressions actually seem more readable to me: (flatten-operation op (cdr lyst)) This keeps together what belongs together. In my opinion, nested function calls in C-like function notation generally look worse than as s-expressions. They look really good when going only one level deep, but nested they are strange. > It's pretty common to have several short parameters on a line; > neoteric-expressions are quite useful in this case. A quick grep finds many > examples. > I always use the "car(lyst)" form when it's a call, never the "(car > lyst)" form, so there's no problem of "which format do I use". > Being readable in great part depends on building on what people > already know, and this is the more familiar notation. Besides, > neoteric-expressions are *already* supported in curly-infix. They are supported in SRFI-105, but if I tested it correctly not activated when explicitly activating curly-infix. I agree on the readability, by the way, just not on the tradeoff against simplicity. Best wishes, Arne -- 1w6 sie zu achten, sie alle zu finden, in Spiele zu leiten und sacht zu verbinden. → http://1w6.org
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 Readableemail@example.com https://lists.sourceforge.net/lists/listinfo/readable-discuss