Re: Wisp as shipped language in Guile?

[Panicz Maciej Godek]

2017-05-13 3:52 GMT+02:00 Mark H Weaver <address@hidden>:

Hi Arne,

Arne Babenhauserheide <address@hidden> 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]