Ah yes, the missing seventeenth way to validate function parameters.
Clojure 1.13 adds support for checked keys
21–30 of 50 posts
Re: Clojure 1.13 adds support for checked keys
#22I love the idea of clojure and perfect immutability, but holy crap I cannot grok the syntax. My C-trained brain explodes.
It'll take a while but now other programming languages look alien to me.
Once you've adopted s-expressions it is hard to go back.
Re: Clojure 1.13 adds support for checked keys
#23I love the idea of clojure and perfect immutability, but holy crap I cannot grok the syntax. My C-trained brain explodes.
It took about two weeks for me to be able to read it.
Might as well have been Russian.
Now it's as natural as any other language.
Re: Clojure 1.13 adds support for checked keys
#24Earlier quoted context omitted.
The maps are still open to new keys even if some keys are checked. I think that fits in with how clojure.spec and Malli work already, but in a lighter syntax.
The maps haven't changed at all, this is a feature at destructuring sites.
Sorry if I wasn’t clear, I was referring to the maps that are being destructured.
Re: Clojure 1.13 adds support for checked keys
#25This is actually great, and I predict that fans of nil-punning will rapidly discover the joys of actually having errors trigger where the error was introduced rather than propagating through the program. Any news on ClojureScript gaining the feature?
What is nil-punning?
allowing functions to treat nil arguments as empty versions of their expected types
Re: Clojure 1.13 adds support for checked keys
#26This is a case I never really thought about - if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program I know this sounds unreliable but in practise I like a language that defaults to pragmatic code paths so I don't have to stay up at night imagining a million code paths This adds a throwing codepath which is quite drastic s…
This is really the kind of thing you want to fail at compile time which isn’t real possible in a dynamic language like Clojure.
Re: Clojure 1.13 adds support for checked keys
#27I love the idea of clojure and perfect immutability, but holy crap I cannot grok the syntax. My C-trained brain explodes.
You get over it really quickly once you start actually using it. I find it basically impossible to read Clojure outside the editor in any meaningful sense.
Re: Clojure 1.13 adds support for checked keys
#28This is helpful, because practically many functions in the wild have assert-like checks at the top of the function, e.g.
`(if-not key1 (throw (Exception ...))`
...and pre-conditions, e.g. `:pre [condition1 condition2]` do not run when `assert` is off.
Re: Clojure 1.13 adds support for checked keys
#29This is a case I never really thought about - if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program I know this sounds unreliable but in practise I like a language that defaults to pragmatic code paths so I don't have to stay up at night imagining a million code paths This adds a throwing codepath which is quite drastic s…
This is really the kind of thing you want to fail at compile time which isn’t real possible in a dynamic language like Clojure.
Unless you use Typed Clojure, which is a library.
https://github.com/typedclojure/typedclojure
I haven't used it, so I don't know its tradeoffs; but its docs say its types exist at compile time: https://github.com/clojure/core.typed/wiki/User-Guide
Re: Clojure 1.13 adds support for checked keys
#30This is a case I never really thought about - if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program I know this sounds unreliable but in practise I like a language that defaults to pragmatic code paths so I don't have to stay up at night imagining a million code paths This adds a throwing codepath which is quite drastic s…
This is really the kind of thing you want to fail at compile time which isn’t real possible in a dynamic language like Clojure.
Well it is possible - you can add a user macro that calls into clj-kondo (or anything actually) to check your codebase on compile
It just doesn't make much sense to do - most modern developers will be running static analysers through LSP or their editor (knowingly or not) continuously on code change so as to see those errors quicker than re-compiling the program