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

[David Storrs]

On Fri, May 1, 2020, 11:25 PM Raoul Duke  wrote:

> $0.02, whitespace sensitivity is just bad ux in the long run. haskell can
> get away with it more than python because haskell can be written more
> concisely i feel than python. but even in H it is sorta unfortunate.
>
> i like how iirc clojure uses sexprs but allows other kinds of parens,
> fairly arbitrarily.
>
> (foo '{2 3 4} '[a b c])
> same thing as
> (foo '(2 3 4) '(a b c))
>
> so humans can make some parts stand out a little bit differently.
>

Racket does the same thing. (), [], and {} are all equivalent as long as
they match consistently. (i.e. you can't do '(] because that doesn't match
consistently.)

> --
> 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/CAJ7XQb67vFEX7D0hHOxJXVG6344ngYU1%3DtmmQ0m6%3DVijqODEQw%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/CAE8gKocmAWMH4TUdJEPCBTPSSe8qEeaixNybDAsERMJaVOBDhQ%40mail.gmail.com.

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

[Raoul Duke]

$0.02, whitespace sensitivity is just bad ux in the long run. haskell can
get away with it more than python because haskell can be written more
concisely i feel than python. but even in H it is sorta unfortunate.

i like how iirc clojure uses sexprs but allows other kinds of parens,
fairly arbitrarily.

(foo '{2 3 4} '[a b c])
same thing as
(foo '(2 3 4) '(a b c))

so humans can make some parts stand out a little bit differently.

-- 
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/CAJ7XQb67vFEX7D0hHOxJXVG6344ngYU1%3DtmmQ0m6%3DVijqODEQw%40mail.gmail.com.

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

[Liwei Chou]

Any one consider this style? Minimizing visual interference while 
preserving parentheses. Even Java program can be written like Python.

[image: main-qimg-8d66f35cd3da4c55a380d0d08c11d930.png]

https://www.quora.com/What-is-the-most-frustrating-thing-about-being-a-computer-programmer/answer/Jesse-Jaun

Though it's kind of like making fun with different coding style. There 
might be some inspiration for us.

gneuner2於 2020年5月2日星期六 UTC+8上午8時12分53秒寫道：
>
>
> On 5/1/2020 4:35 PM, Dexter Lagan wrote:
>
>   Is there value in Rob Pike’s comment on avoiding significant white space 
> in the Go language? 
>
> “We have had extensive experience tracking down build and test failures 
> caused by cross-language builds where a Python snippet embedded in another 
> language, for instance through a SWIG invocation, is subtly and invisibly 
> broken by a change in the indentation of the surrounding code.” — Rob 
> Pike, 2012 
>
>
> I'm not really sure what Pike is getting at there:  I haven't used SWIG 
> myself, but if I understand it correctly, Python code would have to be in a 
> module to be called from "other" language code.  If so, I don't see how the 
> indentation of the "other" code could affect the Python.
>
> That aside: 
>
> Even working only in Python, programmers routinely get tripped up by 
> copy/paste errors - so it is evident that indentation sensitivity is not 
> any real solution to scope related logic problems.  It might [for some 
> definition] help newbies identify stupid errors, but I believe that even 
> moderately experienced programmers are more hindered than helped by it.
>
>
>   I personally dislike white space and prefer either mustaches or 
> parenthesis, just so I know my code will still work if line feeds are 
> stripped somehow, or that some piece of code is embedded or quoted in 
> another language, which is what I gather Rob was talking about. However, 
> Haskell and Python people don’t seem to mind, and if it saves us more 
> keystrokes while keeping expressiveness, why not?
>
>
> Well, few people use Haskell, so I would discount it as a data point.  
> Even so, one of the tutorials includes this interesting tidbit:
>
> With good text editor, programming is fun. Of course, you can get along 
> with simplistic
> editor capable of just cut-n-paste, but good editor is capable of doing 
> most of the chores
> for you, letting you concentrate on what you are writing. With respect to 
> programming
> in Haskell, good text editor should have as much as possible of the 
> following features:
>
> • Syntax highlighting for source files
> • Indentation of source files
> • Interaction with Haskell interpreter (be it Hugs or GHCi)
> • Computer-aided code navigation
> • Code completion
>
>
> The implication is that Haskell is difficult to write without proper 
> editor support.  So too is Python.  Decent syntax and structure aware 
> editors are not really a problem any more, but they can go only so far:  
> they can fail spectacularly when code gets complicated and the language 
> syntax provides no clues to figure out the scoping.
>
> S-exprs do not suffer from this affliction.
>
>
> Also mentioned previously is my concern that indentation sensitivity may 
> make implementing macros as we enjoy them in Racket difficult.  Or maybe 
> impossible.  Although certainly there are indentation languages which have 
> macro facilities, I am not aware of any in which the macros can be written 
> in the same language.  All the ones I know of implement a separate DSL 
> macro language.
>
> I have designed and implemented a few languages: including a Scheme-ish 
> mostly functional language [but lacking macros].   I have not thought 
> through all the nuances of implementing a language that can reflectively 
> manipulate the structure of a program in the midst of compiling it  [or in 
> the case of Lisp - running it].  However, I have to think there are reasons 
> for existing indentation languages not having done so.
>
> YMMV,
> 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/a7b75492-0a76-4d18-b586-2cde1c7acee4%40googlegroups.com.

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

[George Neuner]

On 5/1/2020 4:35 PM, Dexter Lagan wrote:
  Is there value in Rob Pike’s comment on avoiding significant white 
space in the Go language?


