why would it be insane?

you could always augment it down the road with: 1. Stringified commands via a dispatch map (e.g. myns instead of my.ns ) 2. per-command flag parsing (via tools.cli)

this is exactly what we do at cisco threatgrid fwiw

I thought it to be weird because of how hacky this feels

But it's so small and powerful! This approach already has per command flag parsing, using simple Clojure functions! Defaults support out of the box with destructuting. I felt it's strange that I've never seen any similar clojure command line interfaces

something with similar intent is actually in the new version of clj (dev version) I released last week. have not announced with details yet

I have so much to say about it, can't possibly summarize here (and it's actually scaled down from some other things)

Rich and I have actually been working on a variety of ideas in this area for several months, so fortuitous timing! :)

Woah, that's wonderful!

imo you've found a pretty good answer yourself. i try to use nil/none etc as little as the language allows me too. so yeah, it makes sense and i agree.

> nil should not be used to indicate a value so "person has no ssn" is {:person/ssn :ssn/none} instead of {:person/ssn nil}? I like it

This {:person/ssn :ssn/none} is a basically the "NullObject" or "EmptyObject" Pattern. I personally would prefer to not have that key set at all. The problem with nil is, it often happens that it gets a second meaning, like some error occured, or, the programmer did not know what to do in that special case and returns nil instead. So yea, I am also on the "avoid nil as much as possible" side.

"defined but uninitialised" and/or "is unset" sounds like a place-oriented mindset to me. If we instead take an information-centric view, {:email nil} is wrong, and I'd try to limit this kind of a thing to the very edges of the system. I agree with sveri that {:email :email/none} or {:email :gdpr/redacted} doesn't seem right either. The key should just be absent IMHO. That being said, I've never used Clojure in-anger (read: for work), so take this with a pinch of salt 😄

yes, @U883WCP5Z I agree too, that the key should be absent. However, when defining a configuration, it may be there. What should happen then? And by my reasoning on nil, I expect the program to behave as if the key was not defined. In other words, I do not differentiate between existence of a key that is set to nil and absence of a key, as, when I ask to get the value in both cases it will be nil. Considering nil as unset, then I can proceed to apply the same behaviour. From the perspective of information-centric or place-oriented mindset: this is based more on the information I have (a nil value) and less on the structure of information object (a map with key in place). I suggest that looking at the value (the data) at hand seems better than looking at the structure (the place). In a similar way, we can imaging the configuration as a function with the options as params. We call the function and in the process we pass arguments that match the params with values.

(defn compose_config [& {:keys [option-x option-y option-z]}] ...)

(assert (= (compose_config :option-x "foo" :option-y "bar" :option-z nil) (compose_config :option-x "foo" :option-y "bar")))

If the function inputs don't meet the contract then the behavior is undefined. you can short circuit and return an error to the caller to catch this before that point though. In your case, a spec on the config should inform caller's that nil isn't a valid value.

Anything else starts to assign business meaning to nil, which will be hard to maintain

but now you're talking about validation, which IMO is a separate step. The steps are: - get config (read/load/unserialize/etc) - set defaults ("parse" to get the different options) - validate - .. then use safely with the above function in mind, "get config" is achieved by call the function and passing arguments. "set defautls" is the step that I am discussing. And the question is whether a nil value that was passed in, or a nil value for an argument that was not passed in should be handled differently. I am arguing that it should be handled in the same way because nil would mean that the option is unset. "validate" is then invoked. The validation will actually check the types and structure of the compose configuration object/map. Spec is relevant here. > Anything else starts to assign business meaning to nil, which will be hard to maintain I think that what I described agrees with that

Validation would come before setting defaults. The function has a contract, I'm suggesting it's best to not have that include accepting nil values and trying to guess what a caller meant. The issue isn't what you can do with the nil, it's what did the caller mean by it.

Summoning Rich's words: "I'm worried about fred sheppy, is he missing?". When he covered this topic in his speculation talk.

You can reach the same goal with what your suggesting, but the seperation of concerns isn't as clear.

You can also validate at ever stage.

> Validation would come before setting defaults. How can this happen? a default will take the place of a configuration option value that is not set. How can you validate a configuration before setting values to the options? If you do that, then you allow nils. What is the point here?

> The function has a contract, I'm suggesting it's best to not have that include accepting nil values and trying to guess what a caller meant. the function says that it will compose a configuration object from the given configuration options. Some configuration options are optional. The function accepts "named arguments". It does not say that all arguments must be set.

> but the seperation of concerns isn't as clear can you expand on this more? what are the suggested step that you would put in place?

Destructuring sort of blurs the lines because you can no longer test contains?, you can only test for the value itself and assume that it was missing if the binding is to nil. If you follow the (best) practice of not having nil values in hash maps, that assumption is very reasonable -- and Clojure leans heavily on nil-punning so nil results from function calls are generally allowed to indicate "absence of result".

(-> args validate merge-defaults) There is nothing that prevents validation before merging defaults. But this is a side topic to the question you raised. What does nil mean? As you suggest, it's not a good thing to slot into any keys value. You can write a spec that says this key is optionally, but if you provide it, the value must be not nil. I'm agreeing it's a delima, I'm saying your system can't fix it. Garbage in garbage out, you can make a guess that they meant unset, but if the next caller means something else then it's going to fail. If it's acceptable for your system to assume and trim them out then it is, but that's a particular of your system and not a universal expectation.

The end result of the thinking in my blog post was next.jdbc.optional which produces hash maps that do not contain keys whose corresponding values in the database were NULL but with interop against SQL, nil has an important meaning when inserting/updating because you need something to stand in for the value that indicates NULL and because we're using JDBC -- Java libraries -- nil in Clojure and null in Java are the same, so in those hash maps: the setter equivalent and the by-example where clause equivalent have to contain nil values sometimes.

@U04V70XH6 makes sense because postures requires those slots be set by the caller right? It won't insert a nil by default? It's not a key value relationship, it's a tuple of a set size.

@U0DJ4T5U1 For inserts, it is less of an issue if a column has a default of NULL, but for updates you must have a way to signify that you want to replace a column's current value with NULL.

I tend to think of it somewhat like undefined in javascript. If something has a key with a nil, that means we know that is not available but if there is no key we don't know the actual value at that time. If that makes sense