On Thu, Apr 30, 2020 at 09:36:15AM +0200, Dexter Lagan wrote: > There’s one thing I noticed: if debugging is disabled, then parenthesis > highlighting is also disabled (as well as other visual aids, if I remember > well?). The editor also feels faster because of this, but navigating > parentheses becomes slightly more tedious without it.
And that's exactly the parenthesis problem. For a language as parenthesis-heavy as Scheme or Lisp, you need a parenthesis-oriented editor. DrRacket does this very well bu shading the background (but apparently not all the time). Emacs does it too, in principle, but isn't reaally great at it. I hate being at the mercy of whatever editor I'm stuck using. 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. It is possible to do this without creating a hugely complicated and unintuitive syntax for the language! We don't need to savage the language to accomplish this! One thing that greatly mitigates parentheses without affecting the semantic of the language or the syntax (much) is the equivalent of tail-recursion for parenthesis nesting. It the last component of a list is itself a list, instead of enclosing it in parentheses, you just put a prefix in front it it. 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) Let no longer needs its heavy bracket structure because it's easy to chain let's without parenthesis nesting. Wimilaarly, cond itself become unnecessry, and it's easy to chain ifs, lets, and so forth. Of course '/' is already taken in Racket; as is the also natural ';'. 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. Actual parentheses becoma *startlingly* sparser. And language constructions whose primary purpose seems to be to avoid nesting become mostly unnecessary. (Still stuck with letrec though) -- hendrik > > Dex > > > On Apr 25, 2020, at 3:25 PM, sleepnova <wanpee...@gmail.com> wrote: > > > > > > That may help to reduce misimpression. And plus, maybe append some message > > to error message to inform user that they can turn on errortrace if they > > need more detailed debugging information, when errortrace doesn't enabled. > > > > To be clarify, what you mentioned is "Preserve errortrace" option, what > > about "Debugging" option, is it a must enabled option in a non-debugging > > run? > > > > <截圖 2020-04-25 下午9.22.20.png> > > > > > > Sorawee Porncharoenwase <sorawee.pw...@gmail.com> 於 2020年4月25日 週六 下午8:17寫道： > >> It could go either way, no? I've also heard a lot of people complaining > >> that debugging Racket programs is difficult because the stack trace is not > >> useful, and this is because they use the command-line version which > >> doesn't have errortrace enabled (by default). > >> > >> Perhaps what you really are complaining is that the option to > >> enable/disable errortrace is not easily discoverable. Would it help if at: > >> > >> <Screen Shot 2020-04-25 at 05.11.29.png> > >> > >> > >> the text is changed from `racket, with debugging` to `racket, with > >> debugging (slower)`. And the texts are linkified so that when `racket` is > >> clicked, it leads you to the non-detailed language setting, and when `with > >> debugging (slower)` is clicked, it leads you to the detailed language > >> setting? > >> > >> On Sat, Apr 25, 2020 at 3:51 AM Liwei Chou <wanpee...@gmail.com> wrote: > >>> Thanks Dexter, > >>> > >>> Yes, now I know it’s due to the debugging and tracing configuration. > >>> After turn off debugging and profiling, it becomes. > >>> > >>> cpu time: 20 real time: 20 gc time: 0 > >>> > >>> If disable Preserve stacktrace also, I got. > >>> > >>> cpu time: 7 real time: 7 gc time: 0 > >>> > >>> Which is pretty decent, 16x acceleration. > >>> > >>> It's not a problem for me now. However, this behavior may give some new > >>> users the wrong impression that the language may not be very efficient, > >>> which may make some people choose not to continue trying it. > >>> > >>> From the perspective of increasing adoption and reducing barriers, it's > >>> not a good thing. > >>> > >>> If Racket team can consider making normal run and debug run using > >>> different default settings, which conventional development environments > >>> usually do, that can easily solve this problem. > >>> > >>> Dexter Lagan於 2020年4月25日星期六 UTC+8下午5時17分31秒寫道： > >>>> > >>>> Hi Liwei, > >>>> > >>>> I believe disabling debugging and tracing does accelerate the > >>>> evaluation quite a bit from inside DrRacket. On my system, it seems to > >>>> be running my code at the same speed as the main racket binary. > >>>> > >>>> Dex > >>> > >>> -- > >>> 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/cb5e4fa5-2766-4242-aff5-8933bee637c6%40googlegroups.com. > > > > > > -- > > - 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-7O1cv_sOrGRWxoHetdwDLiKLSOpZdt8T3YPj4yQQome7w%40mail.gmail.com. > > -- > 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/71148F23-E424-4580-8CAB-DC40AA0B5D47%40gmail.com. -- 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/20200430151610.h7brabph4uk2bp4v%40topoi.pooq.com.
