From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.devel Subject: Re: Wisp as shipped language in Guile? Date: Sat, 13 May 2017 09:24:56 +0200 Message-ID: References: <87h90wz8rg.fsf@web.de> <87o9uxfrpt.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045c0b5c179438054f62b8e9" X-Trace: blaine.gmane.org 1494660322 19465 195.159.176.226 (13 May 2017 07:25:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 13 May 2017 07:25:22 +0000 (UTC) Cc: Arne Babenhauserheide , Guile Devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat May 13 09:25:09 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d9RQG-0004hp-55 for guile-devel@m.gmane.org; Sat, 13 May 2017 09:25:04 +0200 Original-Received: from localhost ([::1]:56548 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d9RQL-0002C7-NM for guile-devel@m.gmane.org; Sat, 13 May 2017 03:25:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d9RQE-0002AI-5R for guile-devel@gnu.org; Sat, 13 May 2017 03:25:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d9RQC-0003cB-Ar for guile-devel@gnu.org; Sat, 13 May 2017 03:25:02 -0400 Original-Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:35336) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d9RQC-0003bl-03 for guile-devel@gnu.org; Sat, 13 May 2017 03:25:00 -0400 Original-Received: by mail-wm0-x235.google.com with SMTP id b84so37640701wmh.0 for ; Sat, 13 May 2017 00:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0IXpGgga2wUlyrb7+8+URI5xrij4CQdgfcju0/siqpk=; b=i5Pj65La4i3N308jMyk/uZ6W7xMBc4kweyO5XefInNwcr1G22emX5fFv4v3XqvWPaL YCQAA2WmHDTkFiPyNan0qRbYPEuTX2KaRFSCABXkh12m9jnfdU2ZkF2YXgivr2/q4fz+ 11jtA6AWc8Q2rPCq7WstmRiOfYjSolh2hT7g5Q+KV9a9wqUlgxG9IqUy2fvxV3DtWvj2 kTaNfA/cKcdxy81QFGyhhsNBEQRcwYp3MBIV07731fdaTkEoGmCHCupUbhITTk8KJfzz P9L9k8BMr+3/NhBnaIQHiUPbXxU4D7NAXwuGrq2uzXzlJQO6M70p1XM6nu6Ftq1XpSZm pzKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0IXpGgga2wUlyrb7+8+URI5xrij4CQdgfcju0/siqpk=; b=Atg3FLWZw+Hnjk2SA3I7CkaREWJWB3EKqrnPXTDfnJ2hYunutxH3cM9p8UcSUFmrYl Zer/O7QLyC2mt8T5cxneSuflmIYwuH/iNrz+0n8HRdLJZfsycyjwDfBkamP4CdCNT9Qf 1/WQGNI9H8ov0yN4AiPRM2Id4+iE2C5HF8+0WeCjgYQE4vTOcHyqtZLlkyTBovyqyAkq 9tbhIp2rovCRYa41xosqzq2GVI7sOvC9+9OSZ61eEsGNZ/l4ltdUZWQOthTLbM40unY2 qdvL4BecywJMvSVFwJh1nm1RQL+ruDb4fADJ7XyL3lTKlMXcS5Kthc0T1XbZt67iTDTM Nbjg== X-Gm-Message-State: AODbwcDGjZzCoJTw6piTC3CBTpWrUI1gBwL2m/2K5HGbaMvbqBqlFlyn kVpiwokm05Zyd+2fR4SxCQy9KKdRcQ== X-Received: by 10.80.148.194 with SMTP id t2mr6593694eda.128.1494660297494; Sat, 13 May 2017 00:24:57 -0700 (PDT) Original-Received: by 10.80.138.150 with HTTP; Sat, 13 May 2017 00:24:56 -0700 (PDT) In-Reply-To: <87o9uxfrpt.fsf@netris.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::235 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19142 Archived-At: --f403045c0b5c179438054f62b8e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2017-05-13 3:52 GMT+02:00 Mark H Weaver : > Hi Arne, > > Arne Babenhauserheide 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=3Dwisp [] > > > > > > 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=E2=80=99t min= d 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=E2=80=94perhaps dozens or hundreds=E2=80=94and it=E2=80=99s= 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=E2=80=99s just that Lisp programmers don=E2=80=99t 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 >=3D) list) or (filter (is 5 >=3D= _) 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 <=3D z) is more concise than (and (< x y) (<=3D y z)). [On the other hand, I don't think that there's any advantage of (is x =3D y= ) to (=3D x y), because the roles of x and y here are identical] --f403045c0b5c179438054f62b8e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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

