Fork me on GitHub
#clojure
<
2019-04-27
>
didibus00:04:21

Its better to use :refer :all mostly for conssistency

didibus00:04:02

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.

didibus00:04:24

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.

sotrhraven01:04:51

@sogaiu well, just checked GitHub. Man I really should pay more attention.

jeevarajmvsvg10:04:55

@here help me out , which is the best framework for web development in Clojure

hillam.mail13:04:58

@jeevarajmvsvg I think ring is a typical starting point https://github.com/ring-clojure/ring

k.i.o14:04:53

@jeevarajmvsvg if you are looking for framework, re-frame, om next, luminus, fulcro, pedestal for server side?

jeevarajmvsvg14:04:20

Thank you guys

k.i.o14:04:13

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

minsunhuang15:04:16

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?

jeevarajmvsvg17:04:59

@k.i.o that’s true

holyjak20:04:54

partial or #(... %)? Is there a clear preference in the community for one or the other? I kind of prefer partial (since #(..) 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?

ivana20:04:54

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 #(... % ...)

didibus20:04:37

Either or really

scallions20:04:02

I perfer partial over #(...)) whenever possible. Less weird characters and less ambiguity. I would only use #(...) over it if I need to be more succinct in # of characters.

didibus20:04:51

I really wish one day #() could nest

didibus20:04:03

Its one of those small quirks

didibus20:04:19

I wonder why it can't nest actually

lanejo0120:04:18

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

didibus20:04:15

Why with name

didibus20:04:25

I often don't need it named

didibus20:04:29

That's the issue of fn

lanejo0120:04:20

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.

didibus20:04:18

Hum, ya I guess for staxktrace maybe. But sometimes I'd for sure take the convenience over it

ivana20:04:31

About nested #(...%...) - you must have an ability to use argument of external function into internal - but with % or %1 syntax it can not be realized

ivana20:04:17

How you would rewrite (fn [x] (fn [y] (+ x y))) ?

didibus20:04:40

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

didibus20:04:02

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

lanejo0120:04:37

I mean… you can write a macro for that exact syntax if you really want it.

ivana20:04:13

Magic and power of Clojure macroses allows you to write any syntax you want I hope 🙂

didibus20:04:45

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

ivana20:04:51

Oh, I type very slow - I follow answer above 🙂

didibus20:04:00

I always have to explain #()

didibus20:04:45

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

didibus20:04:54

That's a lot of quirks

didibus20:04:51

I mean, minor quirks

ivana20:04:54

As I know, # is a prefix of non-expandable reader macroses

didibus20:04:30

I don't know what would necessarily be better though.

didibus20:04:34

Maybe just #(x y (+ x y)) and have it be nestable

didibus20:04:06

Basically, #() would assume the last expression is the fn body and everything before are the symbol args

ivana20:04:16

🙂 how deside it is one 2-arg lambda or 2 one arged?

didibus20:04:54

For two one arg you'd do #(x #(y (+ x y))

ivana20:04:24

x can be binded global symbol 🙂

didibus20:04:06

Ya, but so can it for (fn[x] ...), so in this case it just shadows the global symbol

ivana20:04:19

Not of course

ivana20:04:53

in lambda calculus it called free or binded args

didibus20:04:40

I guess I'm not following. How is it any different to (fn[x] (fn[y] (+ x y))

ivana20:04:41

everything in vector after fn is binded

ivana20:04:14