“We have had extensive experience tracking down build and test 
failures caused by cross-language builds where a Python snippet 
embedded in another language, for instance through a SWIG invocation, 
is subtly and invisibly broken by a change in the indentation of the 
surrounding code.” — Rob Pike, 2012 





I'm not really sure what Pike is getting at there:  I haven't used SWIG 
myself, but if I understand it correctly, Python code would have to be 
in a module to be called from "other" language code.  If so, I don't see 
how the indentation of the "other" code could affect the Python.


That aside:

Even working only in Python, programmers routinely get tripped up by 
copy/paste errors - so it is evident that indentation sensitivity is not 
any real solution to scope related logic problems.  It might [for some 
definition] help newbies identify stupid errors, but I believe that even 
moderately experienced programmers are more hindered than helped by it.



  I personally dislike white space and prefer either mustaches or 
parenthesis, just so I know my code will still work if line feeds are 
stripped somehow, or that some piece of code is embedded or quoted in 
another language, which is what I gather Rob was talking about. 
However, Haskell and Python people don’t seem to mind, and if it saves 
us more keystrokes while keeping expressiveness, why not?


Well, few people use Haskell, so I would discount it as a data point.  
Even so, one of the tutorials includes this interesting tidbit:


   With good text editor, programming is fun. Of course, you can get
   along with simplistic
   editor capable of just cut-n-paste, but good editor is capable of
   doing most of the chores
   for you, letting you concentrate on what you are writing. With
   respect to programming
   in Haskell, good text editor should have as much as possible of the
   following features:

   • Syntax highlighting for source files
   • Indentation of source files
   • Interaction with Haskell interpreter (be it Hugs or GHCi)
   • Computer-aided code navigation
   • Code completion


The implication is that Haskell is difficult to write without proper 
editor support.  So too is Python.  Decent syntax and structure aware 
editors are not really a problem any more, but they can go only so far:  
they can fail spectacularly when code gets complicated and the language 
syntax provides no clues to figure out the scoping.


S-exprs do not suffer from this affliction.


Also mentioned previously is my concern that indentation sensitivity may 
make implementing macros as we enjoy them in Racket difficult. Or maybe 
impossible.  Although certainly there are indentation languages which 
have macro facilities, I am not aware of any in which the macros can be 
written in the same language.  All the ones I know of implement a 
separate DSL macro language.


I have designed and implemented a few languages: including a Scheme-ish 
mostly functional language [but lacking macros].   I have not thought 
through all the nuances of implementing a language that can reflectively 
manipulate the structure of a program in the midst of compiling it  [or 
in the case of Lisp - running it].  However, I have to think there are 
reasons for existing indentation languages not having done so.


YMMV,
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/e92ee43b-5d6c-000d-dc04-25fe76149284%40comcast.net.

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

[Alex Harsanyi]

On Friday, May 1, 2020 at 9:12:55 PM UTC+8, Jesse Alama wrote:
>
> On Thursday, April 30, 2020 at 2:57:45 PM UTC+2, Jay McCarthy wrote:
>>
>>
>> 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.
>>
>
> I'd like to second this point. There's nothing stopping you from pushing 
> whatever you want to your repo, and hence distributing whatever you want 
> via the package server. I've pushed breaking changes to my packages before, 
> and no one has complained, so I guess I didn't break any part of the 
> interface that they were using. (Or I have no users of my stuff at all, 
> which is certainly possible!)
>
> I don't know how many packages mention, in their description, that they're 
> experimental, explicitly warning me that the interface is unstable and 
> likely to change. I use 'em anyway because they offer useful functionality. 
> I don't recall being nailed by breaking changes, but perhaps I'm just 
> getting lucky.
>
> What exactly is the claim, anyway, about the package server not allowing 
> breaking changes? Is it that if you do a breaking change to your package, 
> then it's possible that other people's packages correspondingly break? If 
> so, then I think that's not a very interesting claim. Does the claim at 
> issue just amount to a restatement of the ethos that Jay mentioned about 
> trying to ensure backwards compatibility for a long time?
>

I think that there are two issues here: 

First there's backwards compatibility -- it is a good idea to keep your 
packages backwards compatible, although sometimes it can be difficult, 
especially with packages which were released too early, before their 
interface stabilized.

Than there are breaking changes.  This does include the backwards 
incompatible changes, but also includes defects.  Defects are 
unintentional, usually unknown to the author at the time of publishing the 
new package version, yet they can break the application.  

As an application author, when my application stops working after updating 
packages, it is little consolation that the API of a package remained 
backwards compatible.

Perhaps I was just unlucky, but I encountered show-stopper defects in the 
first two external packages I tried to use in my application. I had a local 
fix, but had to wait for the author several months to fix the problem (this 
is understandable, the author was busy and these packages were not his top 
priority).   The mechanism I came up with was driven by the following needs:

(1) sit out a package version because it has a defect
(2) while sitting out a package version, I want to be able to update 
other packages that are not affected by the defect
(3) use an alternate source for a package which contains a fix, until 
an official fix is released
(4) delay updating packages, until I have time to verify that the 
update does not break the application and/or address problems
(5) be able to reconstruct old software configurations including 
dependencies

Number (5) is very important to me: I have some development branches which 
are active for several months, and when I go bad to an older branch, to 
continue work, the last thing I want is to deal with a package upgrade -- 
this perhaps reflects personal circumstances: I quite often have 1 hour to 
try to progress a feature on an old branch, and if I spend 15 - 20 minutes 
merging master, updating packages and resolving conflicts, that's 25 - 30% 
of available time gone.
 

