> If this isn't going to be added to the core (and I don't think it should),
> then there would need to be some work done on exposure and making sure
> everyone who wants this functionality knows "look here first and only roll
> your own if this isn't specific enough”.
This is a good point, and it’s one that I’ve considered. I’m not entirely sure
what the solution is. The “rings” system in the package manager seems like a
potential attempt to account for this, but that system is, as of now, unused.
Clojure has a “Clojure contrib” project, which pulls certain user-created
packages into the clojure GitHub org, but I’m not sure that’s really much of a
helpful (or scalable) approach.
> As for the actual package, I'm a strong proponent of a non-macro version
> that's just the reverse of compose, mostly because it plays very nicely with
> anonymous macro functions like fancy-app. I'm a bit biased as that's the one
> I made in my point-free package however. Macro versions are nice too, but I
> prefer the flexibility of an actual function for most purposes.
I kind of agree with this, even if it isn’t really idiomatic Racket. With good
lambda shorthand, this is really just as good as any threading macro I’ve seen,
and it’s more flexible at that. In practice, I haven’t found that added
flexibility all that important in Racket code, but it is conceptually nicer.
The obvious argument against this is “it’s slow!”, which is true currently. The
macro version is quite a bit faster than the higher-order function, for obvious
reasons. That said, I tend to err on the side of conceptual cleanliness over
speed, and it’s hard to argue using a macro where a function would do.
The real argument is that, well, Racket *doesn’t* have built-in function
shorthand. Perhaps we should be discussing that package zoo instead? The
versions I know off the top of my head are:
- fancy-app — Sam’s. Implemented as a module by exporting a customized
#%app that works at expansion-time.
- rackjure — Greg’s. Implemented as a full language. Works at read-time
using readtable dispatch macros with a prefix.
- afl — Alex’s. Implemented as a meta-language. Works at read-time
using readtable dispatch macros with a prefix.
- curly-fn — Mine. Implemented as a meta-language. Works at read-time using
readtable dispatch macros and curly braces.
(If I’m missing any, please let me know.)
While rackjure is quite cool, it’s much more than just anonymous functions and
it isn’t composable, so I consider that out. I know fancy-app is somewhat
appealing because it doesn’t need to be implemented at read-time, but I find
that it doesn’t have a very strong visual sigil that clues me into the fact
that something is a lambda expression, not an application. I think the uniform
syntax works against readability here.
So, in my highly subjective opinion, that leaves afl and curly-fn. I think it
goes without saying which one I prefer, but I’ll be the first to admit that the
differences are minor. The only semantic difference is that curly-fn doubles as
a shorthand for `curry` when no argument placeholders are provided, which I
think is a nice feature, but it could also be easily added to afl.
I think that summarizes another case in which we have lots of libraries that do
the same thing in slightly different ways. This example, however, is different:
it is something that quite likely *should* be in the core. This might be the
best argument for afl, given that it would be the most seamless to add in a
backwards-compatible way, but this is probably another thing to hold off until
racket2, anyway. Until that happens, what are people’s thoughts on this batch
of conflicting libraries?
--
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.
For more options, visit https://groups.google.com/d/optout.
