Re: [racket-users] Would it help to call racket2 something else?

[evdubs]

If "racket" is related to "scheme" by being an illegitimate scheme, I think 
"cartel" could be a good choice for "an even more illegitimate scheme". Plus, 
it's almost an anagram of racket.

#lang cartel

-- 
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/2d72c920-fbad-4916-a5a0-8d513c7623ef%40googlegroups.com.

Re: [racket-users] Re: third-party package tips and developer concerns (Was: New version of file-watchers)

[Sage Gerard]

Thanks for the clarification, Neil! Your feedback does help a great deal. I'll 
also be happy to share updates with a respectful frequency now that I see the 
other replies. :)


~slg

‐‐‐ Original Message ‐‐‐
On Saturday, August 31, 2019 1:04 PM, Hendrik Boom  
wrote:

> On Sat, Aug 31, 2019 at 02:45:02PM +, Sage Gerard wrote:
>
> > I looked back and found my mistake: I only asked about blog posts and 
> > videos. I'll refrain from version update posts here from now on.
>
> Whatever you originally asked for, I think this ensuing discussion about
> third-party packages is valuable.
>
> -- 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/20190831170409.w64sibufwjzy%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/C3hKrfTOC_VR-7WCAjpmUzyiqKlD3mZ_jLQUgo1_AbPLwQms54XQlCeTDPi6MPlJUxxg7zKtDeZwr0wMfpyBNwWCfn9Qx8Csw26HO9Uegnk%3D%40sagegerard.com.

Re: [racket-users] Re: third-party package tips and developer concerns (Was: New version of file-watchers)

[Hendrik Boom]

On Sat, Aug 31, 2019 at 02:45:02PM +, Sage Gerard wrote:
> I looked back and found my mistake: I only asked about blog posts and videos. 
> I'll refrain from version update posts here from now on.

Whatever you originally asked for, I think this ensuing discussion about 
third-party packages is valuable. 

-- 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/20190831170409.w64sibufwjzy%40topoi.pooq.com.

Re: [racket-users] Re: third-party package tips and developer concerns (Was: New version of file-watchers)

[Neil Van Dyke]

Sage Gerard wrote on 8/31/19 10:38 AM:

You probably don't want to be slowing yourself down with offering people 
previews of new versions, lead times for input, etc.

I'm unknown in open source so


I think all of us in Racket land are pretty much unknown in open source 
(outside of Racket/Scheme). :)



creating as many opportunities as possible for feedback is valuable enough to 
be worth the effort.


OK, if you want the input, or are willing to do that extra work, that's 
great.  I only meant it as I said it: I wanted people considering being 
third-party package developers to know they weren't obligated to take on 
that extra burden if they don't want to.



Re: deprecation, I strongly believe that less code is better, and I hope that I 
can draw compromises with users on doing things like remove redundant 
functionality on my own.


That sounds reasonable to me, if that's how you want to do it for your 
packages.


If a third-party package developer expects to possibly break 
backward-compatibility in the future, it might make sense for them to 
indicate that near the top of their package documentation.  That makes 
the social contract more clear.


(I don't think there was much buy-in on that backwards-compatibility 
policy for third-party packages, which was handed down to replace the 
lost PLaneT version support.  It was core-centric, and burdensome to 
third-party developers who are doing rapid/agile 
research/move-fast-and-break-things, and/or open-sourcing parts of a 
system on which they do things like global refactoring, and want to be 
able to make backward-incompatible changes to their code.)



the style guide


That style guide applies only to the code of core Racket itself, not to 
third-party packages.  You can look at it for ideas, or adopt it as a 
bible, if you want, but do your own code however you like.



I think a general theme in these comments is to encourage important and 
sensible things for package developers (e.g., create package metadata 
and catalog entry, do a versioned release of some kind, consider 
including documentation and tests, consider naming things to work well 
with doc search and code readability), but not burdens that people will 
often either ignore or find too discouraging to do anything at all 
(e.g., you don't have to format your code a certain way, you don't have 
to preserve backward compatibility with each version, you don't have to 
Scribble).


