Standardizing the threading macro and organizing packages

[Alexis King]

While in St. Louis, I had a brief conversation with Jay, Alex, and Jack about how we all happen to have our own implementation of Clojure’s threading macro. That macro is called -> in Clojure, but I believe Greg’s rackjure library set the Racket standard of calling it ~>, since the arrow is already used by contracts and types (and the FFI, too, for that matter). I have no idea how many implementations of this macro exist in the wild, but 5 is already far too many.

Duplication is an uncomfortably common problem in Lispy circles, but fragmentation is never a good thing, so I’m interested in trying to create a standard implementation. It is my understanding that Racket has mostly avoided this problem by traditionally absorbing common libraries into the core, but I also understand there’s been a push to reverse this trend by spinning these things off into packages. I plan to extract my implementation of ~> and all its associated friends (I have a lot of them) into their own package, but I’d also like to ask some questions first.

First of all, do any people object to this idea in principle? Is this too trivial of a thing to try and standardize? Assuming that’s not the case, I’ve been wondering what collection to put these in. Currently, Racket packages tend to use their own collections, which is even recommended by the documentation. However, Jay recently brought to my attention that perhaps this isn’t the best way to organize things: it might be better to extend existing collections with new modules. For example, he suggested I move my collections library to data/collection, which would imply that the lens library should be moved to data/lens. I actually like this idea quite a bit, especially for packages that are more mature.

This prompts the question asking where a set of utility macros actually belong. They don’t belong in data/, certainly, and they don’t belong in syntax/, since that collection deals with handling syntax objects themselves. Would it be good to create a util/ collection and place this in util/threading? Or would these be better in their own, separate collection?

The danger of departing from the one-to-one correlation with package names, of course, is the possibility of dramatically increasing the potential for conflicts. Personally, I think that grouping collections logically might be a good thing, but maybe it isn’t worth the risk? I’m interested in hearing people’s thoughts.

Thanks,
Alexis

[Sam Tobin-Hochstadt]

A few thoughts:

1. This is a great idea -- one of the reasons that I think Racket has
avoided lots of little dialects despite syntactic flexibility is
standardizing the community on one thing. I'm glad you're continuing
this.

2. When we've standardized on this sort of thing in the core, the
primary way we arranged it is writing things on mailing lists, so I
hope that works just as well here.

3. I agree with Jay's point about `data` and such, but I don't think
this fits in any existing category. I'm skeptical of a grab-back
`util` collection, though, so I think just putting this in it's own
collection makes the most sense. If we eventually have more things
like this, then we should come up with a category.

Sam

> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jack Firth]

I definitely like standard packages, but how will we avoid the problem of this becoming just another threading macro package instead of an actual standard? I also feel like something similar would be useful for anonymous functions, what with curly-fn, rackjure, fancy-app, the cut and cute macros from srfi 26, etc. etc.

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". Maybe a Wiki page acting like a swiss army knife of useful single purpose packages that the community has standardized? Also things like Greg Hendershott's threading macro blog post would need to be updated to point to the standardized version, along with other places "non standardized" versions of the functionality have been documented.

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.

[Alex Knauth]

On Oct 8, 2015, at 12:02 AM, Jack Firth <jackh...@gmail.com> wrote:

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.

+1

I like the function version better too, as long as I'm also using a good library (such as afl or fancy-app) for concise anonymous functions.

But for more complicated expressions, especially involving nesting, what I really want is something like this:

(-> x ; declares that x is the equivalent of _ or <>

  1

  (add1 x)

  (number->string x 2)

  (string-append x "1")

  (string->number x 10))

This is especially helpful when the xs are more deeply nested within the expressions.

Which can be defined easily like this:

(define-simple-macro (-> var:id expr:expr ...+)

  (let* ([var expr] ...) var))

The some-> version is almost as simple:

(define-simple-macro (some-> var:id expr0:expr expr:expr ...)

  (let* ([var expr0] [var (and var expr)] ...) var))

I actually got this idea from Matthias Felleisen, from this email on the list:

https://groups.google.com/forum/#!msg/racket-users/Um0_anlD8r4/1r-GFejV_HYJ

Which was rewritten to use let* instead of set! here:

https://groups.google.com/forum/#!msg/racket-users/Um0_anlD8r4/cpW0Bp-GMpUJ

I think it would be useful to provide both the function and the macro, without trying to conflate the two.

[Alexis King]

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

[Alex Knauth]

To clarify this, I think the function version is better because it's more powerful and more general, not just because it's convenient.

