On Thu, Apr 30, 2020 at 02:40:00PM -0700, Sorawee Porncharoenwase wrote:
> >
> > I hate being at the mercy of whatever editor I'm stuck using.
>
>
> I agree with this in principle, but in practice, it's really a matter of
> what mainstream editors support. Editors in the past don't universally
> support automatic indentation, and I could imagine a criticism like
> "Indentation sucks, because I hate being at the mercy of whatever editor
> I'm stuck using." But now, automatic indentation is universal, and the
> criticism goes away.
>
>
> > I stongly recommend that we get a language with less of a
> > parenthesis problem so that code is readable without having to haul
> > it into a specialised editor.
> >
>
> Personally, I don't find parenthesis makes code unreadable by itself. The
> rightward drift, in my opinion, is the real problem. I believe that
> `define*` that I proposed at
> https://github.com/racket/rhombus-brainstorming/issues/46 will somewhat
> mitigate the problem.
Yes, rightward drift is one of the problems. That's why I introduced '/'
in a Lispish language I implemented decades ago.
>
> In an old List I used '/' for this, so i got expressions like
> > (if a b / if c d / let s t /if s foo bar)
If course this is a different let from the traditional, age-old one.
> >
>
> Using `/` to reduce parentheses looks nice once it's written down, but my
> concern is that it might not be easily editable. In fact, it ironically
> looks like this notation needs an extra support from editors to consider
> `/` as a delimiter.
Yes, of course. Whatever you use has to be ecognised as a delimiter.
>
> To clarify what I mean: non S-exp languages usually have a line as a unit
> of code, so editors need to support "jump to the beginning/end of line" to
> make editing pleasant. S-exp languages in contrast has a parenthesized
> expression as a unit of code, so editors need to support "jump to a
> matching parenthesis" to make editing pleasant. In your notation, it looks
> like editors need to also support "jump to closest /" to make editing
> pleasant.
In practise, you get things like
( if a (cadr foo)
/ if c
(d u / v w)
/ let s t
/ if s foo bar
)
>
> Also, does it actually make code more readable? I guess I'm not accustomed
> to it, and might find it easier to read it once I am.
I foud it so. Especially for large, complicared expressions involving
intermixed let's and if's.
Of course, I also adapted mu Lisp to make better advantage if the "/" syntax.
multiple let's just become tail-nested let's, without rightward drift.
(let a b
/let c a
/let e (f c)
/big expression incolving these
)
>
>
> > There must be some # code we could use for this (I believe one
> > has already been mentioned on this list sometime in the past year
> > os so) but this symbol tends to become *so* prevalent that it
> > should ideally feel like a single character with a dostinctieve
> > apearance.
> >
>
> This is Nia's parendown: https://docs.racket-lang.org/parendown/index.html
That is lovely.
-- hendrik
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/20200501014133.hoyw2pksi4lpkebz%40topoi.pooq.com.