(def x partial) (apply #(x #(y (+ x y)) 33)

ivana20:04:59

and it must be as a (partial #(+ % ???) 33)

didibus20:04:04

Hey that's neat !

ivana20:04:14

So, the problem is how to strong set symbols as an arguments of lambda, but not as an external symbols

didibus20:04:26

But. I would literally just have it be a macro that expands to (fn[x] (fn[y] (+ x y))

ivana20:04:24

You can write such macro. But it will reduce your capabilities for using external symbols

didibus20:04:06

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

ivana20:04:08

On the other hand, you will know it as a feature, not a bug 🙂

didibus20:04:32

I mean, you could expand it into gensymed symbols as well

didibus20:04:39

Then you wouldn't be able to shsdow

ivana20:04:45

Stay on strong semantic, not weak conventions

didibus20:04:59

Though I would find that surprising, since I'd expect it to shadow

didibus20:04:27

So why doesn't fn has the same problem, I'm still not following?

ivana20:04:57

cause fn have only way and ability to create a new local-meaning (how it say?) symbols

ivana20:04:07

let in Clojure is a spec form, but semantically it is a macro on lambda (and in Scheme it really is!)

ivana20:04:23

(let [a 1 b 2 c 3] (+ a b c)) -> ((fn [a b c] (+ a b c)) 1 2 3)

ivana20:04:20

so, semantically speaking, only lambda-abstraction can insert new named args in combinators

ivana20:04:21

and of course, you can shadow external symbol in fn

ivana20:04:48

but it is well controlled and known

didibus20:04:51

What about (let [a 1 b 2] (fn [a b] (+ a b)))

ivana20:04:24

it is a trivial shadowing I mentioned before 🙂

didibus20:04:34

Right, so I'm just saying I'd like some syntax sugar over fn 😋

ivana20:04:02

what I wanna say - you can wrap fn in a macro

didibus20:04:11

(let [a 1 b 2] #(a b (+ a b)))

didibus20:04:41

Are you saying the evaluation order would be wrong with non reader macros, because let special form won't expect it?

ivana20:04:57

maybe haskell way would be better (\ x y => (+ x y)) 🙂

ivana20:04:09

\ - is a real macro!

ivana20:04:30

# already used by reader special cases

didibus20:04:23

Ya, it's too late for #. But I wish it worked as I wrote it. Maybe adding #f(x y (+ x y))

didibus20:04:46

Or even #fn(x y (+ x y))

didibus20:04:13

Haskell way isn't bad either, just doesn't seem as consistent with the rest of Clojure's syntax

ivana20:04:19

and now it is time to main question - is it so far from current fn syntax?

ivana20:04:32

#fn(x y (+ x y)) or (fn [x y] (+ x y))

didibus20:04:36

(fn [x y] (+ x y))
#fn(x y (+ x y))

didibus20:04:52

:drooling_face:

ivana20:04:19

(not every time I type slower 😂)

didibus20:04:34

Though I do find it visually less distracting

didibus21:04:35

But ya, ideally it would have been how # worked

didibus21:04:53

I think you could still do it

didibus21:04:29

You could have it that when there is no % or %n inside #, it assumes to be #(params form)

lanejo0121:04:58

But then there is magic.

lanejo0121:04:12

and syntax.

didibus21:04:45

I guess this would be an issue: #(+ 1 2)

lanejo0121:04:46

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.

ivana21:04:46

but now #(+ 1 2) is a normal non-arged lambda

didibus21:04:06

You think? Okay, let's say I create #f and these are example usage:

#f(a b (+ a b))
#f(+ 1 %)
#f(+ %1 %2)
You'd find that confusing?

ivana21:04:32

(#(+ 1 2))
=> 3

didibus21:04:59

Ya, extending # wouldn't work, we'd break lambda of no args

ivana21:04:35

@didibus can I suggest a little tweak? 🙂 #f(a b (+ a b)) -> (\ a b (+ a b))

ivana21:04:01

destruction will breaking, but other will work 🙂

lanejo0121:04:24

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

didibus21:04:34

Ya, I guess that could work as well.

didibus21:04:10

So the cost I see isn't how many chars to type

didibus21:04:32

But how visually non distracting it could be

ivana21:04:44

and as I already mentioned - do not forget about magic distraction syntax in fn - macro 🙂

didibus21:04:05

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.

didibus21:04:30

Maybe just #(+ %a %b)

ivana21:04:48

Looks like so

didibus21:04:13

Ya. That would satisfy my use case, would be even better, since now it's actually 50% shorter as well

ivana21:04:46

and this is exactly the same i talked about several types above - strong splitting internal args from external symbols

didibus21:04:12

Oh, that's what you meant?

ivana21:04:32

and you still can write a macro and your dsl syntax for it

didibus21:04:45

I mean, someone could do (let [%1 1 %2 2] #(+ %1 %2)) no? Though unlikely

ivana21:04:50

% prefix with number suffix now used for it in # - style lambdas

ivana21:04:52

you can choose another convention - but you have to choose any one

didibus21:04:15

Wonder if Rich Hickey would approve a patch to add support for #(+ %a %b) hehe. Probably not

ivana21:04:39

I dont think so optimistic 🙂

ivana21:04:20

Your can write your own .clj code preprocessor!

didibus21:04:06

Haha, ya. I'll probably just live with (fn[a b] ...) for now 😋

ivana21:04:16

Lets go back to classic 😂

didibus21:04:17

I think the only time I really need this is when I do a map in a map

didibus21:04:39

And I feel, maybe there's just a whole better way to do what I'm trying to do

ivana21:04:53

I often was needed nested # lambdas

ivana21:04:42

and I had to choose which lambda make # external or internal 🙂

ivana21:04:40

for ex - update map value by function with nested map or filter

didibus21:04:11

There's definitely many time where you need to nest, at least one level

ivana21:04:33

but distructing syntax in fn macro makes choice easier 🙂

didibus21:04:53

Ya, maybe I should just stop using #(), and only use fn. Then I'm never accidentally nesting it and wondering why it throws exception

ivana21:04:58

Good that this exception throws at compile time!

ivana21:04:06

Not at runtime )

k.i.o22:04:53

@ivana is that you who was asking a question about tail call recursion on fp discord?

ivana22:04:46

yes, that was me, and I have same nickname on all messengers/forums.

k.i.o22:04:16

yeah i thought so, just sent you an answer, if its still relevant

ivana22:04:06

thanks, but I already had a constructive discussion about it here

k.i.o22:04:17

great, np

ivana23:04:05

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 🙂

k.i.o23:04:34

yeah, i would like to delete slack, but this community is too important for me