> On Aug 30, 2019, at 1:19 AM, Philip McGrath <phi...@philipmcgrath.com> wrote:
> Hi Kevin,
> This is interesting! A number of people have wanted conveniences around 
> `keyword-apply` and accepting the same keywords as some other function. (The 
> trouble is, different people have different ideas of what those conveniences 
> should be.)
> To start with, I had a few small suggestions about the code you sent: 
> `keyword-apply/filter` doesn't need to be a macro, and your macro should use 
> `fn` rather than `h`;
> the second result of `procedure-keywords` can be `#f` if the given procedure 
> accepts all keywords;
> `for/lists` might be more convenient than `for/fold`;
> I think some of the cases in `filter/kw` get the filtering backwards;
> keywords can be `quote`-ed as values, so you don't need so many 
> symbol-to-string-to-keyword conversions;
> using `set!` this way will cause lots of problems;
> there's no need for `list->vector` in `get-kw-val`; and
> in `def`, it might be better to use syntax parameters than to break hygiene.
> You may know this, but all keyword-accepting functions in Racket are 
> effectively implemented with `make-keyword-procedure`: the variants of 
> `lambda` and `define` that use `kw-formals` are macros that expand to more 
> primitive versions that don't know about keywords. The macros also do some 
> optimization where possible. For inspiration, you might be interested in the 
> implementation in 
> https://github.com/racket/racket/blob/master/racket/collects/racket/private/kw.rkt
> <https://github.com/racket/racket/blob/master/racket/collects/racket/private/kw.rkt>
> For fun, I wrote a version that illustrates some of these suggestions and and 
> tries to do more work at compile-time. Be warned that it is not thoroughly 
> tested! I'm pasting it below, and I've also put it up as a Gist at 
> https://gist.github.com/LiberalArtist/292b6e99421bc76315110a59c0ce2b0d 
> <https://gist.github.com/LiberalArtist/292b6e99421bc76315110a59c0ce2b0d>
> -Philip
Thanks, Philip! Sorry for the bug in the keyword-apply/filter macro. I 
discovered it as well last night when I decided to convert the macro to a 
function. Glad others are working on this idea as well, perhaps something will 
find its way into the main package. As with much of my own code development  
No, I hadn’t realized make-keyword-procedure formed the basis of Racet keyword 
functions — I’m often being surprised like this — seems somewhere along the way 
I missed some fundamental primer of elementary concepts :) 

I’ve not had a chance to peruse the code and websites yet, but as clarification 
of what I have in mind: The problem I’m working on involves a function call f, 
in which some of the parameters are used to lookup functions in a table and 
then apply the remaining parameters in the application of that retrieved 
function g. All was going smoothly until I stored a function in the table that 
used keywords. So the filtering I’ve been working on would allow f to reference 
its own keywords without complaining about g’s and to “filter out” f’s keywords 
from those passed to g when they did not overlap (so to speak). Any additional 
keywords passed in the function call that were not defined by g would then be 
eared by g, which is why Ive been referring to f as a “pass-through”.  So if f 
defined #:foo and #:bar and g defined #:foo and #:baz f would bind any #:foo 
and #:bar values (or use its default values) for its own process, but pass g 
#:foo and #:baz as provided by the parameters passed in the call too f. Of 
course that lasts the flexibility that the #:foo value passed to f might be 
different from that of g — but that’s where I decided to draw the line :) 


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 

Reply via email to