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?

> > 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.

> 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

> > > 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"

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.

> > > 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.