A macro constrains you to the syntax, but a function can be used in many different ways.

Similarly for the macro, allowing the user to specify the identifier to use as a placeholder allows -> expressions to be nested within other ->, meaning pieces can be fit together much more nicely. That's one thing functions do that these shorthand macros tend to leave aside.

[Robby Findler]

In addition to agreeing with you and Sam here Alexis, I would like to
point out another thing that has worked well for Racket in design
situations such as these: benevolent despotism.

That is, the person in charge of the design is expected to fully and
deeply understand what they have designed and to seriously consider
others suggestions but ultimately not get bogged down in directions
that would prevent having something that works well on a reasonable
time-scale.

Robby

[Greg Hendershott]

Why Rackjure

- rackjure is something I started casually, didn't expect it would
ever get 100 stars. On the other hand, I suspect nearly all of those
stars are "huh, interesting". Not "I actually use this". :)

- I have no emotional investment in it. Just feel an obligation to
support it for whoever may actually be using it.

- Also there's probably some value in a realistic example of how to do
some Clojure idioms in Racket? It's another path to Racket. Also,
"Racket is a programming-language programming language".


How Rackjure

- I'd be OK to see rackjure evolve (devolve?) toward a package that
mostly just re-provides other, more granular packages.

- If you do want a Clojure style threading _macro_, rackjure's is the
best implementation now AFAIK. I say that with no ego because that's
mostly thanks to help from people like Sam and Christoffer Sawicki.
Among other things, it's careful to expand using the correct #%app
(you can use it w/o using #lang rackjure). It could easily be its own
package, now, if that makes more sense.

[m...@mbtype.com]

> Duplication is an uncomfortably common problem in Lispy circles, but fragmentation is never a good thing

To be fair, there are plenty of good reasons why duplication / fragmentation would exist, many of them ultimately beneficial to the underlying system. Fragmentation is not per se bad. Standardization is not per se good (because it imposes its own costs & consequences).

[Greg Hendershott]

On Thu, Oct 8, 2015 at 10:56 AM, Greg Hendershott
<greghen...@gmail.com> wrote:
> - If you do want a Clojure style threading _macro_, rackjure's is the
> best implementation now AFAIK. I say that with no ego because that's
> mostly thanks to help from people like Sam and Christoffer Sawicki.
> Among other things, it's careful to expand using the correct #%app
> (you can use it w/o using #lang rackjure). It could easily be its own
> package, now, if that makes more sense.

Hmm that makes it sound like I want to keep "owning" this. But
actually, if someone else would prefer to own it, I'm fine with that!
I'd change rackjure to use that other package.

If that other package even needs it, I'd offer the same sort of help
and PRs that people like Sam and Chris gave me.

[Vincent St-Amour]

On Wed, 07 Oct 2015 23:02:23 -0500,
Jack Firth wrote:
> 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". Maybe a
> Wiki page acting like a swiss army knife of useful single purpose
> packages that the community has standardized? Also things like Greg
> Hendershott's threading macro blog post would need to be updated to
> point to the standardized version, along with other places "non
> standardized" versions of the functionality have been documented.

I think adding a pointer (and maybe some slight nudging :) ) to the
standardized version in the docs for the non-standardized version can go
a long way.

Sending PRs to packages that use the non-standardized versions can help
too. You can use `raco pkg catalog-archive` to download all packages,
and then grep for uses.

Vincent

[Alexis King]

I decided to release my threading implementation as the “threading” package. The documentation is here:
http://pkg-build.racket-lang.org/doc/threading/index.html

I’m okay with this because I wanted to pull them out of my utils package, anyway, and they’re nice to have, even if we come up with a better solution later. I think thrush and thrush+ from point-free might be nice to have in racket/function, but point-free is a good package for them, otherwise.

> On Oct 8, 2015, at 5:17 AM, Robby Findler <ro...@eecs.northwestern.edu> wrote:
>

> In addition to agreeing with you and Sam here Alexis, I would like to
> point out another thing that has worked well for Racket in design
> situations such as these: benevolent despotism.

I appreciate the value of this, certainly, but it doesn’t help much if the “standard” version is just another implementation that nobody agrees on, since that won’t really help the fragmentation much at all.

> On Oct 8, 2015, at 7:56 AM, Greg Hendershott <greghen...@gmail.com> wrote:
>
> If you do want a Clojure style threading _macro_, rackjure's is the
> best implementation now AFAIK. I say that with no ego because that's
> mostly thanks to help from people like Sam and Christoffer Sawicki.
> Among other things, it's careful to expand using the correct #%app
> (you can use it w/o using #lang rackjure). It could easily be its own
> package, now, if that makes more sense.

I’d be interested to hear what fanciness rackjure’s threading macros provide! It would be nice to incorporate those into my package, since I’m sure there are a few things I’m missing. Expanding to the right #%app is one of those things, to start. My implementation also does some fanciness that Clojure’s does not, such as allowing arbitrary position for the arguments, but it would be nice to combine the best of them both.

The question about function reader syntax packages is still outstanding. I get the sense that those aren’t terribly commonly used... but then I also get the sense that packages are very reluctant to depend on anything but the core. Does anyone even really use these packages besides their authors?

[Alex Knauth]

You don't think

(define-simple-macro (-> var:id expr:expr ...+)

  (let* ([var expr] ...) var))

Is better?

It's more powerful, because it allows placeholders to be arbitrarily nested within the expressions.

Also, it allows the user to supply their own identifier to use as a placeholder instead of _, so it doesn't run into the problems of substituting an expression in a place you didn't want it, for instance if you had another ~> expression nested within in.

Because of those two things, it allows pieces of a program to be put together easily, without worrying about whether it will do some weird thing like insert an ~> expression into another ~> expression and end up with a compile-time infinite loop. 

It's also much simpler to keep in your head.

[Alexis King]

> On Oct 8, 2015, at 11:08 AM, Alex Knauth <alex...@knauth.org> wrote:
>
> You don't think
> (define-simple-macro (-> var:id expr:expr ...+)
> (let* ([var expr] ...) var))
>
> Is better?

No, actually I, I don’t. Threading macros are a convenience, just like anonymous functions. I’d rather keep them simple and easy to use than add another term that needs to be provided 100% of the time that I’ll only take advantage of 5% of the time.

As for compile-time infinite loops: I can’t imagine how that could possibly occur, but if you can demonstrate such a problem, that sounds like a bug.

As for simpler to keep in your head: [citation needed]. The original threading macro is a simple macro that unwinds nested function application. Implementation aside, I find that the most intuitive way to visualize it—introducing binding makes that more complicated, not less.

[Alex Knauth]

> On Oct 8, 2015, at 2:27 PM, Alexis King <lexi....@gmail.com> wrote:
>
>
>> On Oct 8, 2015, at 11:08 AM, Alex Knauth <alex...@knauth.org> wrote:
>>
>> You don't think
>> (define-simple-macro (-> var:id expr:expr ...+)
>> (let* ([var expr] ...) var))
>>
>> Is better?
>
> No, actually I, I don’t. Threading macros are a convenience, just like anonymous functions. I’d rather keep them simple and easy to use than add another term that needs to be provided 100% of the time that I’ll only take advantage of 5% of the time.

One big thing that I find convenient is the ability to treat everything as an expression with sub-expressions. This is convenient because it allows me to move expressions around, combine them, and substitute them in whatever ways I want, and nothing unexpected happens. My macro and Jack Firth's function both allow that.

> As for compile-time infinite loops: I can’t imagine how that could possibly occur, but if you can demonstrate such a problem, that sounds like a bug.

Your implementation avoids this, and so does the current rackjure implementation, but I think at one point the rackjure implementation did this:
'(~>> a b (~>> c d))
'(~>> (~>> a b) (~>> c d))
'(~>> c d (~>> a b))
'(~>> (~> c d) (~>> a b))
'(~>> a b (~> c d)) ; back where we started

This confused me. The rules of recursion made sense, but the expansion didn't make sense because the subexpressions weren't subexpressions, but templates.

> As for simpler to keep in your head: [citation needed]. The original threading macro is a simple macro that unwinds nested function application. Implementation aside, I find that the most intuitive way to visualize it—introducing binding makes that more complicated, not less.

Introducing binding makes it about expressions that make sense with lexical scope, as opposed to templates that stuff will get inserted into.

[Alex Knauth]

On Oct 8, 2015, at 2:27 PM, Alexis King <lexi....@gmail.com> wrote:

The original threading macro is a simple macro that unwinds nested function application. Implementation aside, I find that the most intuitive way to visualize it—introducing binding makes that more complicated, not less.

An ~> expression has a start expression followed by a series of templates. 

But at least the start expression is an expression, so it should be able to be replaced with what it equals.

Quick! Should (~>> (~>> a b) (~>> c d)) be equal to (~>> (b a) (~>> c d)) ?

Uh, wait, ahh! My intuition says yes ?

Nope.

One expands to (d c (b a)), and the other expands to (b a (d c)).

Quick! Can you tell which one expands to which? 

I can't unless I actually evaluate expand-once a bunch of times.

If I were implementing this, I would make sure that (~>> some-expr some-template ...) was always equal to

(let ([x some-expr])

  (~>> x some-template ...))

I'm pretty sure there's some technical term for being able to do this, but I can't think of it.

Apply that rule recursively to all the intermediate steps, and

(let* ([x some-expr]

       [x (subst x some-template)]

       ...)

  x)

[Alexis King]

> My macro and Jack Firth's function both allow that.

Sounds like the solution is to go with a function instead of a macro then. If you want that flexibility, I don’t think there’s any reason to stick with a macro, anyway. The point-free package is very nice.

Alexis

[Jack Firth]

I agree about using the function form for flexibility. (Alliteration!) The macro form should be optimized for simple cases, because macros by nature are less flexible. If you have a complex case, write actual functions. You'll spend less time wrangling the syntax system that way.

[Jay McCarthy]

FWIW, I find my threading macro to be very powerful, pretty clear when
used complicatingly, and at about power-level 9,000:

https://github.com/jeapostrophe/exp/blob/master/threading-arrow.rkt

My opinion is to include something like this in remix along with some
nice syntax for cut (what ignorant people call "function literals".)
Probably by replacing the (<> 1) in my ~> with _ and _.1 and by
writing cut as λ.(+ $.0 $.2) using _, λ, and $ as dot transformers.

Jay

--
Jay McCarthy
http://jeapostrophe.github.io

"Wherefore, be not weary in well-doing,
for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
- D&C 64:33

[Alex Knauth]

On Oct 8, 2015, at 4:48 PM, Jay McCarthy <jay.mc...@gmail.com> wrote:

A key thing that Remix has is buttery C-like syntax for infix dots. So
you can write r.ul.x and it might be the same as (posn-x (rectangle-ul
r)) if `r` were bound to a "dot transformer" that looked for .ul and
so on.

(Off topic)

Sounds a bit like my postfix-dot-notation package

http://pkg-build.racket-lang.org/doc/postfix-dot-notation/index.html

Except that this forces you to write r.post-x.rectangle-ul instead of r.x.ul.

[Greg Hendershott]

> Quick! Should (~>> (~>> a b) (~>> c d)) be equal to (~>> (b a) (~>> c d)) ?

Well, I wouldn't want to write or read code like that. If I'm using a
threading macro, at all, it's to reduce nesting, and emphasize the
"flat", "pipeline" quality of some computations. As a result I'm not
eager to write or read nested threading macros. :)

Honestly I hardly use threading macros anymore. I used them a fair
amount in Frog, but that's a relatively "pipeline-ish" app, with lots
of "take X and run it through this series of transformations". Most of
my projects don't really have that quality, or at least I haven't
found it as helpful to express them that way.


As for a threading macro being faster than a thrush function: Although
it is, instead how I'd put it is that it's "not slower than"
traditional nested applications. For example you can "de-nest"
existing code and not worry that you also made it slower. Because it's
expanding to the same nested applications. It's just expressed in a
flat postfix syntax. IFF doing so actually makes it easier to read and
maintain, is what I ask myself these days.

[Alex Knauth]

On Oct 8, 2015, at 4:51 PM, Jack Firth <jackh...@gmail.com> wrote:

Looking at that one, I'm against back-referencing N clauses with (<> n). I find it very difficult to read, and it strikes me as particularly fragile if you're inserting or removing steps into the flow as you edit it. 

Trying to count back steps (especially if they're not formatted to all be one per line) is mental juggling I don't want to do, and it muddies my thought process. If I really want to go to that effort to avoid naming things, I'll use currying and point free composition operations.

+1

I agree completely.

[Alexis King]

> On Oct 8, 2015, at 1:34 PM, Jay McCarthy <jay.mc...@gmail.com> wrote:
>
> FWIW, I find my threading macro to be very powerful, pretty clear when
> used complicatingly, and at about power-level 9,000:
>
> https://github.com/jeapostrophe/exp/blob/master/threading-arrow.rkt

I have to agree with Jack and Alex here: I find that a little terrifying, and I would not want to need to understand any code that used it.

> My opinion is to include something like this in remix along with some
> nice syntax for cut (what ignorant people call "function literals".)

I admit I can’t really disagree with this point. I’m mostly just interested in what syntax you have in mind.

[Jay McCarthy]

On Thu, Oct 8, 2015 at 6:23 PM, Alexis King <lexi....@gmail.com> wrote:
>> On Oct 8, 2015, at 1:34 PM, Jay McCarthy <jay.mc...@gmail.com> wrote:
>>
>> FWIW, I find my threading macro to be very powerful, pretty clear when
>> used complicatingly, and at about power-level 9,000:
>>
>> https://github.com/jeapostrophe/exp/blob/master/threading-arrow.rkt
>
> I have to agree with Jack and Alex here: I find that a little terrifying, and I would not want to need to understand any code that used it.

I'm inspired by your terror.

>> My opinion is to include something like this in remix along with some
>> nice syntax for cut (what ignorant people call "function literals".)
>
> I admit I can’t really disagree with this point. I’m mostly just interested in what syntax you have in mind.

The idea would be to make it like super cut, but with . to give it
that delicious C-like crunchy topping

https://github.com/jeapostrophe/exp/blob/master/scut.ss

So,

λ.(+ $ 1) => (λ (x) (+ x 1)
λ.(+ $.0 $.1) => (λ (x y) (+ x y))
λ.(+ $.x 1) => (λ (#:x x) (+ x 1)
λ.(+ $.x $8) => (λ (#:x x a0 a1 a2 a3 a4 a5 a6 a7 a8) (+ x a8)
λ.(apply + $.0 $.…) => (λ (x . args) (apply + x args))

[Sam Tobin-Hochstadt]

On Thu, Oct 8, 2015 at 6:48 PM, Jay McCarthy <jay.mc...@gmail.com> wrote:
>
>>> My opinion is to include something like this in remix along with some
>>> nice syntax for cut (what ignorant people call "function literals".)
>>
>> I admit I can’t really disagree with this point. I’m mostly just interested in what syntax you have in mind.
>
> The idea would be to make it like super cut, but with . to give it
> that delicious C-like crunchy topping
>
> https://github.com/jeapostrophe/exp/blob/master/scut.ss
>
> So,
>
> λ.(+ $ 1) => (λ (x) (+ x 1)
> λ.(+ $.0 $.1) => (λ (x y) (+ x y))
> λ.(+ $.x 1) => (λ (#:x x) (+ x 1)
> λ.(+ $.x $8) => (λ (#:x x a0 a1 a2 a3 a4 a5 a6 a7 a8) (+ x a8)
> λ.(apply + $.0 $.…) => (λ (x . args) (apply + x args))

Perhaps unsurprisingly, since this is what I implemented in fancy-app,
I think that once you're numbering things, the whole enterprise has
gone off the rails.

Either (+ _ _) [1] should mean (lambda (x) (+ x x)) or (lambda (x y)
(+ x y)) or a syntax error, but when you need to get fancier, named
function arguments are a great thing.

[1] Or whatever preferred syntax we settle on.

Sam

[Jack Firth]

The more I think about it, the more I realize I really dislike specifying the position of arguments in these anonymous function syntaxes. For instance I would prefer this:

(λ (x y) (/ y x))

To this:

λ.(/ $.1 $.0)

In the common case, you won't need to flip any argument orders around. In that case the numbering is just noise that gets tuned down relative to the expression structure. In the uncommon case, because of the common case I might not notice it when reading the code and could critically misread the order of an anonymous function's arguments. In addition, when shuffling the positions around I find it much easier to think in terms of actual bindings, as with the first example, than in terms of positions, as in the second example. What if I need to change argument order or insert an argument? Now I have to tweak the numbers used in the structure of the function, rather than just messing with the declaration of bindings for the function.

This is why I like fancy-app. Once you throw out specifying positions, you don't need that syntactic overhead in the common cases. You're left with just structure:

(define halve (/ _ 2))

Ideally fancy app would do keyword arguments and rest arguments, perhaps rest arguments as (+ . _). I think it handles keyword args (never tried) but I don't know if it does rest args.

[Brian Adkins]

On Wednesday, October 7, 2015 at 11:18:41 PM UTC-4, Sam Tobin-Hochstadt wrote:
> A few thoughts:
>
> 1. This is a great idea -- one of the reasons that I think Racket has
> avoided lots of little dialects despite syntactic flexibility is
> standardizing the community on one thing. I'm glad you're continuing
> this.
>
> 2. When we've standardized on this sort of thing in the core, the
> primary way we arranged it is writing things on mailing lists, so I
> hope that works just as well here.
>
> 3. I agree with Jay's point about `data` and such, but I don't think
> this fits in any existing category. I'm skeptical of a grab-back
> `util` collection, though, so I think just putting this in it's own
> collection makes the most sense. If we eventually have more things
> like this, then we should come up with a category.
>
> Sam

Was any consensus reached on this? I've been working through some exercises in Racket that a friend is implementing in Elixir, and I just came across a "method chaining" situation. I ended up simply writing a wrapper function, but using a version of ~> would've been nice.

The commit is here:

https://github.com/lojic/exercism-racket/commit/5d2d24c240d7157204c473ea98d2e4990bb9e4ca

Lines 29-34 on the left compared to using a wrapper function in lines 35-39 on the right.

[Greg Trzeciak]

On Thursday, October 8, 2015 at 5:09:20 AM UTC+2, Alexis King wrote:
> While in St. Louis, I had a brief conversation with Jay, Alex, and Jack about how we all happen to have our own implementation of Clojure’s threading macro. That macro is called -> in Clojure, but I believe Greg’s rackjure library set the Racket standard of calling it ~>, since the arrow is already used by contracts and types (and the FFI, too, for that matter). I have no idea how many implementations of this macro exist in the wild, but 5 is already far too many.

With Refinements being currently added (http://andmkent.com/blog/2015/07/06/stop-2015-talk-adding-practical-dependent-types-to-typed-racket/):
1. Is the argument of using ~> no longer valid since refinements also use it.
2. Is adding refinements going to cause some conflicts with the existing threading implementations?

Thanks
Greg

[Alexis King]

> On Jan 29, 2016, at 21:55, Brian Adkins <lojic...@gmail.com> wrote:
>
> Was any consensus reached on this? I've been working through some exercises in Racket that a friend is implementing in Elixir, and I just came across a "method chaining" situation. I ended up simply writing a wrapper function, but using a version of ~> would've been nice.

Yes, actually, there was. The “threading” package was the result, and
you can find the documentation here[1]. I believe rackjure’s threading
implementation now also uses this package, so at least some level of
standardization has been reached.

If you want Clojure-style threading macros, the threading package is
probably your best bet. Of course, that might not actually be what you
want: consider also looking at the different ~> from the point-free
package, which is actually a higher-order function. When paired with a
shorthand function package (which didn’t ever get standardized), it can
be a little more powerful (and just as concise) than a dumb macro.

> On Jan 31, 2016, at 05:58, Greg Trzeciak <gtrz...@gmail.com> wrote:
>
> With Refinements being currently added (http://andmkent.com/blog/2015/07/06/stop-2015-talk-adding-practical-dependent-types-to-typed-racket/):
> 1. Is the argument of using ~> no longer valid since refinements also use it.
> 2. Is adding refinements going to cause some conflicts with the existing threading implementations?

I would say no. I’m not sure if the refinement syntax is set in stone,
and even if it is, the name of this particular macro has a relatively
long history in the Racket world, so it doesn’t make much sense to
change it now. In the event that the two are used together and do,
indeed, collide, then Racket’s ample namespace management tools are easy
enough to use to resolve the conflict.

[1]: http://pkg-build.racket-lang.org/doc/threading/index.html

[Brian Adkins]

On Sunday, January 31, 2016 at 1:05:17 PM UTC-5, Alexis King wrote:

> > On Jan 29, 2016, at 21:55, Brian Adkins wrote:
> >
> > Was any consensus reached on this? I've been working through some exercises in Racket that a friend is implementing in Elixir, and I just came across a "method chaining" situation. I ended up simply writing a wrapper function, but using a version of ~> would've been nice.
>
> Yes, actually, there was. The “threading” package was the result, and
> you can find the documentation here[1]. I believe rackjure’s threading
> implementation now also uses this package, so at least some level of
> standardization has been reached.

Awesome! I just tried it out, and it works great:

(define (score word)
(apply + (~> word
string-trim
string-downcase
string->list
(map (curry hash-ref points) _))))

(define (word-count str)
(~> str
string-downcase
(string-split #px"[^a-z]+")
(foldl (λ (word hsh) (hash-update hsh word add1 0))
(make-immutable-hash)
_)))

> If you want Clojure-style threading macros, the threading package is
> probably your best bet. Of course, that might not actually be what you
> want: consider also looking at the different ~> from the point-free
> package, which is actually a higher-order function. When paired with a
> shorthand function package (which didn’t ever get standardized), it can
> be a little more powerful (and just as concise) than a dumb macro.

I'll check this out later.