Re: [racket-users] Reducing parentheses without language damage.

[David Storrs]

On Thu, Apr 30, 2020 at 11:16 AM Hendrik Boom 
wrote:

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

Not to minimize your experience but I'm speaking up simply as a
counterpoint:  I haven't had this issue, even without Racket's equivalence
between () [] and {}.

Also is there a programming editor that *won't* do parenthesis matching?

-- 
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/CAE8gKof3QdacuH1XoK8QftQnpVfFYWUuon0-Z%2B7oLq3JiPgx-g%40mail.gmail.com.

Re: [racket-users] on reducing barriers in the Racket community

[Sorawee Porncharoenwase]

I have debugging disabled, but my parenthesis highlighting is NOT disabled.
Are we talking about the same parenthesis highlighting? Can you attach the
screenshot of this "parenthesis highlighting is also disabled" to the
mailing list?

On Thu, Apr 30, 2020 at 12:36 AM 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.
>
> Dex
>
> On Apr 25, 2020, at 3:25 PM, sleepnova  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  於 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:
>>
>> 
>>
>>
>> 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  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/CADcuegvn3vdkPLqh1fF_UXD1tiuqdytp_cFLhLqmroTo%3DobZqA%40mail.gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[Hendrik Boom]

On Thu, Apr 30, 2020 at 02:46:00PM -0400, David Storrs wrote:
> On Thu, Apr 30, 2020 at 11:16 AM Hendrik Boom 
> wrote:
> 
> > 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.
> >
> 
> Not to minimize your experience but I'm speaking up simply as a
> counterpoint:  I haven't had this issue, even without Racket's equivalence
> between () [] and {}.
> 
> Also is there a programming editor that *won't* do parenthesis matching?

Evidently the Racket editor whan debugging is disabled, if  
understand Dexter Lagan correctly.

-- 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/20200430190125.4eibezfdyp3dcuds%40topoi.pooq.com.

Re: [racket-users] Re: contributing fixes to documentation

[Stephen De Gabrielle]

I think there are tiny bits of documentation that are automatically
generated(OpenGL?), but I think they are well labeled.

In general its not a problem, its mostly typed in by humans, typos and all.

s.

On Thu, Apr 30, 2020 at 2:16 PM Dexter Lagan  wrote:

