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 alre
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
prima
> 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
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
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
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 whoeve
On Thu, Oct 8, 2015 at 10:56 AM, Greg Hendershott
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 c
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
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 o
> On Oct 8, 2015, at 11:08 AM, Alex Knauth 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 e
> On Oct 8, 2015, at 2:27 PM, Alexis King wrote:
>
>
>> On Oct 8, 2015, at 11:08 AM, Alex Knauth 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,
> On Oct 8, 2015, at 2:27 PM, Alexis King 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 ~> expressio
> 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
--
You received this mess
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.
On Thu, Oct 8, 20
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
> On Oct 8, 2015, at 4:48 PM, Jay McCarthy 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
> 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
> On Oct 8, 2015, at 4:51 PM, Jack Firth 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 b
> On Oct 8, 2015, at 1:34 PM, Jay McCarthy 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
On Thu, Oct 8, 2015 at 6:23 PM, Alexis King wrote:
>> On Oct 8, 2015, at 1:34 PM, Jay McCarthy 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/threadin
On Thu, Oct 8, 2015 at 6:48 PM, Jay McCarthy 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 syn
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 cas
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
> 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 usin
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 c
25 matches
Mail list logo