--
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/2355bc5c-09da-5c46-b002-2ae03c69329f%40neilvandyke.org.

[racket-users] [standard-fish] Update: small house facade, with attribute handling code

[Hendrik Boom]

Today's version, together with a new README.md file describing my 
longer-term intentions, rather than what the program dies right now.

The code resides on a monotone repository on my server, which I hope to 
figure out how to make publically accessible.

I haven't written a formal copyrght notice; but I am hereby delaring 
it's free software, and will probably be released under the GPL or MIT 
licence.  Advice welcome.

Though I suspect no one much will develop anything using it, but maybe 
use it as an insperation for something completely different.

-- hendrik

On Sat, Aug 24, 2019 at 08:27:34AM -0400, Hendrik Boom wrote:
> door.rkt draws a picture of a small house, with a door and windows.
> Different picture each time you run it.
> 
> The bulk of the code is there to handle attributes (like colours and 
> sizes) in an association list, so that you can establish defaults and 
> the like.
> 
> One thing I know is that the attribute-handling code isn't right yet, 
> and follows different conventions in different parts of it.
> 
> Sometimes I have multipls versions of a function that are identical 
> except for using different argument conventions.
> 
> It's still very much in a state of flux.
> 
> Suggestions very welcome.
> 
> -- 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/20190824122733.ov2gfaerxsgl5ajz%40topoi.pooq.com.