> (All this said, I'd like to learn more about setting up custom package 
> catalogs, as Alex mentioned, to take matters even more into your own hands.)
>

There is not much to it:  git submodules are widely documented, so I'll 
leave those out, but here is the script that sets up the package catalog 
https://github.com/alex-hhh/ActivityLog2/blob/master/etc/scripts/setup-catalog.sh

And here is the snipped from the build file which sets things up and 
installs packages (note that this install uses "isolation mode" to catch 
dependencies which are not tracked as submodules, don't use the -i switch 
on your development machine):
 

   
 bash ./etc/scripts/setup-catalog.sh -i pkgs/
 raco pkg install --auto tzinfo tzgeolookup data-frame plot-container


I also have added code to my application to verify that the packages are 
installed before building or compiling it and it produdces more user 
friendly error messages. (e.g. it tells the user that they forgot to 
install the "tzinfo" package, rather than failing with a "module not found" 
error).  You can find that here: 
https://github.com/alex-hhh/ActivityLog2/blob/777847f2cdb18ff09596848efc40a332e65da017/rkt/utilities.rkt#L446
 
Alex.
 

-- 
You received this message because you are subscribed to the Google Groups 
"Racke

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

[Dexter Lagan]

  Is there value in Rob Pike’s comment on avoiding significant white space in 
the Go language?

“We have had extensive experience tracking down build and test failures caused 
by cross-language builds where a Python snippet embedded in another language, 
for instance through a SWIG invocation, is subtly and invisibly broken by a 
change in the indentation of the surrounding code.” — Rob Pike, 2012

  I personally dislike white space and prefer either mustaches or parenthesis, 
just so I know my code will still work if line feeds are stripped somehow, or 
that some piece of code is embedded or quoted in another language, which is 
what I gather Rob was talking about. However, Haskell and Python people don’t 
seem to mind, and if it saves us more keystrokes while keeping expressiveness, 
why not?

Dex

> On May 1, 2020, at 10:20 PM, George Neuner  wrote:
> 
> 
> I haven't followed all the discussion regarding a potential successor to 
> Racket.  AFAIHS, no one actually has suggested a required indentation scheme 
> ala Python, but since source indentation (and formatting in general) 
> currently is under discussion, I wanted to make known my feelings on the 
> matter.
> 
> If you don't feel strongly about source indentation, you can skip this.
> 
> George
> 
> 
>> On 5/1/2020 1:19 PM, Christopher Lemmer Webber wrote:
>> Sorawee Porncharoenwase writes:
>> 
>> >
>> >> 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.
>> 
>> You don't even need to imagine it... when Python was taking off, one of
>> the biggest arguments was that it forced people to learn to do
>> reasonable indentation.  Doesn't seem like as much of a good argument
>> now as I thought it was then, and that's partly because most code is
>> indented fine these days due to, as you say, good IDE support.
> 
> The indentation requirement - aka "significant whitespace" - is one of the 
> main things I dislike about Python [the other is its comprehension syntax].  
> An argument certainly can be made for advocating a readable coding style ... 
> but on principle I disagree with a language *requiring* any particular style.
> 
> 
> As it happens, I am old enough to remember when Fortran required very 
> particular formatting: worse even than Python, Fortran was designed around 
> 80-column punch cards, and for a VERY long time it was necessary that 
> particular things be placed in particular columns ... else the statement 
> would not compile.
> 
> see https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html
> 
> Fortran's adherence to rigid source formatting really did not simplify the 
> compiler much at all  (actually an argument can be made that it unnecessarily 
> complicated recognizing certain constructs). And if it ever helped, it wasn't 
> necessary for long - by 1962 [Fortran was introduced in 1959] compilers were 
> able to deal with free form code.  The first version of Lisp [1961] was on 
> punch cards as well, but from the beginning Lisp never had column based 
> restrictions on source format.
> 
> Fortran ... still recognizes the old style, but ... no longer requires column 
> based formatting.  Free form source has been supported by compilers since 
> Fortran90.
> 
> Historically, there have been a handful of (higher level, non-assembly) 
> languages that had odd source formatting requirements, but none were as 
> onerous as Fortran, and none of them survived very long.  But just as Fortran 
> finally was giving up on the idea, Python came along to revive it.  [Python 
> began at about the same time Fortran90 was in committee.]
> 
> 
> Forcing programmers to do menial tasks like configuring editors to certain 
> modes [spaces vs tabs], and to manually count spaces when corresponding 
> scoped lines are too far apart to eyeball the vertical alignment is simply 
> counterproductive - there are plenty of more important things that 
> programmers should be worrying about. Programming editors having language 
> structural awareness have been around since the 80's ... there is no reason 
> ever to bake such things as indentation requirements into the language.
> 
> Just my 2 cents.
> 
> -- 
> 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/e180703e-6e2e-ea6b-d918-b46ff4eebb07%40comcast.net.

-- 
You received this message because you are s

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

[George Neuner]

I haven't followed all the discussion regarding a potential successor to 
Racket.  AFAIHS, no one actually has suggested a required indentation 
scheme ala Python, but since source indentation (and formatting in 
general) currently is under discussion, I wanted to make known my 
feelings on the matter.


If you don't feel strongly about source indentation, you can skip this.

George


On 5/1/2020 1:19 PM, Christopher Lemmer Webber wrote:

Sorawee Porncharoenwase writes:

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

You don't even need to imagine it... when Python was taking off, one of
the biggest arguments was that it forced people to learn to do
reasonable indentation.  Doesn't seem like as much of a good argument
now as I thought it was then, and that's partly because most code is
indented fine these days due to, as you say, good IDE support.


