(defn drop-both-sides
  [n lst]
  (drop n (drop-last n list)))

you have lst in the arg and list in the code

list is a function

Hi guys, I took part of a good discussion yesterday about the requirements a language should have to be considered as part of the Lisp family. In this case, they argued that LFE is not effectively Lisp, but just a language with syntax similar to Lisp, because for instance it doesn't have homoiconicity (I'm not sure about this statement). Why is it this exactly? The same rationale would apply to Clojure?

should i bother with namespaced keywords? I'm guessing the answer is "it depends", but then i'm wondering what it depends on 😞

If you're starting a project from scratch, I would make an effort to use them and get used to them.

Sure, you have to map them to/from unqualified keywords for your API (either REST/like input and results in JSON or HTML forms and URL query params), but that's to be expected -- and no reason to avoid them inside your code.

If you're doing JDBC stuff, next.jdbc's default is qualified keywords. Datomic uses qualified keywords. Spec is really all about qualified keywords.

They have a lot of semantic benefits, e.g., a :person/name is different to a :product/name, after all.

for ones with namespaces, it seems I don't actually need to declare them somehow, right? I just pretend they exist?

i just read this btw: https://vvvvalvalval.github.io/posts/clojure-key-namespacing-convention-considered-harmful.html

i agree about the pain of namespaces for things that hit the wire or go into a database. but for internal stuff it makes it quite nice to disambiguate keywords and usage. For instance, our backend sends a websocket notification message with topic :report/progress and :report/complete. (over the wire but we use edn so it works for us). Finding the emitters and consumers of these notifications is quite easy. if they were just :progress and :complete there could be hundreds of instances of these keywords. But i can quickly find these particular notions of progress and complete. His argument that "report_progress" and "report_complete" can go in a db without change is true but these are ephemeral data in motion so we don't have that issue

> things that hit the wire or go into a database There's no problem with them going into the database: the qualifier is simply ignored (by both clojure.java.jdbc and next.jdbc).

With c.j.j you can get qualified keywords on things coming out of the database, but it's primitive: you can specify a simple :qualifier "prefix" and that's it. With next.jdbc, it tries hard to put "sensible" qualifiers on the keywords, matching the table the column comes from (very useful in a joined query).

It won't surprise you that I disagree with a lot of that article 🙂

If our front end was ClojureScript, rather than JS, we'd probably traffic in EDN or use Transit so we could keep qualified keywords in play right from the user interface all the down to the database and back again.

your comments let me know of this "surprise" 🙂

You should have seen the dust up on Twitter about it 😆

surprising. its normally nuanced and sincere 🙂

along similar lines.. if you are dealing with Java objects do you sort of treat those as "over-the-wire" and turn into a common format, or just use them "as is" in your clojure code... unless of course all your code is clojure in which case moot question.

@joel380 Since that blog post doesn't support comments (which seems to be an unfortunate trend on blogs, these days, so you can only take the posts on face value, without the benefit of an actual discussion), it might help you to read this thread about it https://clojureverse.org/t/clojures-keyword-namespacing-convention-considered-harmful/6169

Oh, now the comments are loading on the blog. They wouldn't load earlier so I thought there were no comments there. I know the discussion happened in multiple places.

Re: Java objects -- can you provide a bit more context @joel380?

Clojure is a hosted language that expects you to use Java interop. Not sure what "over-the-wire" would mean in that context: it's very common for Clojure code to manipulate Java objects.

I have an edn file with a map, I would like to retain the written order of that map. Is there a way to accomplish this?

Hey all. I’m just starting out with Clojure and coming from a JS background. I’m having a bit of trouble understanding variable scope. Here’s an example from a Udemy course where a validCoupon variable is defined in a function isCodeValid and then used inside another function called getCarPrices. You can’t do this in JS because function scope boundaries hide internals from each other. So what is happening when validCoupon is assigned? Is that variable now available on a “global” scope relative to the namespace (ie file)?

This is bad code and you should take a different course :)

def creates a global var and should only be used at the top level of your code

Inside a function you should use let to create lexically scoped locals

@alexmiller Ah that makes a ton more sense. Actually, I’m realizing a big issue with this course is that the instructor doesn’t introduce scope at all. The section on Variables talks only about immutability, valid characters, and case sensitivity but not scope.

link to course @rosschapman?

https://www.udemy.com/course/clojureprogramming/

@rosschapman Have you seen this book? It's a good place to get started: https://www.braveclojure.com/foreword/

dev=> (car/wcar {:host "localhost" :port "6379"})
Execution error (ConnectException) at  (Net.java:-2).
Connection refused

Anyone ever have issues connecting to redis from the repl?