>   Thanks, this guide is great. I'll make sure I fix whatever problem I
> find when I scour the docs. I do have a question however: say I find a typo
> in a function definition, is there any part of the doc that is
> automatically generated, and should not be updated, or updated with
> specific attention?
>
> Dex
>
> On Thu, Apr 30, 2020 at 11:55 AM Stephen De Gabrielle <
> spdegabrie...@gmail.com> wrote:
>
>> I'd forgotten the tutorial to contributing - someone kindly reminded me
>> recently
>> https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html
>>
>> This covers everything from fixing a typo to contributing to the racket
>> language and the main distribution.
>>
>> it is worth the read!
>>
>> S
>>
>> On Thursday, April 30, 2020 at 10:49:33 AM UTC+1, Stephen De Gabrielle
>> wrote:
>>>
>>> Yo Racketeers!
>>>
>>> Someone recently mentioned that is was tricky to update documentation.
>>> it can be.
>>> I thought I'd provide the steps I took to create a PR for the DrRacket
>>> documentation in the hope that they are useful for others who see an issue
>>> with documentation but finding locating the right scribble file a problem.
>>>
>>> In my case I wanted to create a PR to update the 'Extending DrRacket'
>>> part of the DrRacket manual.
>>>
>>> My steps were
>>> 1. click on the header of the heading in the manual, it opens up with a
>>> little link on how to link to that section note the path:
>>> scribblings/drracket/drracket.scrbl
>>> Link to this section with
>>>  @secref["extending-drracket"
>>>  #:doc '(lib "scribblings/drracket/drracket.scrbl")]
>>>
>>> 2.  go to the DrRacket repo and look for something matching that path.
>>> It was buried a little but I found it at
>>> https://github.com/racket/drracket/blob/master/drracket/scribblings/drracket/drracket.scrbl
>>>
>>> 3. this scribble file is a list of includes, but I was able to match
>>> https://docs.racket-lang.org/drracket/extending-drracket.html
>>> with
>>> @include-section["extending.scrbl"]
>>>
>>> 4. opening extending.scrbl I find the section I want to change
>>>
>>> https://github.com/racket/drracket/blob/master/drracket/scribblings/drracket/extending.scrbl
>>>
>>> #lang scribble/doc
>>> @(require "common.rkt"
>>> (for-label compiler/cm setup/parallel-build racket/promise))
>>> @(define racodoc '(lib "scribblings/raco/raco.scrbl"))
>>> @title[#:tag "extending-drracket"]{Extending DrRacket}
>>> DrRacket supports two forms of extension to the programming
>>> environment:
>>> @itemize[
>>> (gmail formatted this weirdly)
>>>
>>> 5. For simple changes (e.g. typos) you can just list in place and create
>>> a PR
>>>  - for more complex changes you will need to fork the repo and rebuild
>>> the scribble to ensure it works before submitting the PR. e.g
>>> https://github.com/racket/drracket/pull/372
>>>
>>> 6. if you run into trouble ask here on racket-users, or on the Racket
>>> slack - there are many helpful racketeers out there.
>>>
>>> Kind regards
>>>
>>> Stephen
>>>
>>>
>>> --
>> 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/9e7438ef-0a7d-4660-a5ba-c2bb41928a3c%40googlegroups.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/CAGHj7-%2BCWZn6VjCVuNPkw1-94Wq%2BzLczc4GVHySrPRJ-2r2WKQ%40mail.gmail.com.

Re: [racket-users] on reducing barriers in the Racket community

[Dexter Lagan]

  I put my foot in my mouth again, it's working. I must have had something
else disabled. I clearly remember not being able to make the cursor 'jump'
around expressions.

Dex

On Thu, Apr 30, 2020 at 9:16 PM Sorawee Porncharoenwase <
sorawee.pw...@gmail.com> wrote:

> I have debugging disabled, but my parenthesis highlighting is NOT
> disabled. Are we talking about the same parenthesis highlighting? Can you
> attach the screenshot of this "parenthesis highlighting is also disabled"
> to the mailing list?
>
> On Thu, Apr 30, 2020 at 12:36 AM 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.
>>
>> Dex
>>
>> On Apr 25, 2020, at 3:25 PM, sleepnova  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  於 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:
>>>
>>> 
>>>
>>>
>>> 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  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 

Re: [racket-users] Rhombus project plan

[Laurent]

Also, if I remember correctly, the timings given in the said (excellent)
tutorial are very conservative or outdated. If you have a multicore
machine, it will speed up the process by up to a factor 8.

On Thu, Apr 30, 2020, 15:42 Sam Tobin-Hochstadt 
wrote:

> On Thu, Apr 30, 2020 at 9:09 AM Ben Greenman
>  wrote:
> >
> > On 4/29/20, Sorawee Porncharoenwase  wrote:
> > > (Not directly related to Rhombus) Speaking of “how to contribute”, I
> find
> > > that it is not friendly at all to setup stuff in order to contribute to
> > > Racket core and main distribution. According to
> > >
> https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html,
> > > if I want to make a change to, say, https://github.com/racket/math, I
> > > should start with:
> > >
> > > $ raco pkg update --no-setup --catalog https://pkgs.racket-lang.org
> math
> > > $ raco pkg update --clone math
> > >
> > > The estimated time to run the above two commands is ONE HOUR! The
> second
> > > command in particular seems to compile every Racket packages (why does
> it
> > > need to do that?!?) which takes a lot of time.
> >
> > That second command recompiles only the packages that depend on math.
> > Unfortunately there are a lot of them.
>
> To follow up on that, here are some strategies for reducing that time:
>
> 1. Start with Minimal Racket, install "math", then follow the steps
> above. That will just rebuild `math`, not everything that depends on
> it, since they won't be installed.
>
> 2. (Dangerous) Do the following:
>$ raco pkg update --no-setup --clone math # fast
>$ raco setup math
>
> This will only setup "math", and thus be faster, but will potentially
> cause other parts of the installation to not work correctly until you
> run "raco setup".
>
> Making the original commands go faster would require one of three
> things (in increasing order of difficulty): detecting that many zo
> files can be re-used from the previous installation in some fashion,
> making Typed Racket faster, or making Racket macro expansion more
> incremental.
>
> Sam
>
> --
> 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/CAK%3DHD%2BZ5k%2BFk2guk8sxe8gs-kQ9NcKJLkHGeWprrucFzqZ%2BABA%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/CABNTSaHpG5ACme4ZWiAhmrJ6avbJs2k3jXMoPfLB1CJEDBWjqQ%40mail.gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[Sorawee Porncharoenwase]

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

Re: [racket-users] Reducing parentheses without language damage.

[Stephen De Gabrielle]

On Thu, 30 Apr 2020 at 20:01, Hendrik Boom  wrote:

> [...]
> > Also is there a programming editor that *won't* do parenthesis matching?
>
> Evidently the Racket editor whan debugging is disabled,


I’m not sure that’s true.

Kind regards
Stephen

-- 


-- 
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/CAGHj7-K_AbF4jmakuSixjnY_rNwPCqYgrd-JSWOrKFjash1Cvg%40mail.gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[George Neuner]

On 4/30/2020 5:40 PM, Sorawee Porncharoenwase wrote:

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


Actually, in the majority of programming languages there is no 
connection between program source and line grouping in an editor. 
Statement based languages define some character to be the statement 
"terminator" (or statement "separator" - yes, there is a semantic 
difference), but most often that character is the semi-colon, not 
#\return or  #\linefeed.


Racket, like Scheme and Lisp, is expression based, NOT statement based, 
and it can't do the same (at least not easily) because expressions can 
be nested arbitrarily, and they can't be limited to a single line.



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.


Once you use Racket (or Scheme or Lisp) long enough, you cease to see 
the parentheses and instead perceive the structure of the code from its 
indentation.  Most editors will happily match parentheses and many can 
understand Scheme structure enough to properly indent things.


George

--
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/c49cbf7a-c66b-88ed-5e6f-489a1c075009%40comcast.net.

Re: [racket-users] Reducing parentheses without language damage.

[Dexter Lagan]

  No it’s not, I checked again and couldn’t reproduce the problem. Please 
ignore my earlier comment.

  I’ve been tracking a bug that causes the colouring of a part of the code as 
comment and disable parenthesis handling, and since I switch debugging on and 
off often, I assumed it was related. I’ll dig further and post the issue if I 
can find out what triggers it.

Dex

> On Apr 30, 2020, at 10:06 PM, Stephen De Gabrielle  
> wrote:
> 
> 
> 
> 
>> On Thu, 30 Apr 2020 at 20:01, Hendrik Boom  wrote:
>> [...]
>> > Also is there a programming editor that *won't* do parenthesis matching?
>> 
>> Evidently the Racket editor whan debugging is disabled,
> 
> I’m not sure that’s true.
> 
> Kind regards
> Stephen
> 
> -- 
> 
> -- 
> 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/CAGHj7-K_AbF4jmakuSixjnY_rNwPCqYgrd-JSWOrKFjash1Cvg%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/E7008AC4-B012-4686-9244-93378E990C46%40gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[sleepnova]

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


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

Re: [racket-users] Reducing parentheses without language damage.

[Hendrik Boom]

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.

Re: [racket-users] Should I stop sending packages to the catalog?

[Sage Gerard]

Hi Jay,

Thanks for the recap. I suspected that I had enough context,
so it helps to have confirmation from a core dev.

It seems I should leverage a patchwork of sources to support
different use cases.

~slg

‐‐‐ Original Message ‐‐‐
On Thursday, April 30, 2020 8:57 AM, Jay McCarthy  
wrote:

> Hi Sage,
>
> Racket has a very high standard of backwards compatibility where we
> strive for programs to work continuously after many many years. In
> most cases, we've been able to live up to the standard with the core
> pieces of Racket. I can think of only a few times where we broke
> compatibility and they were really traumatic and I think we learned a
> lot from them about what compatibility really means.
>
> The package system reflects this ethos. As you know, you can give a
> dependency a lower-bound, but not an upper-bound, because we have
> always been fairly loose with adding functionality (although it is
> technical backwards incompatible), but not removing functionality. If
> you need to break old programs, then you need to make a new logical
> package, i.e. choose a new name, perhaps by adding a number to your
> old name.
>
> If you need to remove functionality or otherwise break old code, then
> you are not really working on the same package anymore, but a new
> product with similar functionality. In the history of Racket, you can
> see this with the change from `(module _ mzscheme ...)` to `#lang scheme` to 
> `#lang racket` and in the change from `(require mred)` to
> `(require scheme/gui)` to `(require racket/gui)`. These are NOT just
> advertising changes because of new names; instead, the name was a
> result of the need to add or remove functionality, while still
> allowing all old programs to continue working.
>
> This is simply a social standard though. There is nothing that
> technically prevents you from breaking compatibility, except that your
> users may be upset. You can post things on the package server that
> follows any rules you want, including conflicting with any other
> packages.
>
> If you do so, and if your users need to pin themselves to particular
> versions there are broadly two techniques. First, you can create your
> own package catalog. Most users typically use two catalogs: the "big"
> one on pkgs.racket-lang.org and another "small" one for your
> particular release, where the core racket packages are pinned to
> particular versions. When we were designing the package system, we
> imagined that organizations would maintain their own catalogs of
> audited versions of packages so they would not be surprised by any
> automatic updates. Second, you can change your package source to pin
> to a particular git revision/tag. This might be particularly useful if
> a package relies on erroneous behavior of some package that was
> otherwise fixed.
>
> Jay
>
> 

Re: [racket-users] a question or two regarding Gregor

[Jon Zeppieri]

Only a small number of zone formats are supported in parsing mode.
This is discussed a bit in https://github.com/97jaz/gregor/issues/25.
The situation could definitely be improved.

- Jon

On Thu, Apr 30, 2020 at 11:33 AM Tim Hanson  wrote:
>
> p.s. I'm stuck on parsing one pattern that comes up in my data. Here's a 
> corresponding test:
>
>   (parameterize ([current-locale "en"])
> (check-equal?
>  (parse-datetime "Sun, 21 Jun 2015 17:50:44 -0500 (CDT)" "EEE, dd MMM 
>  HH:mm:ss  ()") (datetime 2015 6 21 17 50 44)))
>
> that fails with
> ../../../../../Library/Racket/7.6/pkgs/gregor-lib/gregor/private/pattern/ast/zone.rkt:40:2:
>  match: no matching clause for (Zone ... 'offset-name 'long)
>
>
> I'm looking at the source code but am not quite sure. Are zone descriptors 
> such as CDT supported? (I also tried (zzz), but it also fails with
> no matching clause for (Zone ... 'offset-name 'short).)
>
>
> In
>   https://unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns
>
> I find an example:
>
> Pattern Result (in a particular locale)
> .MM.dd G 'at' HH:mm:ss zzz  1996.07.10 AD at 15:08:56 PDT
>
> which makes me think it should perhaps work.
>
> --
> 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/10f6f25d-6da8-4bbb-9459-ce63ae071c34%40googlegroups.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/CAKfDxxw3xz65z7Lm60qsYGhkBzR7Du36i9HfCQHzk7sdXxiytg%40mail.gmail.com.

Re: [racket-users] a question or two regarding Gregor

[Tim Hanson]

Thanks for the quick reply, Jon!

OK, good to know. Maybe I can add the ones I need (if I can figure out how...). 
:)

-- 
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/71a39eaa-7714-47fb-9d24-0d151ae93060%40googlegroups.com.

Re: [racket-users] Should I stop sending packages to the catalog?

[Jay McCarthy]

Hi Sage,

Racket has a very high standard of backwards compatibility where we
strive for programs to work continuously after many many years. In
most cases, we've been able to live up to the standard with the core
pieces of Racket. I can think of only a few times where we broke
compatibility and they were really traumatic and I think we learned a
lot from them about what compatibility really means.

The package system reflects this ethos. As you know, you can give a
dependency a lower-bound, but not an upper-bound, because we have
always been fairly loose with adding functionality (although it is
technical backwards incompatible), but not removing functionality. If
you need to break old programs, then you need to make a new logical
package, i.e. choose a new name, perhaps by adding a number to your
old name.

If you need to remove functionality or otherwise break old code, then
you are not really working on the same package anymore, but a new
product with similar functionality. In the history of Racket, you can
see this with the change from `(module _ mzscheme ...)` to `#lang
scheme` to `#lang racket` and in the change from `(require mred)` to
`(require scheme/gui)` to `(require racket/gui)`. These are NOT just
advertising changes because of new names; instead, the name was a
result of the need to add or remove functionality, while still
allowing all old programs to continue working.

This is simply a social standard though. There is nothing that
technically prevents you from breaking compatibility, except that your
users may be upset. You can post things on the package server that
follows any rules you want, including conflicting with any other
packages.

If you do so, and if your users need to pin themselves to particular
versions there are broadly two techniques. First, you can create your
own package catalog. Most users typically use two catalogs: the "big"
one on pkgs.racket-lang.org and another "small" one for your
particular release, where the core racket packages are pinned to
particular versions. When we were designing the package system, we
imagined that organizations would maintain their own catalogs of
audited versions of packages so they would not be surprised by any
automatic updates. Second, you can change your package source to pin
to a particular git revision/tag. This might be particularly useful if
a package relies on erroneous behavior of some package that was
otherwise fixed.

Jay

--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.

On Wed, Apr 29, 2020 at 12:47 PM Sage Gerard  wrote:
>
> April 9th in the #general Slack channel taught me that there was no clean way 
> to
> release a breaking change in a package. I'm open to working on version pinning
> support in raco pkg provided that a maintainer can walk me through some code.
>
> In the meantime, as much as I appreciate the efforts made in the current 
> system,
> I'm considering stopping my contributions to the package catalog until 
> further notice.
> I'm open to submitting packages if I am confident in their longevity, but I 
> don't want
> to end up in the position I've been in for the last few weeks when planning a 
> release.
> That position being an inability to release an edition that is not in some 
> way "aware"
> of a prior edition. In my view, changing the package/collection name is an
> example of that problem, not a solution to it.
>
> I'm considering asking my users to specify different package sources in their 
> info.rkt
> files when dealing with my work. Before I commit to that decision, I wanted 
> to tap into
> those of you who have already been here. How have you handled breaking changes
> for your projects? How have you communicated with your users to make sure they
> were adequately prepared? Am I being too black-and-white about this?
>
> ~slg
>
>
> --
> 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/3tKIr3GrU9Jnl7V-5yzb52OL3mjt8XNe9F_Qv9HDKwy8xC4j9lQo2e5eGSle4ZFHAee_FiGVhr15lXoovUE6yqoARP-ZNi3kXXz8ETXdufg%3D%40sagegerard.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/CAJYbDa%3Dg7xUiAG3ghR1AKRXneUVcY7Q6A4snMiNjNEC12O2P%2Bg%40mail.gmail.com.

Re: [racket-users] Re: contributing fixes to documentation

[Dexter Lagan]

  Thanks, this guide is great. I'll make sure I fix whatever problem I find
when I scour the docs. I do have a question however: say I find a typo in a
function definition, is there any part of the doc that is automatically
generated, and should not be updated, or updated with specific attention?

Dex

On Thu, Apr 30, 2020 at 11:55 AM Stephen De Gabrielle <
spdegabrie...@gmail.com> wrote:

> I'd forgotten the tutorial to contributing - someone kindly reminded me
> recently
> https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html
>
> This covers everything from fixing a typo to contributing to the racket
> language and the main distribution.
>
> it is worth the read!
>
> S
>
> On Thursday, April 30, 2020 at 10:49:33 AM UTC+1, Stephen De Gabrielle
> wrote:
>>
>> Yo Racketeers!
>>
>> Someone recently mentioned that is was tricky to update documentation. it
>> can be.
>> I thought I'd provide the steps I took to create a PR for the DrRacket
>> documentation in the hope that they are useful for others who see an issue
>> with documentation but finding locating the right scribble file a problem.
>>
>> In my case I wanted to create a PR to update the 'Extending DrRacket'
>> part of the DrRacket manual.
>>
>> My steps were
>> 1. click on the header of the heading in the manual, it opens up with a
>> little link on how to link to that section note the path:
>> scribblings/drracket/drracket.scrbl
>> Link to this section with
>>  @secref["extending-drracket"
>>  #:doc '(lib "scribblings/drracket/drracket.scrbl")]
>>
>> 2.  go to the DrRacket repo and look for something matching that path.
>> It was buried a little but I found it at
>> https://github.com/racket/drracket/blob/master/drracket/scribblings/drracket/drracket.scrbl
>>
>> 3. this scribble file is a list of includes, but I was able to match
>> https://docs.racket-lang.org/drracket/extending-drracket.html
>> with
>> @include-section["extending.scrbl"]
>>
>> 4. opening extending.scrbl I find the section I want to change
>>
>> https://github.com/racket/drracket/blob/master/drracket/scribblings/drracket/extending.scrbl
>>
>> #lang scribble/doc
>> @(require "common.rkt"
>> (for-label compiler/cm setup/parallel-build racket/promise))
>> @(define racodoc '(lib "scribblings/raco/raco.scrbl"))
>> @title[#:tag "extending-drracket"]{Extending DrRacket}
>> DrRacket supports two forms of extension to the programming
>> environment:
>> @itemize[
>> (gmail formatted this weirdly)
>>
>> 5. For simple changes (e.g. typos) you can just list in place and create
>> a PR
>>  - for more complex changes you will need to fork the repo and rebuild
>> the scribble to ensure it works before submitting the PR. e.g
>> https://github.com/racket/drracket/pull/372
>>
>> 6. if you run into trouble ask here on racket-users, or on the Racket
>> slack - there are many helpful racketeers out there.
>>
>> Kind regards
>>
>> Stephen
>>
>>
>> --
> 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/9e7438ef-0a7d-4660-a5ba-c2bb41928a3c%40googlegroups.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/CACUENrKUjZ-ziAVVH1xt6z3Jn8MChwnvDGwEMg3XBs990H0Zuw%40mail.gmail.com.

Re: [racket-users] Rhombus project plan

[Sam Tobin-Hochstadt]

On Thu, Apr 30, 2020 at 9:09 AM Ben Greenman
 wrote:
>
> On 4/29/20, Sorawee Porncharoenwase  wrote:
> > (Not directly related to Rhombus) Speaking of “how to contribute”, I find
> > that it is not friendly at all to setup stuff in order to contribute to
> > Racket core and main distribution. According to
> > https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html,
> > if I want to make a change to, say, https://github.com/racket/math, I
> > should start with:
> >
> > $ raco pkg update --no-setup --catalog https://pkgs.racket-lang.org math
> > $ raco pkg update --clone math
> >
> > The estimated time to run the above two commands is ONE HOUR! The second
> > command in particular seems to compile every Racket packages (why does it
> > need to do that?!?) which takes a lot of time.
>
> That second command recompiles only the packages that depend on math.
> Unfortunately there are a lot of them.

To follow up on that, here are some strategies for reducing that time:

1. Start with Minimal Racket, install "math", then follow the steps
above. That will just rebuild `math`, not everything that depends on
it, since they won't be installed.

2. (Dangerous) Do the following:
   $ raco pkg update --no-setup --clone math # fast
   $ raco setup math

This will only setup "math", and thus be faster, but will potentially
cause other parts of the installation to not work correctly until you
run "raco setup".

Making the original commands go faster would require one of three
things (in increasing order of difficulty): detecting that many zo
files can be re-used from the previous installation in some fashion,
making Typed Racket faster, or making Racket macro expansion more
incremental.

Sam

-- 
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/CAK%3DHD%2BZ5k%2BFk2guk8sxe8gs-kQ9NcKJLkHGeWprrucFzqZ%2BABA%40mail.gmail.com.

[racket-users] Re: Reducing parentheses without language damage.

[George Neuner]

On Thu, 30 Apr 2020 11:16:10 -0400, Hendrik Boom
 wrote:

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

ML and Haskell both look very similar to what you seem to want.  So
does Python for that matter.

But it isn't possible to write integrated, reflexive macros in any of
those languages.  They DO allow macros (of a sort), but their macros
have to be written using a different, more restrictive language ...
ie. you don't write an ML macro in ML, you write it in the subset
language M(acro)ML.

Consequently, macros are not used heavily in any of those languages.
And use of DSLs with those languages are rare.


If you look at the history of Lisp, you'll see that originally it was
intended to have a more conventional syntax: the S-expr parenthesis
laden syntax we still use was intended as a stopgap until the
conventional "M-expr" syntax could be implemented.  But macros proved
to be very difficult to adapt to the M-expr syntax, and macros were so
important to Lisp that they caused McCarthy to abandon the idea of
M-exprs.

George

-- 
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/hvrlafdq67djfk04p10i7teekn0m2pa4kb%404ax.com.

[racket-users] Reducing parentheses without language damage.

[Hendrik Boom]

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  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  於 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:
> >> 
> >> 
> >> 
> >> 
> >> 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  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 
> 

Re: [racket-users] Rhombus project plan

[Ben Greenman]

On 4/29/20, Sorawee Porncharoenwase  wrote:
> (Not directly related to Rhombus) Speaking of “how to contribute”, I find
> that it is not friendly at all to setup stuff in order to contribute to
> Racket core and main distribution. According to
> https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html,
> if I want to make a change to, say, https://github.com/racket/math, I
> should start with:
>
> $ raco pkg update --no-setup --catalog https://pkgs.racket-lang.org math
> $ raco pkg update --clone math
>
> The estimated time to run the above two commands is ONE HOUR! The second
> command in particular seems to compile every Racket packages (why does it
> need to do that?!?) which takes a lot of time.

That second command recompiles only the packages that depend on math.
Unfortunately there are a lot of them.

-- 
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/CAFUu9R6DkRjxd_YNrLGLa%2BCc2q8zUk5MfuTDzcP%2BpAZ_CM43eQ%40mail.gmail.com.

Re: [racket-users] a question or two regarding Gregor

[Tim Hanson]

p.s. I'm stuck on parsing one pattern that comes up in my data. Here's a 
corresponding test:

  (parameterize ([current-locale "en"])
(check-equal?
 (parse-datetime "Sun, 21 Jun 2015 17:50:44 -0500 (CDT)" "EEE, dd MMM 
 HH:mm:ss  ()") (datetime 2015 6 21 17 50 44)))

that fails with
../../../../../Library/Racket/7.6/pkgs/gregor-lib/gregor/private/pattern/ast/zone.rkt:40:2:
 match: no matching clause for (Zone ... 'offset-name 'long)


I'm looking at the source code but am not quite sure. Are zone descriptors such 
as CDT supported? (I also tried (zzz), but it also fails with 
no matching clause for (Zone ... 'offset-name 'short).)


In 
  https://unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns

I find an example:

Pattern Result (in a particular locale)
.MM.dd G 'at' HH:mm:ss zzz  1996.07.10 AD at 15:08:56 PDT

which makes me think it should perhaps work.

-- 
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/10f6f25d-6da8-4bbb-9459-ce63ae071c34%40googlegroups.com.

Re: [racket-users] Rhombus project plan

[Dexter Lagan]

  I just read myself, I meant runtime errors, not compile-time errors. One big 
complain I hear from people used to compiled languages - when they first use 
dynamic and interpreter languages - is the idea of having errors occur at 
runtime, which ‘should’ have been picked up by the interpreter before runtime.

  I understand there’s a major trade off here, and there are things that are 
possible to do with interpreters that aren’t with compilers, and vice versa. 
What I was referring to, is a way to analyse further the source, to identify 
potential errors before they happen at runtime. I thought that’s what contracts 
and typing in general was supposed to catch, and I have yet to experiment with 
contracts in my code, in production. However I have encountered this problem 
many times :

(get-text-from-user ...) returns a string of #f.

  If I use the output of this function, I always run the risk of having the 
user click cancel, and get a contract error returned by the next function. So I 
always have to have something like

(unless result (exit 0))
...or something more involved to deal with the possibility of getting #f like:

(if result (do-something-with result)
   (display-error-and-do-something-else))

  Somehow I’ve always been surprised by the behaviour, and I wish there was a 
solution to this, apart from literally filling my code with checks (which is 
what I do now). If only there was a way to trace the possible output of 
functions against the permitted input of the next function in the chain 
(through continuation marks?), then maybe we could solve a piece of that 
runtime errors puzzle.

Dex

> On Apr 29, 2020, at 11:24 PM, Dexter Lagan  wrote:
> 
>   You’ve always been very inspiring to me. I’ll do my best to better the 
> docs if there’s a guide on how to do so. Bear with me, I have no background 
> in computer science and I don’t even know what a pull request is. I only 
> recently started using version control. I’ve always worked alone, until 
> recently - now I have to lead a team, and I can not longer escape the hard 
> stuff.
> 
>  I have a million questions, about Racket’s direction and symbolic 
> computation in general. I’ve been reading day and night on everything I 
> should have learned in comp-sci. 
> 
>  My dream is to find a solution to compile-time errors (through some kind of 
> analysis, maybe contracts already solve this?), and find a way to teach kids 
> how to program. Thanks for telling me about bootstrapworld. I’ll check it out.
> 
> Dex
> 
>>> On Apr 29, 2020, at 2:21 PM, Matthew Flatt  wrote:
>>> 
>>> At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote:
>>> To the point: what would make Racket2 the ultimate tool (for me):
>>> Performance. Faster startup times, shorter execution times in general. 
>>> Optionally, a ‘lite’ version of Racket that compiles directly to no-deps 
>>> binaries, bypassing the JIT altogether, would be a game-changer. As far as 
>>> high levels languages with functional concepts and metaprogramming 
>>> facilities 
>>> that compiles to tiny, fast bins, Nim comes dangerously close, but it’s not 
>>> a 
>>> Lisp, and it’s not Racket.
>>> Production-quality, modern and fast GUI facilities. I’ll take properly 
>>> documented, complete Qt bindings. Racket/GUI is great for internal tools, 
>>> but 
>>> it quickly becomes slow, tedious and limited for more complex client-facing 
>>> UIs.
>>> One complete, commercial-grade Web framework, inspired from Symphony or 
>>> Laravel. Security and ease of use first, continuations later.
>>> Better documentation: Racket docs are aesthetically very pleasing, complete 
>>> and detailed. However some parts are still very obscure and lacking simple 
>>> examples (if only the part about Continuations included just one basic 
>>> example, such as a ‘return’ implementation, on the very first page. If only 
>>> the Macros documentation started with define-simple-macro and a few very 
>>> basic, practical examples. Instead we’re greeted with pattern-based macros, 
>>> which although very powerful, are very hard to comprehend for newcomers).
>> 
>> Which of these things will you be working on?
>> 
>> 
>>> I am well aware that what I’m wishing for isn’t necessarily compatible with 
>>> Racket’s intended public’s needs (comp-sci teachers and students? That’s 
>>> the 
>>> impression I’m getting). But Racket is the most advanced general purpose 
>>> programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited 
>>> to 
>>> academic use?
>> 
>> https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be
>> 
>> -- 
>> 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/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

-- 

[racket-users] Re: contributing fixes to documentation

[Stephen De Gabrielle]

I'd forgotten the tutorial to contributing - someone kindly reminded me 
recently
https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html

This covers everything from fixing a typo to contributing to the racket 
language and the main distribution.

it is worth the read!

S

On Thursday, April 30, 2020 at 10:49:33 AM UTC+1, Stephen De Gabrielle 
wrote:
>
> Yo Racketeers!
>
> Someone recently mentioned that is was tricky to update documentation. it 
> can be. 
> I thought I'd provide the steps I took to create a PR for the DrRacket 
> documentation in the hope that they are useful for others who see an issue 
> with documentation but finding locating the right scribble file a problem.
>
> In my case I wanted to create a PR to update the 'Extending DrRacket' part 
> of the DrRacket manual. 
>
> My steps were 
> 1. click on the header of the heading in the manual, it opens up with a 
> little link on how to link to that section note the path:  
> scribblings/drracket/drracket.scrbl
> Link to this section with 
>  @secref["extending-drracket"
>  #:doc '(lib "scribblings/drracket/drracket.scrbl")]
>
> 2.  go to the DrRacket repo and look for something matching that path.
> It was buried a little but I found it at 
> https://github.com/racket/drracket/blob/master/drracket/scribblings/drracket/drracket.scrbl
>
> 3. this scribble file is a list of includes, but I was able to match
> https://docs.racket-lang.org/drracket/extending-drracket.html
> with
> @include-section["extending.scrbl"]
>  
> 4. opening extending.scrbl I find the section I want to change
>
> https://github.com/racket/drracket/blob/master/drracket/scribblings/drracket/extending.scrbl
>
> #lang scribble/doc
> @(require "common.rkt"
> (for-label compiler/cm setup/parallel-build racket/promise))
> @(define racodoc '(lib "scribblings/raco/raco.scrbl"))
> @title[#:tag "extending-drracket"]{Extending DrRacket}
> DrRacket supports two forms of extension to the programming
> environment:
> @itemize[
> (gmail formatted this weirdly)
>
> 5. For simple changes (e.g. typos) you can just list in place and create a 
> PR 
>  - for more complex changes you will need to fork the repo and rebuild the 
> scribble to ensure it works before submitting the PR. e.g 
> https://github.com/racket/drracket/pull/372
>
> 6. if you run into trouble ask here on racket-users, or on the Racket 
> slack - there are many helpful racketeers out there.
>
> Kind regards
>
> Stephen
>
>
>

-- 
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/9e7438ef-0a7d-4660-a5ba-c2bb41928a3c%40googlegroups.com.

[racket-users] contributing fixes to documentation

[Stephen De Gabrielle]

Yo Racketeers!

Someone recently mentioned that is was tricky to update documentation. it
can be.
I thought I'd provide the steps I took to create a PR for the DrRacket
documentation in the hope that they are useful for others who see an issue
with documentation but finding locating the right scribble file a problem.

In my case I wanted to create a PR to update the 'Extending DrRacket' part
of the DrRacket manual.

My steps were
1. click on the header of the heading in the manual, it opens up with a
little link on how to link to that section note the path:
scribblings/drracket/drracket.scrbl
Link to this section with
 @secref["extending-drracket"
 #:doc '(lib "scribblings/drracket/drracket.scrbl")]

2.  go to the DrRacket repo and look for something matching that path.
It was buried a little but I found it at
https://github.com/racket/drracket/blob/master/drracket/scribblings/drracket/drracket.scrbl

3. this scribble file is a list of includes, but I was able to match
https://docs.racket-lang.org/drracket/extending-drracket.html
with
@include-section["extending.scrbl"]

4. opening extending.scrbl I find the section I want to change
https://github.com/racket/drracket/blob/master/drracket/scribblings/drracket/extending.scrbl

#lang scribble/doc
@(require "common.rkt"
(for-label compiler/cm setup/parallel-build racket/promise))
@(define racodoc '(lib "scribblings/raco/raco.scrbl"))
@title[#:tag "extending-drracket"]{Extending DrRacket}
DrRacket supports two forms of extension to the programming
environment:
@itemize[
(gmail formatted this weirdly)

5. For simple changes (e.g. typos) you can just list in place and create a
PR
 - for more complex changes you will need to fork the repo and rebuild the
scribble to ensure it works before submitting the PR. e.g
https://github.com/racket/drracket/pull/372

6. if you run into trouble ask here on racket-users, or on the Racket slack
- there are many helpful racketeers out there.

Kind regards

Stephen

-- 
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/CAGHj7-%2BtJTEP%2BdNS21u%2BzzihteL0X2V0%2BkZJEHsP4K5kpPQPqw%40mail.gmail.com.

Re: [racket-users] Re: Should I stop sending packages to the catalog?

[Laurent]

Alex, that looks like an interesting workflow. Maybe worth a blog post? ;)

On Thu, Apr 30, 2020 at 12:11 AM Alex Harsanyi 
wrote:

>
> You could both send packages to the package catalog and instruct your
> users to use a different package source if they wish to use old versions.
> I don't see these two options in conflict with each other.
>
> As an application writer, I am on the other side of this problem, by
> depending on other packages. Having limited time to work on my project I
> want to upgrade package dependencies at my own pace.   The solution I found
> is to use git submodules and add each package as a submodule to my
> application.  I  construct a catalog of these packages, at an exact git
> commit, and simply run a raco pkg install, knowing that the exact version
> that I want will be there.  From time to time, I update these submodules
> and allow some time for fixing any problems that might result from these
> updates.  This has worked reasonably well so far, and I can reliably
> reconstruct older versions of the application knowing that all dependencies
> will be correct for that old version.
>
> For my part, for any packages that my application depends on, their
> authors can make any breaking changes they want, as this will not
> immediately break my application.  At a later date I can review these
> changes, update my application and move to the new version.
>
> The only downside is that installed packages are at "user scope" rather
> than "application scope" so once installed from the git submodules, that
> package becomes available to all applications on my computer.   So far this
> has not been a real issue, although I had to uninstall, switch catalogs and
> re-install a few times.
>
> I personally regard pkgs.racket-lang.org as the source for the latest
> package versions, for users which just started using the package. Users who
> need precise versioning, can always setup their own package catalogs (i
> discovered that it is a really simple process)
>
> Alex.
>
>
> On Thursday, April 30, 2020 at 12:47:25 AM UTC+8, Sage Gerard wrote:
>>
>> April 9th in the #general Slack channel taught me that there was no clean
>> way to
>> release a breaking change in a package. I'm open to working on version
>> pinning
>> support in raco pkg provided that a maintainer can walk me through some
>> code.
>>
>> In the meantime, as much as I appreciate the efforts made in the current
>> system,
>> I'm considering stopping my contributions to the package catalog until
>> further notice.
>> I'm open to submitting packages if I am confident in their longevity, but
>> I don't want
>> to end up in the position I've been in for the last few weeks when
>> planning a release.
>> That position being an inability to release an edition that is not in
>> some way "aware"
>> of a prior edition. In my view, changing the package/collection name is an
>> example of that problem, not a solution to it.
>>
>> I'm considering asking my users to specify different package sources in
>> their info.rkt
>> files when dealing with my work. Before I commit to that decision, I
>> wanted to tap into
>> those of you who have already been here. How have you handled breaking
>> changes
>> for your projects? How have you communicated with your users to make sure
>> they
>> were adequately prepared? Am I being too black-and-white about this?
>>
>> *~slg*
>>
>>
>> --
> 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/b3b54ccf-b4f1-425e-802a-110d5ac26591%40googlegroups.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/CABNTSaE5MN8qDaKd7VF1qL%3DbRhktAw017jyVzUe4O8sFkK%3D0QQ%40mail.gmail.com.

Re: [racket-users] on reducing barriers in the Racket community

[Dexter Lagan]

  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.

Dex

> On Apr 25, 2020, at 3:25 PM, sleepnova  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  於 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:
>> 
>> 
>> 
>> 
>> 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  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.

[racket-users] anagram

[aziz]

*hello i need again your help i have an examen in one day i need to 
understand this programme : Define an anagr function taking as a parameter 
a character string and returning the list of all anagrams of this string. 
We are not concerned in this question of whether an anagram appears several 
times or not in the result. We can do this in the following way: calculate 
all anagrams starting with the first character of the given string, then 
all those starting with the second character of the given string and so on. 
For example, this function could give the results following: (anagr "abc") 
returns' ("abc" "acb" "bac" "bca" "cab" "cba") and (anagr "aba") returns 
("aba" "aab" "baa" "baa "" aab "" aba "). i have an idea : isolated the 
first character then calculate the anagrams of the remaining strings then 
with the second character and so on*
*But i don't know how make this exercise please*

-- 
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/77a8130b-6950-4308-89fa-7b4d35267cba%40googlegroups.com.