The indentation requirement - aka "significant whitespace" - is one of 
the main things I dislike about Python [the other is its comprehension 
syntax].  An argument certainly can be made for advocating a readable 
coding style ... but on principle I disagree with a language *requiring* 
any particular style.



As it happens, I am old enough to remember when Fortran required very 
particular formatting: worse even than Python, Fortran was designed 
around 80-column punch cards, and for a VERY long time it was necessary 
that particular things be placed in particular columns ... else the 
statement would not compile.


    see https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html

Fortran's adherence to rigid source formatting really did not simplify 
the compiler much at all  (actually an argument can be made that it 
unnecessarily complicated recognizing certain constructs). And if it 
ever helped, it wasn't necessary for long - by 1962 [Fortran was 
introduced in 1959] compilers were able to deal with free form code.  
The first version of Lisp [1961] was on punch cards as well, but from 
the beginning Lisp never had column based restrictions on source format.


Fortran ... still recognizes the old style, but ... no longer requires 
column based formatting.  Free form source has been supported by 
compilers since Fortran90.


Historically, there have been a handful of (higher level, non-assembly) 
languages that had odd source formatting requirements, but none were as 
onerous as Fortran, and none of them survived very long.  But just as 
Fortran finally was giving up on the idea, Python came along to revive 
it.  [Python began at about the same time Fortran90 was in committee.]



Forcing programmers to do menial tasks like configuring editors to 
certain modes [spaces vs tabs], and to manually count spaces when 
corresponding scoped lines are too far apart to eyeball the vertical 
alignment is simply counterproductive - there are plenty of more 
important things that programmers should be worrying about. Programming 
editors having language structural awareness have been around since the 
80's ... there is no reason ever to bake such things as indentation 
requirements into the language.


Just my 2 cents.

--
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/e180703e-6e2e-ea6b-d918-b46ff4eebb07%40comcast.net.

Re: [racket-users] Questions about working on DrRacket and gui

[Matthew Flatt]

At Fri, 1 May 2020 16:59:22 +0200, Dexter Lagan wrote:
>   I'd like to download DrRacket's source and profile it, say to improve
> scrolling performance or track this post-startup lock-up :

Does the start-time delay happen if you just type a number and hit
return, as opposed to typing an identifier? If not, the delay is
probably in loading documentation as triggered the first time DrRacket
sees an identifier to look up.

> - Do I need to download the entire Racket tree in order to build DrRacket?

You can start with minimal Racket and install DrRacket, as Sorawee
said, but be aware that installing DrRacket will pull in most of a
normal Racket distribution, anyway.

> - Is the DrRacket's built-in profiler solid enough to handle profiling
> DrRacket itself?

Running DrRacket inside of DrRacket is not likely to give you useful
information for something like scrolling, because DrRacket shares the
GUI instance with programs that it runs.