Arne Babenhauserheide <arne_bab@web.d= e> writes:
> A few weeks ago I asked in IRC whether wisp[1] could be included with<= br> > Guile in modules/language/wisp to allow every guile users to run wisp<= br> > code from any Guile installation via
>
>
>=C2=A0 =C2=A0 =C2=A0$ guile --language=3Dwisp [<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<= br> infix expressions) to core Guile.=C2=A0 Even now, I'm of the opinion th= at
judicious use of curly infix could be beneficial for readability, but as far as I can tell, there's been essentially no uptake.=C2=A0 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 advan= tage (and don=E2=80=99t mind the admitted relative clumsiness of S-expressi= ons for numerical expressions) and those who are certain that algebraic syn= tax is more concise, more convenient, or even more natural (whatever that m= ay mean, considering that all these notations are artificial).

We co= njecture that Algol-style syntax has not really caught on in the Lisp commu= nity as a whole for two reasons. First, there are not enough special symbol= s to go around. When your domain of discourse is limited to numbers or char= acters, there are only so many operations of interest, and it is not diffic= ult to assign one special character to each and be done with it. But Lisp h= as a much richer domain of discourse, and a Lisp programmer often approache= s an application as yet another exercise in language design; the style typi= cally involves designing new data structures and new functions to operate o= n them=E2=80=94perhaps dozens or hundreds=E2=80=94and it=E2=80=99s just too= hard to invent that many distinct symbols (though the APL community certai= nly has tried). Ultimately one must always fall back on a general function-= call notation; it=E2=80=99s just that Lisp programmers don=E2=80=99t wait u= ntil they fail.

Second, and perhaps more important, Algol-style synt= ax 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 progra= m from the appearance of its representation as data is not likely to be war= mly received (and this was, and is, one of the principal objections to the = inclusion of loop in Common Lisp).

On the other hand, precisely beca= use Lisp makes it easy to play with program representations, it is always e= asy for the novice to experiment with alternative notations.=C2=A0 Therefor= e 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 equal= ly confident that they will continue, after an initial period
of infatua= tion, to reject it. (Perhaps this process should be regarded as a rite of p= assage for Lisp hackers.)"

Guy= L. Steele, Jr. and Richard P. Gabriel, "The Evolution of Lisp"
My personal opinion is that adding n= ew 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. Wh= at we need is an editor with a good typesetting feature, so that various pr= ogrammers 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= 9;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 asym= metrical binary relations: x < y is a bit more obvious than (< x y). = However, this can be achieved using regular Scheme syntax, say, with the fo= llowing macros:

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

(define-syntax is (syntax-rule= s (_)
=C2=A0 ((is _ related-to? right . likewise)
=C2=A0=C2=A0 (lambd= a (_)
=C2=A0=C2=A0=C2=A0=C2=A0 (infix _ related-to? right . likewise)))<= br>=C2=A0
=C2=A0 ((is left related-to? _ . likewise)
=C2=A0=C2=A0 (l= ambda (_)
=C2=A0=C2=A0=C2=A0=C2=A0 (infix left related-to? _ . likewise)= ))
=C2=A0
=C2=A0 ((is x related-to? y . likewise)
=C2=A0=C2=A0 (i= nfix x related-to? y . likewise))

=C2=A0 ((is x) ;; thanks to Arne&#= 39;s earlier suggestions
=C2=A0=C2=A0 (lambda (y)
=C2=A0=C2=A0=C2=A0= =C2=A0 (equal? x y)))

=C2=A0 ((is left relation) ;; same as "(i= s left relation _)"
=C2=A0=C2=A0 (lambda (right)
=C2=A0=C2=A0=C2= =A0=C2=A0 (relation left right)))))

Perhaps the "is" macro allows more than it should, and "inf= ix" should just be renamed to "is", to allow usages like
=
(remove (is _ < 5) list) or (filter= (is 5 >=3D) list) or (filter (is 5 >=3D _) 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 <=3D z) is more concise than (and (< x y) (<= =3D y z)).

[On the other hand, I don't think that there's any advanta= ge of (is x =3D y) to (=3D x y), because the roles of x and y here are iden= tical]

--f403045c0b5c179438054f62b8e9--