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,

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