> #lang racket
> (require pict)
> (require racket/gui/base)
> (require racket/random)
> 
> (define (show tag thing) (print (cons tag thing)) thing)
> 
> ; (list 'random (random 1 10) (random 1 2) (random 1 234))
> ; (list 'chosen (random-ref '(a b c d e f)))
> ; (list 'nope)
> ; (show 'showtest 'showdatum)
> 
> 
> ; Attribute management
> 
> 
> ; ali is an environment.  It should contain all the parameters that are neede 
> to make a typical whatever (at the moment, the whatever is a door.)
> ;  At the moment, also, it allows attributes to be defined as functions; at 
> lookup time the entire association list is passed to the function so that its 
> value can depend on other (not necessarily previous) parameters.
> 
> ; This mechanism was originally introduced for flexibility, but is being used 
> mainly to implement the freeze operation.
> 
> (define (looker name ali succeed fail)
>   (letrec (
>   (lookup2 (lambda (name aa succeed fail)
> (if (eq? aa '())
>   (fail)
>   (if (eq? name (caar aa))
> (let ((value (cdar aa)))
>   (if (procedure? value)
> (succeed (value ali))
> (succeed value)
>   )
>   )
> (lookup2 name (cdr aa) succeed fail)
>   )
> )
>   )))
> (lookup2 name ali succeed fail)
>   )
> )
> 
> (define (lookup name ali fail)
>   (looker name ali (lambda (result) result) fail)
> )
> (define (old lookup name ali fail)
>   (letrec (
>   (lookup2 (lambda (name aa fail)
> (if (eq? aa '())
>   (fail)
>   (if (eq? name (caar aa))
> (let ((value (cdar aa)))
>   (if (procedure? value)
> (value ali)
> value
>   )
>   )
> (lookup2 name (cdr aa) fail)
>   )
> )
>   )))
> (lookup2 name ali fail)
>   )
> )
> 
> (define (binda name value a) (cons (cons name value) a))
> 
> (define (bind name value object)
>   (lambda (a)
> (object (binda name value a))
>   )
> )
> 
> ; Freezing is a mechanism for choosing parameters to be passed down to more 
> local objects, so, for example, we can set a style for all he windows in a 
> house, but allow each house to have its own style for windoess.  This is 
> accomplished by having the window-style be a function instead of a value.  
> The freeze calls the function and rebids the name to the result of that 
> function.  The resulting associon list is passed down to lower objects.
> 
> (define (freezea name a)
>   (let ((value (lookup name a (lambda () '()
> (if (eq? value '()) a (binda name value a
> 
> ; Got the wrong definition for lookup.  Need a way after the lookup to base 
> decision on its success.  Returning '() in't enough.  I wonder what the right 
> definition is.
> 
> (define (freeze name f a)
>   ( let (( value (lookup name a (lambda () '())) ))
> (if (eq? value '())
>   f
>   (lambda (a) (f (binda name value a)))
> )
>   )
> )
> 
> (define (freezeo name object)
>   ( lambda (a)
> (let (( value (lookup name a (lambda () '())) ))
> (if (eq? value '())
>   (object a)
>   (object (binda name value a))
> )
>   ))
> )
> 
> (define (with a name value) (cons (cons name value) a))
> 
> 
> ;  Graphics combinators
> 

Re: [racket-users] Re: third-party package tips and developer concerns (Was: New version of file-watchers)

[Sage Gerard]

I looked back and found my mistake: I only asked about blog posts and videos. 
I'll refrain from version update posts here from now on.


~slg

‐‐‐ Original Message ‐‐‐
On Saturday, August 31, 2019 10:38 AM, Sage Gerard  wrote:

> Hi Neil, and thanks for the helpful information and historical context.
>
> I do have some follow up questions if that's alright, because I want to make 
> the most out of my time here and it seems like you can clarify that.
>
> > You probably don't want to be slowing yourself down with offering people 
> > previews of new versions, lead times for input, etc.
>
> I'm unknown in open source so creating as many opportunities as possible for 
> feedback is valuable enough to be worth the effort. On Aug 25th I asked on 
> this list if regular updates would come off as bad etiquette or unwanted 
> solicitation, and the answer I got seemed to suggest that it would be 
> alright. By the subject line of the email it seems that the thread was 
> cannibalized. It seems I misinterpreted the earlier answer, and for that I 
> apologize.
>
> > Identifier naming
>
> I felt the pain over the identifier xexpr->string. I personally didn't 
> particularly mind using prefix-in to address it, but I chalked it up to how 
> namespaces were designed and went with it.
>
> But I'm wondering: How much do volunteers have to change the way they work 
> due to technical limitations out of their control? I understand that to the 
> extent that these are not my servers and other people are impacted by what I 
> put out. Where I get lost is that--from what I can tell--this is a community 
> of people who wish to work in ways that other designers might not approve and 
> I thought the ecosystem wouldn't raise a flag over a provided name.
>
> > When you do want to break the interfaces, there's currently no great way.
>
> I'm already seeing a pattern here: Do technical limitations define governance 
> of volunteers?
>
> To put it another way, do you allow design limitations to draw a hard line 
> between regulating contributions and allowing contributors to have their own 
> way of doing things?
>
> Re: deprecation, I strongly believe that less code is better, and I hope that 
> I can draw compromises with users on doing things like remove redundant 
> functionality on my own. If several months notice for removal is another 
> thing that raises a flag, then I'll refresh myself on the style guide and of 
> course take your suggestions to heart to improve the experience for everyone.
>
> But... I do also want my way of working (for free, no less) to be welcome to 
> the greatest extent possible. What can I do to give myself and other 
> volunteers that space?
>
> ~slg
>
> ‐‐‐ Original Message ‐‐‐
> On Saturday, August 31, 2019 7:00 AM, Neil Van Dyke n...@neilvandyke.org 
> wrote:
>
> > First, to Sage, thank you for going to the work to open source
> > third-party packages like this.
> > Here are a few suggestions that came to mind from this post, which I'd
> > like to mention to Racket third-party package developers in general.
> > (Only suggestions, not presuming to tell anyone what to do; just
> > avoiding real work this early Saturday morning. :)  Also, as I was
> > writing this, I realized one of the points is an opportunity to give
> > some context on recent governance concerns.
> > Note that some of these suggestions are biased to a development approach
> > that encourages developing all software in such a way that there's often
> > low friction to project/organization-internal component reuse, or even
> > to selectively open-sourcing individual modules.
> >
> > -   Normally, you'll be developing your own large systems, and a given
> > open source package will just be a small part of it, and you might have
> > many such open source packages.  You probably don't want to be slowing
> > yourself down with offering people previews of new versions, lead times
> > for input, etc. -- when you're ready to push a new version, just do it. 
> > There are other mechanisms for not breaking users of your package.  Of
> > course you can ask for input if you're contemplating big or breaking
> > changes, and not sure what to do.
> >
> > -   Try not to make identifiers be simple generic terms, like `watch`,
> > that might better be used for key language features, or in users' own
> > programs.  (Note that, historically in Racket, there was an idea that
> > modules might provide such simple generic identifiers, and then modules
> > using them would add a prefix or otherwise transform them. But that had
> > a couple problems: it was more work for the module user in practice, and
> > it also meant that reading unfamiliar code or looking up unfamiliar
> > identifiers in documentation/Google search was harder.  There will
> > always be a lot of name collisions in Racket documentation search of
> > core Racket and whatever third-party modules are 

[racket-users] Re: third-party package tips and developer concerns (Was: New version of file-watchers)

[Sage Gerard]

Hi Neil, and thanks for the helpful information and historical context.

I do have some follow up questions if that's alright, because I want to make 
the most out of my time here and it seems like you can clarify that.

> You probably don't want to be slowing yourself down with offering people 
> previews of new versions, lead times for input, etc.

I'm unknown in open source so creating as many opportunities as possible for 
feedback is valuable enough to be worth the effort. On Aug 25th I asked on this 
list if regular updates would come off as bad etiquette or unwanted 
solicitation, and the answer I got seemed to suggest that it would be alright. 
By the subject line of the email it seems that the thread was cannibalized. It 
seems I misinterpreted the earlier answer, and for that I apologize.

> Identifier naming

I felt the pain over the identifier xexpr->string. I personally didn't 
particularly mind using prefix-in to address it, but I chalked it up to how 
namespaces were designed and went with it.

But I'm wondering: How much do volunteers have to change the way they work due 
to technical limitations out of their control? I understand that to the extent 
that these are not my servers and other people are impacted by what I put out. 
Where I get lost is that--from what I can tell--this is a community of people 
who wish to work in ways that other designers might not approve and I thought 
the ecosystem wouldn't raise a flag over a provided name.

>  When you do want to break the interfaces, there's currently no great way.

I'm already seeing a pattern here: Do technical limitations define governance 
of volunteers?

To put it another way, do you allow design limitations to draw a hard line 
between regulating contributions and allowing contributors to have their own 
way of doing things?

Re: deprecation, I strongly believe that less code is better, and I hope that I 
can draw compromises with users on doing things like remove redundant 
functionality on my own. If several months notice for removal is another thing 
that raises a flag, then I'll refresh myself on the style guide and of course 
take your suggestions to heart to improve the experience for everyone.

But... I do also want my way of working (for free, no less) to be welcome to 
the greatest extent possible. What can I do to give myself and other volunteers 
that space?

~slg

‐‐‐ Original Message ‐‐‐
On Saturday, August 31, 2019 7:00 AM, Neil Van Dyke  
wrote:

> First, to Sage, thank you for going to the work to open source
> third-party packages like this.
>
> Here are a few suggestions that came to mind from this post, which I'd
> like to mention to Racket third-party package developers in general.
> (Only suggestions, not presuming to tell anyone what to do; just
> avoiding real work this early Saturday morning. :)  Also, as I was
> writing this, I realized one of the points is an opportunity to give
> some context on recent governance concerns.
>
> Note that some of these suggestions are biased to a development approach
> that encourages developing all software in such a way that there's often
> low friction to project/organization-internal component reuse, or even
> to selectively open-sourcing individual modules.
>
> -   Normally, you'll be developing your own large systems, and a given
> open source package will just be a small part of it, and you might have
> many such open source packages.  You probably don't want to be slowing
> yourself down with offering people previews of new versions, lead times
> for input, etc. -- when you're ready to push a new version, just do it. 
> There are other mechanisms for not breaking users of your package.  Of
> course you can ask for input if you're contemplating big or breaking
> changes, and not sure what to do.
>
> -   Try not to make identifiers be simple generic terms, like `watch`,
> that might better be used for key language features, or in users' own
> programs.  (Note that, historically in Racket, there was an idea that
> modules might provide such simple generic identifiers, and then modules
> using them would add a prefix or otherwise transform them. But that had
> a couple problems: it was more work for the module user in practice, and
> it also meant that reading unfamiliar code or looking up unfamiliar
> identifiers in documentation/Google search was harder.  There will
> always be a lot of name collisions in Racket documentation search of
> core Racket and whatever third-party modules are installed, but
> non-generic names improves that in a worse-is-better kind of way.)
>
> -   Of course, you can name your identifiers however you want, and you
> might want to make them fairly descriptive, in the scope of all Racket
> packages.  One convention that sometimes (not always) seems good is to
> include the package name in each exported identifier, which helps search
> and recognizing 

[racket-users] third-party package tips and developer concerns (Was: New version of file-watchers)

[Neil Van Dyke]

First, to Sage, thank you for going to the work to open source 
third-party packages like this.


Here are a few suggestions that came to mind from this post, which I'd 
like to mention to Racket third-party package developers in general. 
(Only suggestions, not presuming to tell anyone what to do; just 
avoiding real work this early Saturday morning. :)  Also, as I was 
writing this, I realized one of the points is an opportunity to give 
some context on recent governance concerns.


Note that some of these suggestions are biased to a development approach 
that encourages developing all software in such a way that there's often 
low friction to project/organization-internal component reuse, or even 
to selectively open-sourcing individual modules.


* Normally, you'll be developing your own large systems, and a given 
open source package will just be a small part of it, and you might have 
many such open source packages.  You probably don't want to be slowing 
yourself down with offering people previews of new versions, lead times 
for input, etc. -- when you're ready to push a new version, just do it.  
There are other mechanisms for not breaking users of your package.  Of 
course you can ask for input if you're contemplating big or breaking 
changes, and not sure what to do.


* Try not to make identifiers be simple generic terms, like `watch`, 
that might better be used for key language features, or in users' own 
programs.  (Note that, historically in Racket, there was an idea that 
modules might provide such simple generic identifiers, and then modules 
using them would add a prefix or otherwise transform them. But that had 
a couple problems: it was more work for the module user in practice, and 
it also meant that reading unfamiliar code or looking up unfamiliar 
identifiers in documentation/Google search was harder.  There will 
always be a lot of name collisions in Racket documentation search of 
core Racket and whatever third-party modules are installed, but 
non-generic names improves that in a worse-is-better kind of way.)


* Of course, you can name your identifiers however you want, and you 
might want to make them fairly descriptive, in the scope of all Racket 
packages.  One convention that sometimes (not always) seems good is to 
include the package name in each exported identifier, which helps search 
and recognizing which package an identifier comes from when reading 
code, and also reduces name collisions between packages.  For example, I 
think every identifier from the `roomba` package contains `roomba` in 
its name (and if you wanted shorter names for this package, to make it 
more like, say, Logo turtle graphics, that might be a `#lang`), 
"https://www.neilvandyke.org/racket/roomba/  That convention might not 
be appropriate for `file-watchers`, but I just wanted to mention it, 
because it seems to often help.


* Try not to remove deprecated interfaces from within a package, unless 
keeping them is a significant burden for you.  You can move the 
documentation for them to some dark corner of the manual (like the end 
of the manual, or end of a section), and use the `deprecated` Scribble 
procedure on them.  But if it's practical to keep them in, that reduces 
breaking users of your modules.  Think of a little deprecated API as 
like scars of a battle-tested and enduring package.


* When you do want to break the interfaces, there's currently no great 
way.  Racket's original PLaneT package system had a very simple yet very 
nice SemVer-like versioning system that some third-party package authors 
used,[1] and multiple versions of the same package could be installed at 
once.  That was particularly helpful for low-encumbrance third-party 
packages.  Users of the package could keep using the old version until 
they were ready to make changes to use the new one, and the package 
developer (usually altruistically releasing some part of their system 
that was their real job) wasn't unduly burdened.  And being able to have 
multiple versions of a package installed at once could often (though not 
always) let you move incrementally, of packages you control, and from 
the graph of interdependent third-party packages you use.  With the new 
package system, that version-related functionality was lost, and it was 
emphasized as policy that new package versions should always be 
backwards compatible, and if you wanted to break an interface, you 
should make a new package (with a new name).  Losing that various 
version-related functionality made sense for core Racket's policy change 
to support backward-compatibility, but I think it didn't make sense for 
the breadth of third-party developers for whom we'd like to encourage 
low-friction release and updating of their packages.[2]



[1] See 
"http://planet.racket-lang.org/display.ss?package=javascript.plt=dherman;, 
which was up non-backward-compatible version 9.  Dave Herman was able to 
keep doing his work, but also keep releasing new 

Re: [racket-users] Persistent job queue

[Bogdan Popa]

> I haven't been able to find a persistent job queue for Racket, so I thought
> I'd ask if one exists before writing a simple one. I did see Jay's job
> queue package, but it doesn't appear to persist to disk, and that is a
> requirement.

FWIW, I am working on a new Redis client package[1] that should be
complete sometime next week and I have a little task queue example
here[2] based on Redis streams.

I plan on writing a task queueing library in the future based on this
client (I have some experience with the problem domain[3]), but it may
be a while before I get to it.

> I typically use Postgres for my apps, and I would prefer to also use
> Postgres for the persistence of the job queue to avoid introducing
> something new (e.g. Redis) to my server setup. Amazon RDS provides great
> multi-site availability, so I want to continue to leverage that.

Recent versions of Postgres make this pretty easy to do so you might not
need a library.  Here's a little snippet from one of my older Racket
applications that uses a Postgres table as a persistent task queue, in
case it helps:

https://gist.github.com/Bogdanp/c796b15a0fa8d577a5f46ff25230baa6



[1]: https://github.com/Bogdanp/racket-redis
[2]: https://github.com/Bogdanp/racket-redis/tree/master/examples/task-queue
[3]: https://dramatiq.io

-- 
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/m2d0glkbpr.fsf%40192.168.0.139.

Re: [racket-users] New version of file-watchers

[Stephen De Gabrielle]

Awesome -thank you for releasing this.

s.


On Wed, Aug 28, 2019 at 11:30 PM Sage Gerard  wrote:

> Version 0.2 of the file monitoring package file-watchers is about to
> drop. Here's a PR for public review. There are no contributors, so I plan
> to merge in 48 hours if there is no feedback. Otherwise I'll play it by
> ear. https://github.com/zyrolasting/file-watchers/pull/4
>
> The new release upgrades the CLI and the public API. Highlights:
>
>- The CLI provides cleaner feedback on what ends the process.
>- All file monitoring approaches can now target individual files as
>well as directories. Earlier only directories could be specified, which
>make it hard to ignore files.
>- (watch-directories) is deprecated in favor of (watch), which
>supports files and directories. The former will be removed after Jan 1st
>2020.
>
> *~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/GDZKfX5RNbeKTSVXJg7DaBOp9MqBqz84s_-fuZ8reIHqUr1ewKclTSq7VDq8kYq17Bc466KH85pRVh6QD_r6T1C8MDRdWqFfYS_-Jfby9wQ%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/CAGHj7-KATVg-Ha7yqgk9o2iQ7N2806HK2mwai0Eo-_Mj%3DJ10sg%40mail.gmail.com.

Re: [racket-users] [racket users] make-keyword-procedure follow-up

[Jack Firth]

You might have some success using my arguments 
 package, which defines 
an arguments? data structure wrapping a bundle of positional and keyword 
args. It also provides some functions that are like make-keyword-procedure 
and keyword-apply, but with a nicer interface based on the arguments 
structure:

> (apply/arguments sort
   (arguments '("fo" "bar" "bazz") < #:key 
string-length))
'("bar" "bazz" "fo")
> (define/arguments (keywords-product args)
(for/product ([(k v) (in-hash (arguments-keyword args))])
  v))
> (keywords-product #:foo 2 #:bar 3)
6
> (keywords-product 'ignored #:baz 6 #:blah 4)
24

-- 
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/83554d22-5863-4aa8-9d62-cbf6caef14c2%40googlegroups.com.