From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Request for feedback on SRFI-126 Date: Thu, 1 Oct 2015 01:39:16 +0200 Message-ID: References: <87zj08t5w1.fsf@T420.taylan> <2004212.koJWAIKy7V@fluss> <1624973.gGP49SRqMa@fluss> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01227ec44d09930520ff7039 X-Trace: ger.gmane.org 1443698691 18653 80.91.229.3 (1 Oct 2015 11:24:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 11:24:51 +0000 (UTC) Cc: "guile-user@gnu.org" , guile-devel To: Arne Babenhauserheide Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Oct 01 13:24:50 2015 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zhbyj-0007kP-93 for guile-user@m.gmane.org; Thu, 01 Oct 2015 13:24:49 +0200 Original-Received: from localhost ([::1]:48435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhbyi-0004lV-LC for guile-user@m.gmane.org; Thu, 01 Oct 2015 07:24:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhQxz-0003kI-Ru for guile-user@gnu.org; Wed, 30 Sep 2015 19:39:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhQxx-0005Qs-Ge for guile-user@gnu.org; Wed, 30 Sep 2015 19:39:19 -0400 Original-Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:37608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhQxx-0005Qh-7F; Wed, 30 Sep 2015 19:39:17 -0400 Original-Received: by wicfx3 with SMTP id fx3so4952171wic.0; Wed, 30 Sep 2015 16:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7kmLUkm0GEX9JhRsEVoj04rkwsMemNEIcsgC9AfZzus=; b=e8YJu263aUHV4UsK6wf4ML7icFOa2Psiewpb7VMEql0I7TZhMOLC5MprL5cQQD/pFE gKrHOg2NrYCYgCLKymjPBqiV9qrR9YwBhOiD/hdVCifpatepgkYR2lLN9QpwH0x2btAP R4RqhhjlWUkoeMUGM9mR/esq69NqnbQAZT/ZJod22ZxJRA4DdApcbrvBnIjrllx1FtR3 m3K9YOJ4DWHdSDyeEAn726iaTHy8OCWYdgTJhbLCmc+mqLdcwpbekNXiTouXdPkF/Ju1 WSe+cdaFo7K7oguTI+Jz2mPtvtPdz0NstYb7iH62evIpJHjZ/rGH2h2SaImMmUehErCB oNmw== X-Received: by 10.194.121.232 with SMTP id ln8mr8434776wjb.76.1443656356396; Wed, 30 Sep 2015 16:39:16 -0700 (PDT) Original-Received: by 10.194.34.35 with HTTP; Wed, 30 Sep 2015 16:39:16 -0700 (PDT) In-Reply-To: <1624973.gGP49SRqMa@fluss> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22e X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12066 gmane.lisp.guile.devel:17883 Archived-At: --089e01227ec44d09930520ff7039 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-10-01 0:16 GMT+02:00 Arne Babenhauserheide : > Am Mittwoch, 30. September 2015, 08:39:44 schrieb Panicz Maciej Godek: > > > > others), then it would be most harmful to the Scheme community, > because > > > > that would increase code enthropy and force programmer to make an > > > > irrelevant choice. > > > > > > It=E2=80=99s no more irrelevant than the choice between Guile and Rac= ket. > > > > No. Guile and Racket are both experiments. I think it was a good move o= n > > Racket's side that they proclaimed that they are a separate programming > > language, because that way they manage to avoid bad community pressures > > like this. > > Do you see wisp as community pressure on Scheme implementations? > I meant this discussion in general. I think that there we either need to treat SRFIs as a sort of a pressure on the community, or the status of a document being SRFI becomes irrelevant. > > And different from that choice, it=E2=80=99s trivial to change: > > > > > > for i in *.w; do guile wisp.scm $i > $(basename $i .w).scm; done > > > Converting strange syntax to Lisp is essentially what parsing does. > > I=E2=80=99ll cheat a bit here and pull your later answer: > > > This is the reason why emacs indents lisp code. This is the part of > > Norvig's comparison that I particularly like: > > > > "One of Python's controversial features, using indentation level rather > > than begin/end or braces, was driven by this philosophy: since there ar= e > no > > braces, there are no style wars over where to put the braces. > > Interestingly, Lisp has exactly the same philosphy on this point: > everyone > > uses emacs to indent their code, so they don't argue over the > indentation. > > Take a Lisp program, indent it properly, and delete the opening parens = at > > the start of lines and their matching close parens, and you end up with > > something that looks rather like a Python program." > > If you do that, you essentially have wisp. Being as close as possible > to Scheme with just leaving out the parens you can infer from > indentation is the core design principle of wisp. > I think it is a slippery slope. You may wish to have lisp, infix curly braces and "sweet-expressions" and suddenly everything gets complicated and no one knows how the code should be written, because there are so many options. > > > Yet you loose a lot of support from your tools if you miss the > assumptions > > that they were made upon. > > That=E2=80=99s completely, totally true. > > Guile itself provides almost its full support when you=E2=80=99re using w= isp, > but the tool support is much weaker. The Emacs mode for wisp is much, > much weaker than Geiser and there are no syntax highlighters in any > code hosting service, and that doesn=E2=80=99t even start with external c= ode > analysis tools. > > But you can already do stuff like this: > http://draketo.de/english/wisp/shakespeare > > :) This surely does look nice :D > > > It also sacrifices some of the strengths of Scheme, actually, because > it > > > > makes the code structure obscure. > > > > > > I disagree on that. The structure is still just as easy to recognize > > > as with parens: > > > > It is easy for you, because you're inveted it. For everyone else it's > just > > another thing they'd need to learn in order to read the code. They'd ne= ed > > to remember all the assumptions you've made. > > Let=E2=80=99s do that by example: > > define : hello world > format #t "Hello ~A!\n" world > > hello "World" > Simple examples are simple. Now tell me how this code would look like in wisp and how would the lack of parenthesis be helpful in its analysis. This is a real-life example copied&pasted from my repository: (define* (setup-pose! #;of rig #;to pose #:key (keeping #f)) (assert (and (pose? pose) (if keeping (body? keeping)))) (with-context-for-joint/body-relation (let ((('pose . parameters) pose)) (for (joint-name . angle) in parameters (when angle (let* ((joint (joint-named joint-name #;from rig)) (mobile-bodies immobile-bodies direction (let ((left right (split-bodies-at joint))) (cond ((and keeping (in? keeping left)) (values right left -1)) ((or (not keeping) (in? keeping right)) (values left right +1)) (else (error))))) (angle* (- angle (joint-property joint 'angle))) (mobile-joints (unique (fold union '() (map joints-attached-to mobile-bodies)))) (axis pivot (values (* direction (joint-property joint 'axis)) (joint-property joint 'anchor)))) (assert (eq? (joint-type joint) 'hinge)) (for body in mobile-bodies (rotate-body! body #;by angle* #;around axis #;at pivot)))))))) Recognizing the structure isn=E2=80=99t the problem. Tool support is a > problem. And integration. And documentation. And so on. It is unlikely > to be the best system for all kinds of hacking. But it might be a > pretty good system for some tasks. And when you program in wisp, going > to standard Scheme is really easy. You already know all the > functionality, the structures, the libraries and so on. > I can't see the gain from using that system. Actually, if we had an editor that could typeset the Scheme code in various ways, everyone could be aesthetically pleased, and that wouldn't need to break the existing code base. > > > The same goal could better be achieved (non-intrusively) by making an > > > easy > > > > to use editor that would allow to display your Scheme code in the > way you > > > > prefer, be it Python-style indentation or some fancy LaTeX > formatting. > > > > > > I consider it as problematic when programming languages need strong > > > tool support to be easy to read. With the right tools, even Java is > > > nice to use. > > > > Raise your hands all those who don't use emacs to write their Lisp code= . > > Raise your hands all those who don't use geiser to interact with Guile. > > > > I honestly think that, however clever Lisp is, it would be rather painf= ul > > to edit it without proper tools. Even the aforementioned 'wisp.scm' is = a > > tool. > > You=E2=80=99re talking about editing right now. I explicitly talked about > reading, not about editing. > Emacs indenting your code is an editing tool support that faciliates reading. Also, I find rainbow parens and hide-show mode helpful when reading the code. I end here, because I need to get going all best --089e01227ec44d09930520ff7039 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2015-10-01 0:16 GMT+02:00 Arne Babenhauserheide <arne_bab@web.de>:
Am Mittwoch, 30. September 2015, = 08:39:44 schrieb Panicz Maciej Godek:
> > > others), then it would be most harmful to the Scheme communi= ty, because
> > > that would increase code enthropy and force programmer to ma= ke an
> > > irrelevant choice.
> >
> > It=E2=80=99s no more irrelevant than the choice between Guile and= Racket.
>
> No. Guile and Racket are both experiments. I think it was a good move = on
> Racket's side that they proclaimed that they are a separate progra= mming
> language, because that way they manage to avoid bad community pressure= s
> like this.

