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,
1w6 sie zu achten,
sie alle zu finden,
in Spiele zu leiten
und sacht zu verbinden.

Attachment: 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
Readable-discuss mailing list

Reply via email to