For us folks trapped in json-land... Is writing clojure spec directly against the incoming json data model and generating json schema for clients from the clojure.spec effective? I'm hoping that spec can be leveraged somehow for transforming directly into clojure data down the road (whereas for now we likely use existing Java objects).

Well, you'd have to convert from JSON to keyword-based hash maps before you could apply Spec, so you could either use :req-un/`:opt-un` on plain keywords (and later convert to whatever internal qualified-keyword domain structures you wanted) or perhaps arrange for the JSON-to-map conversion to add qualifiers and use regular Spec stuff (`:req`/`:opt`). But in Spec 2, handling of unqualified and qualified keywords diverges further due to s/schema/`s/select` effectively replacing s/keys.

This code leads me to believe that clojure = does some kind of structural equality check between lists? Is that correct?

(= (list ()) (list ()))

Clojure's = does a nested value check across types with similar properties. So yes.

> (= ()
     (for [x ()] nil)
     []
     (list)
     (map identity []))
true

On a similar note, I usually use (frequencies) to compare 2 maps (such as (= (frequencies map-one) (frequencies map-two)) ). Is there a better way to check map equality, or is that the de-facto solution?

you should be able to do (= map-one map-two). are you seeing unexpected results?

Sorry, I mis-typed. I mean to compare lists independent of order. I've been comparing lots of lists of maps, which is why I remembered wrong.

> (= {:a 1}
     (hash-map :a 1))
true

comparing frequencies seems reasonable for comparing seqs in an order independent way. depending on the situation, it might also be a hint that you're using the wrong data structure

In Sean Corfield's usermanager example, compojure handlers are specified with a leading #' . The app has a model view controller architecture, and within the controller, calls to (assoc-in request ...) are used "add" data into the request map and pass it into the views. I find the same thing in a similar example using reitit, for example ["/list" {:handler #'user-ctl/get-users}]

#'

In my experimentation with building an MVC app using reitit, I've found that (assoc-in request ...) does not work unless I specify the handlers with a leading #` . I also seem to be having issues passing form params into the controller for processing. In a functional sense, what is this doing in this case?

user=> (def x 1)
#'user/x
user=> x
1
user=> #'x
#'user/x
user=> (deref #'x)
1
user=> @#'x
1
user=>

So it is passing a var rather than evaluating the handler immediately?

not exactly

a var is its own thing, and it evaluates to itself

a var is the little mutable cell top level definitions are stored in

which is why if you define a function f, then define a function g which uses f, then redefine f, g will use the new definition

g refers to f through the mutable var, and if you redefine f it just mutates the var

vars have a useful feature that they can be invoked like functions, and when you invoke like functions they just invoke whatever value they have with whatever arguments where passed

user=> (+ 1 2)
3
user=> (#'+ 1 2)
3
user=>

passing vars instead of functions allows you to update by defining the vars, and have the server pickup the new behavior without being restarted

Ok, I see this behavior in the routing libraries.

Thanks for the higher level explanation @hiredman

What makes this behavior different when running the server? in pure clojure function g implicitly uses the var's new definition for f, by just using f's name, but with the server you need to pass the var directly

@kaxaw75836 It's not about "server" vs "pure clojure" -- it's about contexts where the (current) value of the function is captured and therefore new definitions of it are not seen.

Here's a REPL session that shows where this comes into play:

user=> (defn f [g] (fn [coll] (map g coll)))
#'user/f
user=> (defn q [n] (inc n))
#'user/q
user=> (def ff (f q))
#'user/ff
user=> (ff (range 5))
(1 2 3 4 5)
user=> (defn q [n] (dec n))
#'user/q
user=> (ff (range 5))
(1 2 3 4 5)
user=> (defn q [n] (inc n))
#'user/q
user=> (def ff (f #'q))
#'user/ff
user=> (ff (range 5))
(1 2 3 4 5)
user=> (defn q [n] (dec n))
#'user/q
user=> (ff (range 5))
(-1 0 1 2 3)
user=> 

Note how the first redefinition of q is not picked up by ff -- we still get the inc-based version -- but in the second section, where ff was def'd to use a Var reference #'q, the redefinition of q (to use dec) is picked up by ff in that last call.

This is essentially the pattern used in middleware and (some) routing definitions in web apps in Clojure, which is why it matters.

^ @nando @kaxaw75836

got it! 👍

@seancorfield Thanks for the explanation. It's a subtle but essential point that isn't highlighted in router docs or simple examples. Very thankfully, changing my router handlers to use var references solved all the mysterious issues I was having. Suddenly, data is persisting properly to a datomic dev-local instance from a form and I have a list of that data displaying in my app! 😀