Re: Wisp as shipped language in Guile?

[Panicz Maciej Godek <godek.maciek@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5602 bytes --]

2017-05-13 3:52 GMT+02:00 Mark H Weaver <mhw@netris.org>:

> Hi Arne,
>
> Arne Babenhauserheide <arne_bab@web.de> writes:
> > A few weeks ago I asked in IRC whether wisp[1] could be included with
> > Guile in modules/language/wisp to allow every guile users to run wisp
> > code from any Guile installation via
> >
> >
> >     $ guile --language=wisp [<file>]
> >
> >
> > Essentially this is about making wisp as language part of the
> > "batteries" of Guile.
>
> About 4.5 years ago, I went out on a limb and added SRFI-105 (curly
> infix expressions) to core Guile.  Even now, I'm of the opinion that
> judicious use of curly infix could be beneficial for readability, but as
> far as I can tell, there's been essentially no uptake.  If I'm wrong
> about that, please let me know.
>
> Although (a subset of) SRFI-105 seems like a clear win to me, I cannot
> say the same of either Wisp or SRFI-110 (Sweet expressions).
>
>
"The idea of introducing Algol-like syntax into Lisp keeps popping up and
has seldom failed to create enormous controversy between those who find the
universal use of S-expressions a technical advantage (and don’t mind the
admitted relative clumsiness of S-expressions for numerical expressions)
and those who are certain that algebraic syntax is more concise, more
convenient, or even more natural (whatever that may mean, considering that
all these notations are artificial).

We conjecture that Algol-style syntax has not really caught on in the Lisp
community as a whole for two reasons. First, there are not enough special
symbols to go around. When your domain of discourse is limited to numbers
or characters, there are only so many operations of interest, and it is not
difficult to assign one special character to each and be done with it. But
Lisp has a much richer domain of discourse, and a Lisp programmer often
approaches an application as yet another exercise in language design; the
style typically involves designing new data structures and new functions to
operate on them—perhaps dozens or hundreds—and it’s just too hard to invent
that many distinct symbols (though the APL community certainly has tried).
Ultimately one must always fall back on a general function-call notation;
it’s just that Lisp programmers don’t wait until they fail.

Second, and perhaps more important, Algol-style syntax makes programs look
less like the data structures used to represent them. In a culture where
the ability to manipulate representations of programs is a central
paradigm, a notation that distances the appearance of a program from the
appearance of its representation as data is not likely to be warmly
received (and this was, and is, one of the principal objections to the
inclusion of loop in Common Lisp).

On the other hand, precisely because Lisp makes it easy to play with
program representations, it is always easy for the novice to experiment
with alternative notations.  Therefore we expect future generations of Lisp
programmers to continue to reinvent Algol-style syntax for Lisp, over and
over and over again, and we are equally confident that they will continue,
after an initial period
of infatuation, to reject it. (Perhaps this process should be regarded as a
rite of passage for Lisp hackers.)"

Guy L. Steele, Jr. and Richard P. Gabriel, "The Evolution of Lisp"

My personal opinion is that adding new ways for expressing the same thing
that can already be expressed in the language is a bad thing, because it
only increases the entropy of your code base.

When it comes to readability, I don't think that we need to make the reader
syntax more complex. What we need is an editor with a good typesetting
feature, so that various programmers could use the formatting of their
liking (say, making their code look more like Haskell or more like Julia or
some other mathematical idols like Mathematica) without making any invasive
changes to the code base.

When it comes to curly infix, I don't think that it really is an advantage
for arithmetic expressions. But I do agree that infix expressions are
actually clarifying in the case of asymmetrical binary relations: x < y is
a bit more obvious than (< x y). However, this can be achieved using
regular Scheme syntax, say, with the following macros:

(define-syntax infix (syntax-rules ()
  ((_ x related-to? y)
   (related-to? x y))
  ((_ x related-to? y . likewise)
   (and (infix x related-to? y)
    (infix y . likewise)))))

(define-syntax is (syntax-rules (_)
  ((is _ related-to? right . likewise)
   (lambda (_)
     (infix _ related-to? right . likewise)))

  ((is left related-to? _ . likewise)
   (lambda (_)
     (infix left related-to? _ . likewise)))

  ((is x related-to? y . likewise)
   (infix x related-to? y . likewise))

  ((is x) ;; thanks to Arne's earlier suggestions
   (lambda (y)
     (equal? x y)))

  ((is left relation) ;; same as "(is left relation _)"
   (lambda (right)
     (relation left right)))))

Perhaps the "is" macro allows more than it should, and "infix" should just
be renamed to "is", to allow usages like

(remove (is _ < 5) list) or (filter (is 5 >=) list) or (filter (is 5 >= _)
list)

but I'm convinced that, say

(is x divisible-by? y)

is more obvious to read than

(divisible-by? x y) or (divides? x y)

and (is x < y <= z) is more concise than (and (< x y) (<= y z)).

[On the other hand, I don't think that there's any advantage of (is x = y)
to (= x y), because the roles of x and y here are identical]

[-- Attachment #2: Type: text/html, Size: 6743 bytes --]