Re: Request for feedback on SRFI-126

[Panicz Maciej Godek]

2015-10-01 0:16 GMT+02:00 Arne Babenhauserheide <address@hidden>:

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’s 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 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’s 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’ll 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 are 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’s completely, totally true.

Guile itself provides almost its full support when you’re using wisp,
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’t even start with external code
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 need
> to remember all the assumptions you've made.

Let’s 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’t 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 painful
> to edit it without proper tools. Even the aforementioned 'wisp.scm' is a
> tool.

You’re 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