On Feb 12, 12:15 pm, Meikel Brandmeyer <m...@kotka.de> wrote:
> > I dislike this strategy for two related reasons: (1) It cannont be > > nested. Here is a pseudo-example: > > > (?-> 2 ... some computations ... (f (?-> ... I don't have access to > > the outer "?" anymore... ))) > > > (2) Shadowing user bindings. If I bind ? to something in my code (e.g. > > (let [? (pred? foo)] (....))) the ?-> form shadows my definition, > > preventing access. > Agreed, Mark. I thought these limitations were acceptable given that compactness is the goal of the macro -- i.e. it wouldn't make much sense to nest with it -- but you're likely right that it'd be shortsighted. > However I would not name it let-> since there is no binding vector > following. I would suggest pipe-as. This also explains, that the given > local is bound to different things during the different stages of the > pipe. +1 to Miekel's pipe-as: I agree that "let" forms should have a binding vector. > What I definitively want is the non-seq => (non-seq local) translation. > That's really nice. Agreed. > It does prompt me to consider > a more complicated macro that inspects its arguments and provides > several behaviors under one name. If the first arg is a symbol, it > works like let->. If the first argument is a list, it works like ->. > If the first argument is the keyword :last it behaves like pipe. This > would be backwards compatible with the current -> implementation, but > also allow for the additional functionality described in this thread. Mark, I don't think this is actually backwards compatible. If the first arg is a symbol, you don't know if it's a symbol to be bound or if it's the initial value, e.g. user=> (-> 0 inc dec) 0 user=> (def z 0) #'user/z user=> (-> z inc dec) 0 At the moment, my vote is for two macros: 1 pipe: like -> but accumulated value is place at end of each form 2 pipe-as: in which user specifies binding symbol for accumulated value, plus the non-seq to (non-seq local) translation Perry --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
