Thanks for sharing. I see "Nested parentheses" only one way to represent
tree structure. There are certainly other cleverer ways to do it. Once it
appears, the representation of the tree transform (macro) may also be
better. I'm looking forward to seeing better representation.
https://en.wikipedia.org/wiki/Tree_structure#Nested_parentheses

Sorawee Porncharoenwase <sorawee.pw...@gmail.com> 於 2020年5月1日 週五 上午5:40寫道:

> 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.
>
> 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)
>>
>
> 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.
>
> 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.
>
> 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.
>
>
>> 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
>
>
> --
> 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/CADcuegsYr6KKeZg5sV1ocgcywnCTbi8rf_gB5_MiQG9%3D_W_cFQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/racket-users/CADcuegsYr6KKeZg5sV1ocgcywnCTbi8rf_gB5_MiQG9%3D_W_cFQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
- sleepnova
呼叫小黃創辦人 & CEO

-- 
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/CABa2-7OwuDSkXca3Of86E0uKoNgCUUCSE01S1k%3Dx1JZ80EHiXw%40mail.gmail.com.

Reply via email to