Running DrRacket with `raco profile` is more promising. It doesn't work
as easily as it should, partly because DrRacket wants to be in control,
and partly because `raco profile` doesn't deal with the custodian being
changed or waiting for a GUI program to exit. But I was able to run it
by supplying this wrapper program to `raco profile`:

 #lang racket/base
 (require racket/gui/base)

 (define c (make-custodian))
 (define done (make-semaphore))

 (parameterize ([current-custodian c])
   (parameterize ([exit-handler
   (lambda (v)
 (semaphore-post done)
 (custodian-shutdown-all c))])
 (define e (make-eventspace))
 (parameterize ([current-eventspace e])
   (queue-callback (lambda () 
 ;; here's where we finally start DrRacket
 (dynamic-require 'drracket #f))

 (sync done)


> - Modules in DrRacket's repo don't always have very telling names. Is there
> a document describing what each module does?

There's nothing like that, as far as I know.

> - If I make a change to a source file on my system, yet somebody else
> modifies the same file on their local system. Say both of our changes are
> accepted by whoever manages commits, how will accepted changes to the code
> merged?

We use Git, which provides good tools for merging changes.

>   Also, say I have a suggestion regarding how DrRacket handles compiling
> standalone executables, do I still need to create an issue on its Github?
> For work I compile to standalone all day long, and I really wish DrRacket
> didn't zip the resulting file (it would be better to have the .exe file in
> an automatically created /bin or /output folder). Zipping the file takes
> time, and I have to unzip it each time, which takes more time, this piles
> up when done every few minutes, all day long. I could use raco exe, but I'd
> rather stay in DrRacket, and I'm sure many people would rather have the
> default behavior to not zip, just to have single responsibility on the
> compile function.

That sounds plausible for many cases. (In some cases, depending on the
platform and the program, there are unavoidably multiple output files.)

>  One last questions: I have encountered differences in the behavior of
> macros between the REPL, a launcher and a standalone executable for
> distribution. Is there a document outlining the deeper differences between
> these three ways of executing Racket code?

I think you're probably encountering differences in how the namespace
and module registry is set up for `eval` and/or `dynamic-require`.

Maybe you've already seen these, but if not, they're good starting
points:

  https://docs.racket-lang.org/guide/reflection.html

  https://docs.racket-lang.org/raco/exe.html
  (especially paragraphs 3 through 6 about modules)


-- 
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/5eac8218.1c69fb81.f0545.ba78SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

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

[Sage Gerard]

As long as I don't have to keep reorganizing my code to accommodate the 
tooling, then it's a night and day improvement. Would you mind terribly if I 
worked with you? I was mulling over this myself in the dev list, but I am happy 
to aid any existing effort.

 Original Message 
On May 1, 2020, 12:59 PM, Bogdan Popa wrote:

> Alex Harsanyi writes:
>
>> 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.
>
> I'm in a similar position since I operate a few Racket applications.
>
> I'd been mulling over the idea of a snapshotting service for the main
> package catalog to help automate some of this over the past couple of
> months, but this thread finally pushed me to get started on building it.
>
> More details here: https://github.com/bogdanp/racksnaps
>
> It's not quite ready for general use yet (the first snapshot is being
> built as we speak), but I should be able to iron out the kinks over the
> next couple of weeks.
>
> I'm curious what folks think about this approach.
>
> --
> 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/m2k11vmw0d.fsf%40192.168.0.142.

-- 
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/48J4XwYAvsHLrD7fsgD5_M1RutQcf_CobzsBJV-F5Ltg0i1YYIc4gf-9UMUN2QykF_a0drTjO5jiQ5-dcrGoO64AqrhKdD90Pse-TR28dOc%3D%40sagegerard.com.

[racket-users] ICFP 2020 will be held ONLINE Aug 23-28

['Sam Tobin-Hochstadt' via users-redirect]

The ICFP 2020 organizers would like to announce that the conference
and co-located events, originally scheduled for August 23-28, in
Jersey City, New Jersey, will now be held online during the same
dates. Further information for presenters, authors, attendees,
sponsors, and the ICFP community will be provided as it becomes
available.

  The ICFP Organizing Committee

-- 
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/5eac72f38c986_5b6e2b07d78345b4501e5%40homer.mail.

Re: [racket-users] a minor regexp question (and a how-could-I-answer-it-myself? question)

[David Storrs]

For the record, it's probably better to stick with #px in all cases.  The
vast majority of non-Racket code is based off the pcre library, which
stands for "Perl-compatible regular expressions" so if you stick with #px
the regex will be more familiar to more people.  Plus, standardizing on one
notation will eliminate bugs like the one you're seeing.

On Fri, May 1, 2020 at 9:50 AM Tim Hanson  wrote:

> Thanks, Jens, much appreciated. I suspect I even knew this once and had
> since forgotten it.
>
> (I even glanced at the docs, saw the two kinds, but didn’t pause long
> enough to wonder if it mattered to me.)
>
> --
> 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/69320674-8272-4751-a6ce-40c140a7358c%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/CAE8gKocP1FP4ufrQW%2BVyKYKHSmC3i-LWPvM9C0jekHLj1fqj3Q%40mail.gmail.com.

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

[Bogdan Popa]

Sam Tobin-Hochstadt writes:

> This is very cool! One question -- for "main-distribution" packages,
> are you snapshotting the most-recent release catalog? Or
> pkgs.racket-lang.org? The latter is simpler, but the former is
> probably needed to make the examples in the README work. Otherwise,
> if, say, "typed-racket-lib" on May 1 depended on a newer-than-7.6
> version of "base", using the snapshot first (or only the snapshot)
> would get you a version of "typed-racket-lib" that didn't work on 7.6.

At the moment, I'm snapshotting pkgs.racket-lang.org but not updating
packages from the main distribution.  That is, I start with the main
distribution of regular Racket 7.6 and add packages on top, but I don't
change any existing ones.

I think I can change the first example in the README to just

raco pkg config --set catalogs \
https://racksnaps.defn.io/snapshots/2020/05/01/catalog/ \
https://pkgs.racket-lang.org \
https://planet-compats.racket-lang.org

without changing the behavior.

-- 
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/m2h7wzmth6.fsf%40192.168.0.142.

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

[Sam Tobin-Hochstadt]

This is very cool! One question -- for "main-distribution" packages,
are you snapshotting the most-recent release catalog? Or
pkgs.racket-lang.org? The latter is simpler, but the former is
probably needed to make the examples in the README work. Otherwise,
if, say, "typed-racket-lib" on May 1 depended on a newer-than-7.6
version of "base", using the snapshot first (or only the snapshot)
would get you a version of "typed-racket-lib" that didn't work on 7.6.
I think that if you snapshot pkgs.racket-lang.org, then just adding
the 7.6 catalog before the snapshot catalog would work the way you
want, but I haven't fully thought through everything.

Sam

On Fri, May 1, 2020 at 12:59 PM Bogdan Popa  wrote:
>
>
> Alex Harsanyi writes:
>
> > 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.
>
> I'm in a similar position since I operate a few Racket applications.
>
> I'd been mulling over the idea of a snapshotting service for the main
> package catalog to help automate some of this over the past couple of
> months, but this thread finally pushed me to get started on building it.
>
> More details here: https://github.com/bogdanp/racksnaps
>
> It's not quite ready for general use yet (the first snapshot is being
> built as we speak), but I should be able to iron out the kinks over the
> next couple of weeks.
>
> I'm curious what folks think about this approach.
>
> --
> 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/m2k11vmw0d.fsf%40192.168.0.142.

-- 
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%2BaxH7A0UaM6xrwiawjGif%2B%2B%2B7E_3_giVd4Z-ArmMFhO2A%40mail.gmail.com.

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

[Christopher Lemmer Webber]

Sorawee Porncharoenwase writes:

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

You don't even need to imagine it... when Python was taking off, one of
the biggest arguments was that it forced people to learn to do
reasonable indentation.  Doesn't seem like as much of a good argument
now as I thought it was then, and that's partly because most code is
indented fine these days due to, as you say, good IDE support.

-- 
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/87a72rshcl.fsf%40dustycloud.org.

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

[Bogdan Popa]

Alex Harsanyi writes:

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

I'm in a similar position since I operate a few Racket applications.

I'd been mulling over the idea of a snapshotting service for the main
package catalog to help automate some of this over the past couple of
months, but this thread finally pushed me to get started on building it.

More details here: https://github.com/bogdanp/racksnaps

It's not quite ready for general use yet (the first snapshot is being
built as we speak), but I should be able to iron out the kinks over the
next couple of weeks.

I'm curious what folks think about this approach.

-- 
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/m2k11vmw0d.fsf%40192.168.0.142.

Re: [racket-users] Questions about working on DrRacket and gui

[Dexter Lagan]

  Thanks I’ll look into this.

Dex

> On May 1, 2020, at 5:03 PM, Sorawee Porncharoenwase  
> wrote:
> 
> 
> Sam just suggested me in the other email thread that a much easier way to do 
> things is to download and install Minimal Racket, then install DrRacket from 
> source.
> 
>> On Fri, May 1, 2020 at 7:59 AM Dexter Lagan  wrote:
>> Hi,
>> 
>>   I apologize in advance if my questions are naïve or have been asked 
>> previously. I read the 'Building Racket from Source' guide and couldn't find 
>> answers to some specific questions. I'm new to Git.
>> 
>>   I'd like to download DrRacket's source and profile it, say to improve 
>> scrolling performance or track this post-startup lock-up :
>> - Do I need to download the entire Racket tree in order to build DrRacket?
>> - Is the DrRacket's built-in profiler solid enough to handle profiling 
>> DrRacket itself?
>> - Modules in DrRacket's repo don't always have very telling names. Is there 
>> a document describing what each module does?
>> - If I make a change to a source file on my system, yet somebody else 
>> modifies the same file on their local system. Say both of our changes are 
>> accepted by whoever manages commits, how will accepted changes to the code 
>> merged?
>> 
>>   Also, say I have a suggestion regarding how DrRacket handles compiling 
>> standalone executables, do I still need to create an issue on its Github? 
>> For work I compile to standalone all day long, and I really wish DrRacket 
>> didn't zip the resulting file (it would be better to have the .exe file in 
>> an automatically created /bin or /output folder). Zipping the file takes 
>> time, and I have to unzip it each time, which takes more time, this piles up 
>> when done every few minutes, all day long. I could use raco exe, but I'd 
>> rather stay in DrRacket, and I'm sure many people would rather have the 
>> default behavior to not zip, just to have single responsibility on the 
>> compile function.
>> 
>>  One last questions: I have encountered differences in the behavior of 
>> macros between the REPL, a launcher and a standalone executable for 
>> distribution. Is there a document outlining the deeper differences between 
>> these three ways of executing Racket code?
>> 
>> Have a great weekend, wherever you're confined,
>> 
>> Dexter
>> -- 
>> 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/CACUENr%2B%3Drr87rehZHQyDX%2BusXBZHdCY_46-pkKTuotj6HRwffg%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/078809BB-8EA9-4C2A-B8C4-DD32FEADFF62%40gmail.com.

Re: [racket-users] Questions about working on DrRacket and gui

[Sorawee Porncharoenwase]

Sam just suggested me in the other email thread that a much easier way to
do things is to download and install Minimal Racket, then install DrRacket
from source.

On Fri, May 1, 2020 at 7:59 AM Dexter Lagan  wrote:

> Hi,
>
>   I apologize in advance if my questions are naïve or have been asked
> previously. I read the 'Building Racket from Source' guide and couldn't
> find answers to some specific questions. I'm new to Git.
>
>   I'd like to download DrRacket's source and profile it, say to improve
> scrolling performance or track this post-startup lock-up :
> - Do I need to download the entire Racket tree in order to build DrRacket?
> - Is the DrRacket's built-in profiler solid enough to handle profiling
> DrRacket itself?
> - Modules in DrRacket's repo don't always have very telling names. Is
> there a document describing what each module does?
> - If I make a change to a source file on my system, yet somebody else
> modifies the same file on their local system. Say both of our changes are
> accepted by whoever manages commits, how will accepted changes to the code
> merged?
>
>   Also, say I have a suggestion regarding how DrRacket handles compiling
> standalone executables, do I still need to create an issue on its Github?
> For work I compile to standalone all day long, and I really wish DrRacket
> didn't zip the resulting file (it would be better to have the .exe file in
> an automatically created /bin or /output folder). Zipping the file takes
> time, and I have to unzip it each time, which takes more time, this piles
> up when done every few minutes, all day long. I could use raco exe, but I'd
> rather stay in DrRacket, and I'm sure many people would rather have the
> default behavior to not zip, just to have single responsibility on the
> compile function.
>
>  One last questions: I have encountered differences in the behavior of
> macros between the REPL, a launcher and a standalone executable for
> distribution. Is there a document outlining the deeper differences between
> these three ways of executing Racket code?
>
> Have a great weekend, wherever you're confined,
>
> Dexter
>
> --
> 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/CACUENr%2B%3Drr87rehZHQyDX%2BusXBZHdCY_46-pkKTuotj6HRwffg%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/CADcuegsm%2BiZV10KtB46jG%2B2-jAj4Hktotd%3DuXT9zO9bQ_5p78A%40mail.gmail.com.

