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
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