Do you see wisp as community pressure on Scheme implementations?
=

I meant this discussion in general. I thin= k that there we either need to treat SRFIs as a sort of a pressure on the c= ommunity, or the status of a document being SRFI becomes irrelevant.
<= div>
> > And different from that choice, it=E2=80=99s trivial to change: > >
> >=C2=A0 =C2=A0 =C2=A0for i in *.w; do guile wisp.scm $i > $(base= name $i .w).scm; done

> Converting strange syntax to Lisp is essentially what parsing does.
I=E2=80=99ll cheat a bit here and pull your later answer:

> This is the reason why emacs indents lisp code. This is the part of > Norvig's comparison that I particularly like:
>
> "One of Python's controversial features, using indentation le= vel rather
> than begin/end or braces, was driven by this philosophy: since there a= re no
> braces, there are no style wars over where to put the braces.
> Interestingly, Lisp has exactly the same philosphy on this point: ever= yone
> uses emacs to indent their code, so they don't argue over the inde= ntation.
> Take a Lisp program, indent it properly, and delete the opening parens= at
> the start of lines and their matching close parens, and you end up wit= h
> something that looks rather like a Python program."

If you do that, you essentially have wisp. Being as close as possibl= e
to Scheme with just leaving out the parens you can infer from
indentation is the core design principle of wisp.