[racket-users] Questions about working on DrRacket and gui

[Dexter Lagan]

Hi,

  I apologize in advance if my questions are naïve or have been asked
previously. I read the 'Building Racket from Source' guide and couldn't
find answers to some specific questions. I'm new to Git.

  I'd like to download DrRacket's source and profile it, say to improve
scrolling performance or track this post-startup lock-up :
- Do I need to download the entire Racket tree in order to build DrRacket?
- Is the DrRacket's built-in profiler solid enough to handle profiling
DrRacket itself?
- Modules in DrRacket's repo don't always have very telling names. Is there
a document describing what each module does?
- If I make a change to a source file on my system, yet somebody else
modifies the same file on their local system. Say both of our changes are
accepted by whoever manages commits, how will accepted changes to the code
merged?

  Also, say I have a suggestion regarding how DrRacket handles compiling
standalone executables, do I still need to create an issue on its Github?
For work I compile to standalone all day long, and I really wish DrRacket
didn't zip the resulting file (it would be better to have the .exe file in
an automatically created /bin or /output folder). Zipping the file takes
time, and I have to unzip it each time, which takes more time, this piles
up when done every few minutes, all day long. I could use raco exe, but I'd
rather stay in DrRacket, and I'm sure many people would rather have the
default behavior to not zip, just to have single responsibility on the
compile function.

 One last questions: I have encountered differences in the behavior of
