does memoization care about the order of arguments?

@hermannkevin Yes, the arguments are treated as a vector of values and used as a key into the cache. Why?

i got a function I'd like to memoize and ideally I'd want to ignore the order

Look at org.clojure/core.memoize -- it lets you use metadata on a function definition so you can provide a function to apply to the arguments before they are used as a cache key.

You could specify set so that a set of values instead of a vector of values is used.

thanks, that looks like what I want!

Example (`memo` is an alias for clojure.core.memoize):

user=> (defn ^{:clojure.core.memoize/args-fn set} foo [a b c] (println 'foo a b c) (+ a b c))
#'user/foo
user=> (def bar (memo/memo #'foo))
#'user/bar
user=> (bar 1 2 3)
foo 1 2 3
6
user=> (bar 3 2 1)
6
user=>

You could provide the metadata at the point of memoization if you don't control the source of the function

user=> (def bar (memo/memo (with-meta foo {:clojure.core.memoize/args-fn set})))
#'user/bar
user=> (bar 1 2 3)
foo 1 2 3
6
user=> (bar 3 2 1)
6
user=>

thanks, that worked for me.

Is there a (quick) way how to generate lein's project.clj (or at maven's pom at least) from deps.edn file?

Hi there. I need some help with Java interop. I'm trying to call a java method but clojure keeps picking the wrong implementation of the method to call. I want the one taking a string argument, but it chooses the one taking the URI argument, and then tries to cast the string I pass in into a URI.

user> (import '[java.nio.file Paths])
java.nio.file.Paths
user> (Paths/get ".")
Execution error (ClassCastException) at user/eval12360 (form-init19142548285076119.clj:2354).
java.lang.String cannot be cast to java.net.URI

I want to call the variable arity string form: https://docs.oracle.com/javase/7/docs/api/java/nio/file/Paths.html

annotating the argument with ^String doesnt help

how do I help clojure choose the other method?

A little tangential but I've written a Clojure wrapper for the NIO2 stuff in Java which might be helpful: https://github.com/logicblocks/pathological

@retrogradeorbit how did you annotate the argument? That should have been sufficient

user> (Paths/get ^String ".")
Syntax error reading source at (REPL:2357:29).
Metadata can only be applied to IMetas

@toby924 that library looks perfect! Thanks very much for pointing that out!

I'm about half way through the documentation: https://logicblocks.github.io/pathological/

I want to create a symlink, but another library for clojure nio was missing symlink functionality. But I see yours has it! 👍

I will read your source with intrigue

Happy to throw together a getting started if it would be useful

@retrogradeorbit on your specific question, there are 2 arities of (Paths/get ...), one that takes a single argument of type URI and one that takes two arguments, the first a string, the second, variadic of strings. To invoke with just a string, you also have to provide an empty variadic argument which for Clojure is an empty array.

oh ok interesting. Im not a Java coder... so not something Im familiar with

So:

(Paths/get "." (into-array String []))

user> (Paths/get "." (make-array String 0))
#object[sun.nio.fs.UnixPath 0x3ae4beac "."]

well I'll be!

Yep, either of those would work

warty!

love it. thanks heaps @toby924

👍

No problem

Hi, does anybody know if it is possible to somehow flush protocols' MethodImplCache caches? I'm using tools.reloading a lot in a project, and it looks like these caches are the reason for a memory leak. since they retain the class objects that transitively hold onto some state that I recreate between reloads.

They get flushed when you extend the protocol I think, maybe you could abuse that

@alexmiller Thank you! I will try that. Right now, it looks like the exact offender is clojure.core.protocols/coll-reduce. I will try to dummy-extend it. But I assume that this has to be done for every non-reloaded protocol that ever sees my "heavyweight" classes, right?

presumably

What would be the simplest way of serving a static directory of files via http with clojure?

hi, please advice, how I can invoke java method with var string args?

(java.nio.file.Paths/get (into-array String ["/tmp"]))

close, since the first argument isn’t varargs you need this:

(java.nio.file.Paths/get "/tmp" (into-array String []))

it’s a known issue and you can vote for it here: https://ask.clojure.org/index.php/4224/java-method-calls-cannot-omit-varargs

oh, thanks!

what's the proper name for ::user or ::s/user compared to :mynamespace/user?

aliased keyword? namespaced keyword (but the latter one is too)?

latter if fully-qualified keyword

former is aliased I'd say, all of them namespaced

I'm looking for an option name in a parser to parse the former keywords, would :aliased-keyword sound good?

the ::keyword is an "auto-resolved keyword"

it resolves to a "qualified keyword"

ah, so :auto-resolved-keyword

sure

aliases are really a feature of namespaces, not keywords

a symbol or keyword qualifier may or may not match a namespace alias

or maybe I'll make a separate option :auto-resolve so it can be orthogonal of keywords maybe

or just :resolve

:resolve-alias... hmm

only applies to keywords

well, also maps I guess

but also to maps no?

yeah

so sure

thanks!

i think i asked this a while ago and unfortunately its lost to the history. is there a way to spec a seq such that its first three members match specs and then the elements after that come in pairs matching a spec? ie, [:X :Y :Z], [:X :Y :Z :thing1 :thing2], where thing1 and thing2 can repeat but only in pairs?

(s/cat :x ::x :y ::y :z ::z (s/* (s/cat :t1 ::thing1 :t2 ::thing2))) ?

yeah that works perfectly. Is there an easy way to conform it back to the original vector? unfortunately this produces a map when we really want the original vector back

in short, no

(and thank you for responding)

yeah. was afraid of that.

although you could wrap it in (s/nonconforming ...) to get literally the input back

thank you. i think s/nonconforming is new to us and seems quite helpful

I thought *ns* would be a nice option to designate the current namespace, like in:

$ lein run "::foo" "{:resolve-alias {*ns* bar}}"
:bar/foo

user=> (require '[clojure.string :as *ns*])
nil
user=> (*ns*/starts-with? "foo" "f")
true

aliases are an independent naming space

and because they only appear in qualifiers, they never collide with var names

what is an example of a qualifier?

a in a/b

or :a/b

oh you mean var names in the current namespace, unqualified

yeah, I was only talking about for an options map, to talk about the "current" namespace, to resolve ::foo, *ns* is apparently not a good choice, since that can already be taken (although that would be very weird). Maybe :current is better

I see

generally, prefer keywords for "special" enumerated values, yes

yeah, it's very nice that symbols and keywords can't conflict

so something like this:

$ lein run "[::foo ::str/foo]" "{:resolve-alias {:current user, str clojure.string}}"
[:user/foo :clojure.string/foo]

I'm trying to validate the contents of a vector such that my function returns true or false. For instance, I have this function

(defn valid? [vals]
  (map (fn [num] (> num 0)) vals))

@brian.rogers every?

Amazing thank you @borkdude!

every? has "noteworthy" behavior on empty collection:

user=> (every? (fn [n] (> n 0)) [3 2 1])
true
user=> (every? (fn [n] (> n 0)) [])
true
user=> 

I'm curious to hear the Clojure philosophy on this

seems natural to me. every item in the collection satisfies the predicate

Python too:

python
>>> all([])
True
>>> any([])
False

What seems more out of place, is that every?'s counterpart is some and not some?

Huh, that's noteworthy too (`some` vs some?)

every? returns a boolean since its about the entire collection. some does not as its about an individual element. the ? is appropriately missing

I have no problem with how every? works. I think I just had some deep-rooted instinct that imagined a boolean-flag not being set to true until the predicate had run at least once.

As an exercize, implemented every? in Java (my most familiar language) and can see that even my instinct is probably wrong. The method is trying to falsify something. Start assuming everything is ok. Iterate collection and look for something that violates the predicate. If the collection is empty, nothing violates it. So I had bad instinct here.

the best way i know of it is, "if its false, show me a counter example"

To be honest, I wouldn't be surprised if there isn't a few bugs out there due to every? returning true of empty set

in mathematics this is know as "vacuously true"

"you're not wrong" vs. "you're definitely right" 🙂

also see and, s/and, and more in Clojure

user=> (and)
true
user=> 

Ya, it doesn't matter what its known of as in math :p. I'd still bet there's a few bugs due to it out there. I'm not saying it's the wrong behaviour. Just it doesn't really fit he principle of least surprise unless you know about the vacuous truth

as someone is fond of saying "people are surprised by many things"

I would find it very surprising for these functions to not respect the vacuous truth aspect of logic and I think you'll find this is common not just in math but across many programming languages

Totally agree on likelihood of bugs with every?. I'm not as convinced this is elevated to a violation of least-surprise principle. Especially given my daily encounters of code that violates surprise -- I find these violations far more... sociopathic and sinister. every? is much more of a nuanced "oops" (IMHO).

I'd be super surprised if (every? satisfies? constraints) returned false when I had no constraints

That's true that either way it would surprise someone somewhere and possibly lead them to a bug. I think that's a cognitive load that's often downplayed when learning higher level languages like Clojure though.

If you had to implement every? yourself for example, the behavior would be more apparent to you.

That's why I believe the REPL is an invaluable tool

Because validating your assertions is really important in Clojure

Btw, the wikipedia article does say: > Outside of mathematics, statements which can be characterized informally as vacuously true can be misleading. Such statements make reasonable assertions about qualified objects which do not actually exist. 😝

And it goes on to say that even in math, vacuous truth is mostly of no interest, except as a base case for inductive proofs. So I do wonder what of interests it is in a comp-sci context, unless you're implementing an inductive proof.

recursion is induction

"every datum should satisfy every constraint in this list of constraints, if there are no constraints they automatically pass, if there is no data it automatically passes"

that's two vacuous truths that are relevant to normal business logic

so inductive proofs are deeply relevant in computer science

and yeah, in recursion, vacuous truths are common as base cases at the end of recursion

so datastructures built and destroyed recursively (like a linked list) are sometimes called inductive datastructures

"every datum should satisfy every constraint in this list of constraints, if there are no constraints they automatically pass, if there is no data it automatically passes" Except, by the wikipedia article.and my own impression, I believe that for most domain outside of math, that's not going to be the correct or common requirement.

the wikipedia article is incorrect

s/math/logic/

programming languages are symbolic logics

@didibus I literally implement that logic, in multiple apps

> so datastructures built and destroyed recursively (like a linked list) are sometimes called inductive datastructures I don't believe vacuous truth matters here. That's just a different use of the word induction, but it's no longer relevant to the vacuous truth as far as I can tell.

it does

the behavior for the empty collection relies on a vacuous truth

just like in my example

@noisesmith Can you describe a use case that needs it like that?

one thing is without vacuous truth, (not (every? pred ...)) would differ from (some (complement pred ...)) and that would be quite annoying

@didibus a request against the foo service requires permissions [bar baz quux], instead of hard-coding this check, I map each request to a vector of conditions the requesting account must pass

an empty list of conditions means the request is always valid

Woa, that's like exactly one of the use case I was thinking where this would lead to possible huge security vulnerabilities

Why would you default to allow access?

it's not a vuln because I literally map from action to checks, and error on not found

it's only a default to allow access if you explicitly provide an empty list of checks

How does that work from the user side? They submit an empty form?

I just checked, and even SQL follows this logic with the ALL operator, which is interesting because SQL sometimes makes similar things a syntax error (e.g., x IN () - an empty list).

@didibus the perms, in code, are a hash map literal from action to checks

the user simply submits an action, the code uses the mapping

ruby too...

irb(main):001:0> [].all? {|a| false }
=> true

@didibus a mapping from action to validations is much harder to get wrong than a huge nested conditional

But if the checks is empty it will allow the action right?

and python

>>> all([])
True

@didibus sure, it would also be an error to say (def perm-check (constantly true)) - that's a logic bug in both cases, it's not a problem with the technique

it's a really hard thing to get wrong - an empty vector stands out like a sore thumb

Ok, but that's different. You're just saying it would never be empty because of some other reason

Not that you rely on every? returning true when empty

no, I'm saying relying on vacuous truth maps intuitively to domain logic such that the permission checking code is easier to maintain

and java

jshell> Arrays.asList().stream().allMatch(e -> false)
$1 ==> true

right, this is standard, it's not just a clojure thing, and especially with recursive code it just makes sense

Hum.. ok I didn't understand then. What part of the logic benefits from the vacuous truth?

in a recursive function (defn all-true [conditions] (if (first conditions) (and ((first conditions)) (recur (rest conditions))) true))

we don't usually need to recur for this, we have functions like every?

it relies on the vacuous truth that if a list of conditions is empty, any assertion you make about each item is true

Okay, we're arguing at different level

it's not just true in this case - this is a clear example of it being true

I'm saying that in most domain, an empty list of condition being true is misleading. And so is all vacuous truth statement.

and I'm saying that's false and providing my counter examples

But I understand that for some base case, you want empty to default to true, mostly for inductive proofs and maybe a few recursive logic not sure.

But those are for the domain of math

not just for that case

look I'm going to stop spamming the channel @didibus but it's also true for javascript, SQL, and excel. so I think the world just doesn't agree with you

also for things like "every condition returns true for this input" (empty condition list - always true) or "every member must attend this meeting" (no members, always true)

Ya, I understand this isn't special to Clojure. I'm not against what Clojure did or not. I just feel when leveraged as domain logic, it is misleading. And the wikipedia article acknowledges that. So I feel the world might agree either way.

When would you want every member must attend this meeting, no member to be true?

Like, should-reserve-room? Well clearly you don't what to reserve the room if there's no members showing up

thats an ANY question though

no, more like raise an alert to management if any members didn't attend, no applicable members means all checks pass, no alert

The tension isn't between math/logic vs prog languages, the tension is between math/logic and "common sense". For another example: me and wife getting ready to go out somewhere. Wife: "should I wear the blue shirt or the red shirt?" Me: "Yes." Wife: smacks me.

Wait... raise an alert? That would be on true, so every? Would raise an alert even if there was no member

Mathematically I'm right. In common sense, I'm not. Math "or" is not english "or".

i think a better example of didibus's point would be your boss asking you "have you completed all your tasks?", and you say "yes" when you haven't been given any tasks.

(if (every? not-attend members) (raise-alert))

It's when a programmer like me innocently is thinking in english rather than math that bugs might occasionally pop out of using every?

@isak right, and in a program that answer would be correct

@didibus but that's still wrong, (if (not (every? ...)) ...)

@noisesmith yea I know, but in real life the "right answer" would be "not applicable"

the boolean function can't return "I haven't been assigned any tasks"

@noisesmith what do you mean in a program that would be correct? That sounds like 100% a bug

In expected behavior

this is exhausting, sorry, I don't see this discussion going anywhere

in real life, you can "throw an exception", or refuse to accept the type constraint of the question

Hum.. that's kinda what I mean. You now need additional checks to avoid introducing a defect from the empty set treatment of every?. So, we can all agree to disagree and I'm not suggesting changing the default, you need to know it and deal with it. Being consistent with all other languages is probably best. And like Alex said, defaults are never always right or always wrong, there's always someone surprised no matter what. Now, personally, I think it makes total sense to say that this behavior is often misleading. That misleading property is inherent to the vacuous truth. Math chose the default convenient to the use cases most common in math. And I think programming languages chose to be consistent with math. But that does mean that when using every? to implement business logic and rules for most non math domain, you should be careful to special handle the empty set.

Deploy to Clojars4s
user=> 
Run clojure -A:deploy
  clojure -A:deploy
WARNING: Specified aliases are undeclared: [:deploy]
Clojure 1.10.1
user=> 

(if (every? :completed tasks) (disburse-payment) (withhold-payment))

:pre [(every? some arg)]

if the payment is (apply + (map :cost tasks))

you can either understand the contentions of logic and use them to your advantage or stub your toe on them every time you interact with a formal system

that piece of code is pretty contextual and it could work or not work depending on how everything is set up

if having no tasks means every task is completed or there’s nothing stopping you from disbursing a payment, would be fine

yea that is not a good example. Better would be: if you completed all your tasks for the day, and there was at least one, you can go home early.

I think that's a great example. Please find me a business owner who wants people paid for doing nothing.

that is an error in programming though

you are missing the "there exists a task" part of the spec

Yes, that's exactly my point.

This is a bug

Because the behavior of every? is misleading to its user

i don’t really see the point of this conversation anymore. the bug isn’t with the every? it’s with the code itself.

the bug is a poor understanding and translation of the spec in an informal system into a formal system

And so I wouldn't be surprised if you can find quite a few bugs in the wild introduced by every?

You can always say a bug is a poor understanding and translation. All bugs are like that

And every bug introduced by mutability are poor understandings of mutation

i feel like you just answered your own question

What do you mean?

I think maybe we've derailed a bit. I'm making a software correctnes argument, and ya, I lack empirical evidence for this. But just like I believe mutability leads to defects, I believe every?'s behavior on empty set does as well. Both because of the same reason, the cognitive burden and mismatch to the programmer.

and your suggestion is to diverge from the common behavior from logic, mathematics, and most programming languages

Well... I mean... isn't that what FP advocates try to tell everyone else 😋. But no, in this case I think it would be worse to do so. I'm not sure how to best address this issue. My take will be to bring it up early on and mention it say in clojure-docs that you might be surprised by its handling of empty set.

i agree the docs could probably be more clear

So if someone asks, why does every? return true on empty. I won't say... oh here's why? (super smart reason that is very convincing) I'll just say: ya that's misleading, you just need to be aware of it, sorry, that's how it goes

the source code is clear about it and there are examples on clojuredocs of how it behaves with empty collections, but it’s not obvious from the docstring itself

i think the “here’s why” is pretty convincing but that’s just my opinion

Well, "because math" has never really worked on me, but ya, that could be personal

it’s also consistent with other programming languages (like ruby)

Well consistency can be why Clojure did it. But why did the first language do it?

Which all other copied

because math

🤪

Oh, that emoji looks way different on slack

That's not the right emotion

😝

That's better

And math seems to have done it to simplify the base case of inductive proofs

can we take this to #deadhorses or a thread?

Ya, sorry

not a problem, just think we've exhausted it

it's all adopted wholesale from java / maven

Hum... not sure. But it's pretty simple. We can probably summarize it to you quickly

there's a path, all entries on that path are merged, any resources are looked up based on that shared root

@deleted-user one thing that helped me immensely was using in the repl

It helps to open a jar file using winzip or some other zipping tool and just peak at the inside.

that looks something up on classpath, and shows where it was found (if anywhere)

Yes

user=> (http://clojure.java.io/resource "clojure/core.clj") #object[java.net.URL 0x14dda234 "jar:file:/Users/justin.smith/.m2/repository/org/clojure/clojure/1.10.0/clojure-1.10.0.jar!/clojure/core.clj"]

Its a zip with extension .jar

an editor that is worth using can usually open a jar directly

pom.xml is a file used by maven

Ya

maven is a tool for managing classpath

leiningen and deps.edn and boot all know how to use maven artifacts and repositories

Basically Java code is just compiled into .class files. And those are just zipped together into a library which by convention uses .jar as extension. Additional files can be put into that zipped file as well, at your choosing.

an uberjar is a merge of many jars

Uberjar is just when you put the files your app needs and the files all your dependencies also need together into one jar

And the classpath is just a list of paths to every file your app needs.

it's a list of roots that can be checked for the files

each root can be checked for a path

Which can point to jars as well, in which case it knows that means all files in the jar

right, maven is a tool that adds files and directories to the classpath

and lein, deps.edn and boot are maven compatible

Ya, so its similar. The package manager just downloads all required files, and then creates a list of paths to all of them in correct order.

The only annoying thing is that the paths on the classpath are to a file, not to a directory. So for every single file you need to add a path to it.

Right so one more thing that goes in a Jar is a manifest file

Which is metadata

And that tells you what the main file is if there is one

But you can also explicitly tell clj which one to use by passing --main if I remember correctly

Hum... ya not sure.

I mean you can put a custom metadata file in it

That you use for whatever you want

But I don't know if the default manifest file supports custom meta

I recommend not going down the rabbit whole of why every? is true for empty set 😛 As it seems to be a huge point of debate with no clear agreement both in the philosophy and math stackexchanges hehe. The most conclusive statement that seems to always happen is "Just Cause". As I just did, and lost a good afternoon of work.

But, the most logical one is that in propositional logic, For All statements are proved by showing that there are no example disproving the proposition. So a For All statement on an empty set cannot be disproved as no counter-example can be found, since the set has nothing in it, thus implying the proposition to be true.

And apparently, there are also vacuous falsehood. And in both cases, the term vacuous is used because it just points at an edge case.

Where vacuous falsehoods would be its negation if I got that right. Like, (NOT For All of pred empty set) is always false. That is a vacuous falsehood.

And vacuuous is used in the sense: "it doesn't really say anything meaningful"