=
I think it is a slippery slope. You may wish to have lisp, infix= curly braces and "sweet-expressions" and suddenly everything get= s complicated and no one knows how the code should be written, because ther= e are so many options.
=C2=A0

> Yet you loose a lot of support from your tools if you miss the assumpt= ions
> that they were made upon.

That=E2=80=99s completely, totally true.

Guile itself provides almost its full support when you=E2=80=99re using wis= p,
but the tool support is much weaker. The Emacs mode for wisp is much,
much weaker than Geiser and there are no syntax highlighters in any
code hosting service, and that doesn=E2=80=99t even start with external cod= e
analysis tools.

But you can already do stuff like this:
http://draketo.de/english/wisp/shakespeare


:)
T= his surely does look nice :D

> > > It also sacrifices some of the strengths of Scheme, actually= , because it
> > > makes the code structure obscure.
> >
> > I disagree on that. The structure is still just as easy to recogn= ize
> > as with parens:
>
> It is easy for you, because you're inveted it. For everyone else i= t's just
> another thing they'd need to learn in order to read the code. They= 'd need
> to remember all the assumptions you've made.

Let=E2=80=99s do that by example:

define : hello world
=C2=A0 format #t "Hello ~A!\n" world

hello "World"

Simple examples= are simple.
Now tell me how this code would look like in wisp an= d how would the lack of parenthesis be helpful in its analysis. This is a r= eal-life example copied&pasted from my repository:

=
(define* (setup-pose! #;of rig #;to pose #:key (keeping #f))
=C2=A0 (assert (and (pose? pose)
=C2=A0 =C2=A0 =C2=A0 (if keeping (body? keeping))= ))
=C2=A0 (with-context-for-joint/body-relation
=C2=A0 = =C2=A0(let ((('pose . parameters) pose))
=C2=A0 =C2=A0 =C2=A0= (for (joint-name . angle) in parameters
=C2=A0 =C2=A0 =C2=A0 =C2= =A0(when angle
(let* ((joint (joint-named joint-name #;from rig))
(mobile-bodies immobile-bodies dir= ection
=C2= =A0 =C2=A0 =C2=A0 (let ((left right (split-bodies-at joint)))
(cond ((and keeping (in= ? keeping left))
= (values right left -1))
=C2=A0 =C2=A0 =C2=A0 ((or (not keeping) (in? keeping r= ight))
(va= lues left right +1))
= =C2=A0 =C2=A0 =C2=A0 (else
(error)))))
(angle* (- angle (joint-property joint 'angl= e)))
(mobile-= joints (unique (fold union '()
=C2=A0 =C2=A0 (map joints-attached-to
<= span class=3D"" style=3D"white-space:pre"> =C2=A0mobile-bodies= ))))
(axis pi= vot (values (* direction (joint-property joint 'axis))
=C2=A0 =C2=A0(joint-proper= ty joint 'anchor))))
=C2=A0 (assert (eq? (joint-type joint) 'hinge))
<= span class=3D"" style=3D"white-space:pre"> =C2=A0 (for body in mobi= le-bodies
=C2= =A0 =C2=A0 (rotate-body! body #;by angle* #;around axis #;at pivot))))))))<= /div>


Recognizing the structure isn=E2=80=99t the problem. Tool support is a
problem. And integration. And documentation. And so on. It is unlikely
to be the best system for all kinds of hacking. But it might be a
pretty good system for some tasks. And when you program in wisp, going
to standard Scheme is really easy. You already know all the
functionality, the structures, the libraries and so on.

I can't see the gain from using that system. Actually,= if we had an editor that could typeset the Scheme code in various ways, ev= eryone could be aesthetically pleased, and that wouldn't need to break = the existing code base.

> > > The same goal could better be achieved (non-intrusively) by = making an
> > easy
> > > to use editor that would allow to display your Scheme code i= n the way you
> > > prefer, be it Python-style indentation or some fancy LaTeX f= ormatting.
> >
> > I consider it as problematic when programming languages need stro= ng
> > tool support to be easy to read. With the right tools, even Java = is
> > nice to use.
>
> Raise your hands all those who don't use emacs to write their Lisp= code.
> Raise your hands all those who don't use geiser to interact with G= uile.
>
> I honestly think that, however clever Lisp is, it would be rather pain= ful
> to edit it without proper tools. Even the aforementioned 'wisp.scm= ' is a
> tool.

You=E2=80=99re talking about editing right now. I explicitly talked = about
reading, not about editing.

Emacs inden= ting your code is an editing tool support that faciliates reading. Also, I = find rainbow parens and hide-show mode helpful when reading the code.
=

I end here, because I need to get going
all b= est


--089e01227ec44d09930520ff7039--