macros between the REPL, a launcher and a standalone executable for
distribution. Is there a document outlining the deeper differences between
these three ways of executing Racket code?

Have a great weekend, wherever you're confined,

Dexter

-- 
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/CACUENr%2B%3Drr87rehZHQyDX%2BusXBZHdCY_46-pkKTuotj6HRwffg%40mail.gmail.com.

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

[Laurent]

For your second point, you can never really know what other work depends on
your package. You could display a message in the new package or in the
readme for example, but that's likely not going to work well for
various reasons. (but see my last comment)

However, what Jay is saying I believe (correct me if I'm wrong), is that
you can just create a tag for the previous version, modify your current
package 'my-package' on the pkg server to refer to that tag, and create a
new package 'my-package2' on the pkg server pointing to master. The pkg
catalog is going to be cluttered with all backward-incompatible version
numbers but a) Jay doesn't seem to be worried about that b) it's currently
not the case (meaning, people don't do that currently, but maybe they
should?).

Old users won't see the breaking change, and new users will see and use the
new version on the catalog (or clone directly from github). What's missing
again is a way to tell old users that a new package is available with new
features, but I think Jay was saying some time ago that this should be the
purpose of mailing lists and other media.



On Fri, May 1, 2020 at 2:23 PM Hendrik Boom  wrote:

> On Fri, May 01, 2020 at 06:12:55AM -0700, Jesse Alama wrote:
> > On Thursday, April 30, 2020 at 2:57:45 PM UTC+2, Jay McCarthy wrote:
> > >
> > >
> > > 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.
> > >
> >
> > I'd like to second this point. There's nothing stopping you from pushing
> > whatever you want to your repo, and hence distributing whatever you want
> > via the package server. I've pushed breaking changes to my packages
> before,
> > and no one has complained, so I guess I didn't break any part of the
> > interface that they were using. (Or I have no users of my stuff at all,
> > which is certainly possible!)
> >
> > I don't know how many packages mention, in their description, that
> they're
> > experimental, explicitly warning me that the interface is unstable and
> > likely to change. I use 'em anyway because they offer useful
> functionality.
> > I don't recall being nailed by breaking changes, but perhaps I'm just
> > getting lucky.
> >
> > What exactly is the claim, anyway, about the package server not allowing
> > breaking changes? Is it that if you do a breaking change to your
> package,
> > then it's possible that other people's packages correspondingly break?
> If
> > so, then I think that's not a very interesting claim. Does the claim at
> > issue just amount to a restatement of the ethos that Jay mentioned about
> > trying to ensure backwards compatibility for a long time?
> >
> > (All this said, I'd like to learn more about setting up custom package
> > catalogs, as Alex mentioned, to take matters even more into your own
> hands.)
>
> Is there a mechanism for, when you know you are making a breaking change
> in a package, at least being warned about other packages that may break
> as a result?
>
> And is there a mechanism for testing those other packages before
> committing your breaking package to the public repository?
>
> -- 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/04ebf61c-54b3-4f58-96aa-f5bdc5f2b457%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/20200501132344.4nwjgebdlyttwkzu%40topoi.pooq.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/CABNTSaGQGFVL%3D4jhaV6WJH6b5QU52rfk-rJ4mbrhvCntO2AZDQ%40mail.gmail.com.

Re: [racket-users] a minor regexp question (and a how-could-I-answer-it-myself? question)

[Tim Hanson]

Thanks, Jens, much appreciated. I suspect I even knew this once and had since 
forgotten it.

(I even glanced at the docs, saw the two kinds, but didn’t pause long enough to 
wonder if it mattered to me.)

-- 
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/69320674-8272-4751-a6ce-40c140a7358c%40googlegroups.com.

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

[Hendrik Boom]

On Fri, May 01, 2020 at 06:12:55AM -0700, Jesse Alama wrote:
> On Thursday, April 30, 2020 at 2:57:45 PM UTC+2, Jay McCarthy wrote:
> >
> >
> > 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.
> >
> 
> I'd like to second this point. There's nothing stopping you from pushing 
> whatever you want to your repo, and hence distributing whatever you want 
> via the package server. I've pushed breaking changes to my packages before, 
> and no one has complained, so I guess I didn't break any part of the 
> interface that they were using. (Or I have no users of my stuff at all, 
> which is certainly possible!)
> 
> I don't know how many packages mention, in their description, that they're 
> experimental, explicitly warning me that the interface is unstable and 
> likely to change. I use 'em anyway because they offer useful functionality. 
> I don't recall being nailed by breaking changes, but perhaps I'm just 
> getting lucky.
> 
> What exactly is the claim, anyway, about the package server not allowing 
> breaking changes? Is it that if you do a breaking change to your package, 
> then it's possible that other people's packages correspondingly break? If 
> so, then I think that's not a very interesting claim. Does the claim at 
> issue just amount to a restatement of the ethos that Jay mentioned about 
> trying to ensure backwards compatibility for a long time?
> 
> (All this said, I'd like to learn more about setting up custom package 
> catalogs, as Alex mentioned, to take matters even more into your own hands.)

