Re: [Readable-discuss] wisp and readable - common expressions
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
Re: [Readable-discuss] wisp and readable - common expressions
Am Freitag, 21. November 2014, 18:48:16 schrieb David A. Wheeler: > It is obviously possible to change the semantics of leading period. > I am hesitant to add yet another operator; you may disagree but I > really tried to make it a short list. I know you did. Every single additional operator came from a structure you found in code which wasn’t represented elegantly enough in sweet. I decided to forgo that goal and instead assume that the coding style will adapt to some degree to the language as long as the technically necessary features as well as 90% of the general cases are represented elegantly. Since the leading period is already almost part of the syntax, it might have a much lower conceptual cost than other operators. That’s why I chose it for that, after all ☺ > I also really wanted to fix the notation, but leading period is > basically never used so that is probably not really a problem. > > Let me think about it. Happily :) 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
Re: [Readable-discuss] wisp and readable - common expressions
David A. Wheeler:
> > If wisp interpreted neoteric-expressions by default,
> > then many more expressions work in both systems...
On Fri, 21 Nov 2014 22:38:13 +0100, Arne Babenhauserheide
wrote:
> That’s true, but then lines with a single element would be treated
> differently than lines with multiple elements, and that is a gotcha I want to
> avoid.
As I've commented before, I think the wisp rule *seems* simpler ("each line is
new list"),
but in practice it is *itself* a gotcha, because it leads to bizarre behavior
like this.
Which is why both SRFI-49 and sweet-expressions don't do it.
But suspending that old discussion, let's focus on the example you mentioned...
> It hits you with things like newline
> 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.
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))
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.
You *can* do it using traditional s-expression notation, of course:
cons (car lyst) (flatten-operation op (cdr lyst))
However, I think the former is more readable. In particular,
the "car(lyst)" format is the same as mathematics and nearly all other
programming languages, making it much more familiar. 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.
--- David A. Wheeler
--
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
Re: [Readable-discuss] wisp and readable - common expressions
It is obviously possible to change the semantics of leading period. I am
hesitant to add yet another operator; you may disagree but I really tried to
make it a short list. I also really wanted to fix the notation, but leading
period is basically never used so that is probably not really a problem.
Let me think about it.
On November 21, 2014 4:38:13 PM EST, Arne Babenhauserheide
wrote:
>Am Mittwoch, 19. November 2014, 18:34:25 schrieb David A. Wheeler:
>> It's possible to write code that is interpreted *identically*
>> on both wisp and sweet when indentation is enabled.
>
>That’s cool!
>
>> In sweet, a "." at the
>> beginning of a line post-indent is basically ignored.
>
>Would it be possible to generalize this, so sweet would also make the
>full line a continuation instead of only ignoring the dot?
>
>That would make many uses of \\ unnecessary, and wisp would then be
>almost a subset of sweet.
>
>> Thus, in both sweet and wisp:
>> a b c
>> d e
>> . f
>> g h
>> becomes:
>> (a b c
>> (d e)
>> f
>> (g h))
>
>> If wisp interpreted neoteric-expressions by default,
>> then many more expressions work in both systems, e.g.:
>> defun factorial()
>> if {n <= 1}
>> . 1
>> {n * factorial{n - 1}}
>
>That’s true, but then lines with a single element would be treated
>differently than lines with multiple elements, and that is a gotcha I
>want to avoid.
>
>It hits you with things like newline
>
>wisp:
>define : hello
> display "Hello World!"
> newline
>define : hello2 who
> format #t "Hello ~A!\n" who
>hello2 "wisp"
>
>sweet:
>define hello()
> display "Hello World!"
> newline()
>hello()
>define hello(who)
> format #t "Hello ~A!\n" who
>hello2 "sweet"
>; or
>hello2("sweet")
>
>> So while neoteric-expressions provide two ways to write something,
>> in practice, there's a "more readable" way that better expresses the
>purpose
>> in each case.
>
>It’s almost as if you had intentionally motivated a quote I found
>yesterday but didn’t share because I didn’t know whether it would come
>off as offensive. With that kind of (unintentional?) prep-work:
>
>
> wisp-expressions are not as sweet as readable, but they KISS.
>
>
>:-)
>
>Best wishes,
>Arne
--- David A.Wheeler--
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
Re: [Readable-discuss] wisp and readable - common expressions
Am Mittwoch, 19. November 2014, 18:34:25 schrieb David A. Wheeler:
> It's possible to write code that is interpreted *identically*
> on both wisp and sweet when indentation is enabled.
That’s cool!
> In sweet, a "." at the
> beginning of a line post-indent is basically ignored.
Would it be possible to generalize this, so sweet would also make the
full line a continuation instead of only ignoring the dot?
That would make many uses of \\ unnecessary, and wisp would then be
almost a subset of sweet.
> Thus, in both sweet and wisp:
> a b c
> d e
> . f
> g h
> becomes:
> (a b c
> (d e)
> f
> (g h))
> If wisp interpreted neoteric-expressions by default,
> then many more expressions work in both systems, e.g.:
> defun factorial()
> if {n <= 1}
> . 1
> {n * factorial{n - 1}}
That’s true, but then lines with a single element would be treated
differently than lines with multiple elements, and that is a gotcha I
want to avoid.
It hits you with things like newline
wisp:
define : hello
display "Hello World!"
newline
define : hello2 who
format #t "Hello ~A!\n" who
hello2 "wisp"
sweet:
define hello()
display "Hello World!"
newline()
hello()
define hello(who)
format #t "Hello ~A!\n" who
hello2 "sweet"
; or
hello2("sweet")
> So while neoteric-expressions provide two ways to write something,
> in practice, there's a "more readable" way that better expresses the purpose
> in each case.
It’s almost as if you had intentionally motivated a quote I found
yesterday but didn’t share because I didn’t know whether it would come
off as offensive. With that kind of (unintentional?) prep-work:
wisp-expressions are not as sweet as readable, but they KISS.
:-)
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
[Readable-discuss] wisp and readable - common expressions
BTW,
It's possible to write code that is interpreted *identically*
on both wisp and sweet when indentation is enabled. In sweet, a "." at the
beginning of a line post-indent is basically ignored. This was for consistency
with neoteric-expressions, and left there in part to be consistent with sweet.
In wisp, a leading "." is NECESSARY to disable automatic list-wrapping.
So if you begin any line with "." if it has a single element, and avoid the
additional markers like ":", "$", "\\", and <*...*>, they're identical.
Thus, in both sweet and wisp:
a b c
d e
. f
g h
becomes:
(a b c
(d e)
f
(g h))
Of course, once you open a list (...) and format it normally,
or start a curly-infix-expression {...}, they are identical.
If wisp interpreted neoteric-expressions by default,
then many more expressions work in both systems, e.g.:
defun factorial()
if {n <= 1}
. 1
{n * factorial{n - 1}}
In general I find that if the first element is a symbol, I normally
write it using f(...), e.g., cos(). That is ALWAYS true if it's
a procedure I'm calling. However, if the first element is not a symbol,
e.g., a number, then I write a normal list, e.g., '(1 2 3).
The pretty-printer exploits this; if something is a symbol, and the list
is not too long (e.g., 16 items or so), it's presented in f(...) format.
So while neoteric-expressions provide two ways to write something,
in practice, there's a "more readable" way that better expresses the purpose
in each case.
--- David A. Wheeler
--
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
