[racket-users] Re: Standardizing the threading macro and organizing packages

[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

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

[racket-users] Re: Standardizing the threading macro and organizing packages

[mb]

> 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).

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

Re: [racket-users] Re: Standardizing the threading macro and organizing packages

[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

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

[racket-users] Re: Standardizing the threading macro and organizing packages

[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.

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

[racket-users] Re: Standardizing the threading macro and organizing packages

[Alex Knauth]

> On Oct 8, 2015, at 12:02 AM, Jack Firth  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.


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