This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (56)
- # calva (61)
- # cider (16)
- # clara (7)
- # cljdoc (2)
- # cljs-dev (2)
- # cljsrn (1)
- # clojure (144)
- # clojure-spec (23)
- # clojure-uk (5)
- # clojurescript (9)
- # clojureverse-ops (5)
- # community-development (4)
- # cursive (18)
- # datomic (15)
- # docs (6)
- # jackdaw (2)
- # nrepl (10)
- # nyc (2)
- # off-topic (18)
- # rewrite-clj (20)
- # shadow-cljs (31)
And as a way to encourage not refering :all to begin with. But instead explicitly listing what to refer, and even better, not refering anything, just aliasing instead.
But use still works. Its just that since require can now do everything and more that what use used to do, use is no longer needed.
@jeevarajmvsvg I think ring is a typical starting point https://github.com/ring-clojure/ring
@jeevarajmvsvg if you are looking for framework, re-frame, om next, luminus, fulcro, pedestal for server side?
@jeevarajmvsvg just remember there is no BEST in programming, everything has its strong and weak sides, you just need to choose the one that fits your task better.
Hello. I started a project using a Leiningen template. The template has since been updated. Is there a way to incorporate template changes into an existing project?
#(... %)? Is there a clear preference in the community for one or the other?
I kind of prefer
#(..) don't nest and it is fewer weird characters) but it is much longer to type and anon. fn. is more flexible as the
% can be placed anywhere, not just at the end. I believe people use
#(..) much more, is that a correct observation?
As a haskeller in past, I was surprised how indirect is carryng in Clojure - in Haskell you can simply drop argumenst for this. But the same question about arguments order also exists (more
flip-s is about it). And absence of
(* 10) syntax also make code more verbose. I think you can use such hack for shorten type:
def p- partial or use common reader macroses like
#(... % ...)
#(...)) whenever possible. Less weird characters and less ambiguity. I would only use
#(...) over it if I need to be more succinct in # of characters.
If you’re nesting anon functions it sounds like you should be calling
fn (with a name! like
(fn my-fn-instead-of-partial [a b] (+ a b)) )
So that when going through a stack trace its not a gensym’ed name. It may seem verbose with 1 or 2 levels of nesting but i’ve seen those partials be passed around for DI (Not a pattern I like…) and its next to impossible to understand what function was actually called via the stacktrace if you don’t have a name.
Hum, ya I guess for staxktrace maybe. But sometimes I'd for sure take the convenience over it
#(...%...) - you must have an ability to use argument of external function into internal - but with
%1 syntax it can not be realized
Hum... Is that the only logic? I guess sometimes you need to close over the parent, but shadowing would be okay a lot of the time
I guess actually, I'm more hoping for a new form. It's a but embarrassing that I find Java's syntax better
(x -> y -> (+ x y))
Its not that I really want it. Its that I find #() is a little quirky. And I wouldn't mind a core improvement on it
It has both implicit args, which is quirky, it has the issue that it always wrap the inside in a parenthesis so you can't do #("10") and it can't be nested
Basically, #() would assume the last expression is the fn body and everything before are the symbol args
So, the problem is how to strong set symbols as an arguments of lambda, but not as an external symbols
But. I would literally just have it be a macro that expands to
(fn[x] (fn[y] (+ x y))
You can write such macro. But it will reduce your capabilities for using external symbols
I don't think so, since the user picks the symbol names, they are in control, if they don't want to shadow, they just use another name
let in Clojure is a spec form, but semantically it is a macro on lambda (and in Scheme it really is!)
so, semantically speaking, only lambda-abstraction can insert new named args in combinators
Are you saying the evaluation order would be wrong with non reader macros, because let special form won't expect it?
Ya, it's too late for #. But I wish it worked as I wrote it. Maybe adding #f(x y (+ x y))
Haskell way isn't bad either, just doesn't seem as consistent with the rest of Clojure's syntax
You could have it that when there is no % or %n inside #, it assumes to be #(params form)
And every time I would look at an anonymous fn I’d have to remember and think about if the magic is happening there or not.
You think? Okay, let's say I create #f and these are example usage:
You'd find that confusing?
#f(a b (+ a b)) #f(+ 1 %) #f(+ %1 %2)
#f(a b (+ a b)) => (fn [a b] (+ a b)) ;; cost: is wrapping a and b in a vector #f(+ 1 %) => #(+ 1 %) ;; cost: an extra character #f(+ %1 %2) => #(+ %1 %2) ;; cost: an extra character.
and as I already mentioned - do not forget about magic distraction syntax in
fn - macro 🙂
Now that I think about it though, it seems what I'm really asking for is named arguments inside # and thus the ability to nest it.
Ya. That would satisfy my use case, would be even better, since now it's actually 50% shorter as well
and this is exactly the same i talked about several types above - strong splitting internal args from external symbols
Wonder if Rich Hickey would approve a patch to add support for
#(+ %a %b) hehe. Probably not
Ya, maybe I should just stop using #(), and only use fn. Then I'm never accidentally nesting it and wondering why it throws exception
and I think I'l be rare visitor of discord and other channels - I have a limited amount of day time (only 24 hours 🙂 ) and multiple messengers wants more than this 🙂