Is there a mechanism for, when you know you are making a breaking change 
in a package, at least being warned about other packages that may break 
as a result?

And is there a mechanism for testing those other packages before 
committing your breaking package to the public repository?

-- 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/04ebf61c-54b3-4f58-96aa-f5bdc5f2b457%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/20200501132344.4nwjgebdlyttwkzu%40topoi.pooq.com.

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

[Hendrik Boom]

On Thu, Apr 30, 2020 at 02:40:00PM -0700, Sorawee Porncharoenwase wrote:
> 
> This is Nia's parendown: https://docs.racket-lang.org/parendown/index.html

Just wondering:  Is there a way to write division if Nia's parendown is in 
effect?
There would be no problem with this if it was originally designed into the 
language,
but language add-ons give the probem of syntax-versus-name confliicts.

-- 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/20200501131750.seligwkp7zifoddu%40topoi.pooq.com.

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

[Jesse Alama]

On Thursday, April 30, 2020 at 2:57:45 PM UTC+2, Jay McCarthy wrote:
>
>
> 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.
>

I'd like to second this point. There's nothing stopping you from pushing 
whatever you want to your repo, and hence distributing whatever you want 
via the package server. I've pushed breaking changes to my packages before, 
and no one has complained, so I guess I didn't break any part of the 
interface that they were using. (Or I have no users of my stuff at all, 
which is certainly possible!)

I don't know how many packages mention, in their description, that they're 
experimental, explicitly warning me that the interface is unstable and 
likely to change. I use 'em anyway because they offer useful functionality. 
I don't recall being nailed by breaking changes, but perhaps I'm just 
getting lucky.

What exactly is the claim, anyway, about the package server not allowing 
breaking changes? Is it that if you do a breaking change to your package, 
then it's possible that other people's packages correspondingly break? If 
so, then I think that's not a very interesting claim. Does the claim at 
issue just amount to a restatement of the ethos that Jay mentioned about 
trying to ensure backwards compatibility for a long time?

(All this said, I'd like to learn more about setting up custom package 
catalogs, as Alex mentioned, to take matters even more into your own hands.)

-- 
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/04ebf61c-54b3-4f58-96aa-f5bdc5f2b457%40googlegroups.com.

Re: [racket-users] a minor regexp question (and a how-could-I-answer-it-myself? question)

[Jens Axel Søgaard]

Den fre. 1. maj 2020 kl. 14.20 skrev Tim Hanson :

> hi, just now I'm debugging a regular expression and trying to understand
> why this:
>
>   > (regexp-match-positions #rx"[-+][0-9]+" "-0500")
>   '((0 . 5))
>
> works as I expect, whereas this:
>
>   > (regexp-match-positions #rx"[-+][0-9]{4}" "-0500")
>   #f
>
> doesn't. (My naive opinion is the second expression should return the same
> answer as the first.)
>

The cause of the confusion is that there are several notations for regular
expressions.
Racket supports two types "egrep" and "Perl" ones.
Turns out the repetition syntax with braces {} are only supported in Perl
regular expressions.
Therefore you need to use #px rather than #rx.

The relevant section of the documentation:

[image: image.png]



> Wondering whether I could discover for myself whether this is a known
> issue, I found directly:
>
>   https://github.com/racket/racket/search?q=regexp&type=Issues
>
> or perhaps something like this:
>
>
> https://github.com/racket/racket/search?q=regexp+type%3Aissue&unscoped_q=regexp+type%3Aissue
>
> is better, but either way I'm quickly pretty lost in terms of deciding
> whether this relates to a known issue.
>

You need to look at docs.racket-lang.org instead. Then search for "regexp"
or "regular expression".
You will then end up here:

https://docs.racket-lang.org/reference/regexp.html?q=regular%20expression

Also ... if it is any consolation ... you are not the first to be confused
by this.

/Jens Axel

Racket Stories
https://racket-stories.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/CABefVgx%3D9iTX5op3G4KaJ5Wt2dNDcOVE%2BWV%3DJ3jct_JEWDnEKQ%40mail.gmail.com.

[racket-users] a minor regexp question (and a how-could-I-answer-it-myself? question)

[Tim Hanson]

hi, just now I'm debugging a regular expression and trying to understand why 
this:

  > (regexp-match-positions #rx"[-+][0-9]+" "-0500")
  '((0 . 5))

works as I expect, whereas this:

  > (regexp-match-positions #rx"[-+][0-9]{4}" "-0500")
  #f

doesn't. (My naive opinion is the second expression should return the same 
answer as the first.)



Wondering whether I could discover for myself whether this is a known issue, I 
found directly:

  https://github.com/racket/racket/search?q=regexp&type=Issues

or perhaps something like this:

  
https://github.com/racket/racket/search?q=regexp+type%3Aissue&unscoped_q=regexp+type%3Aissue

is better, but either way I'm quickly pretty lost in terms of deciding whether 
this relates to a known issue.


I'd appreciate advice on either question.

-- 
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/061c9f78-0ffe-4a5e-be12-10518d70c413%40googlegroups.com.