Fork me on GitHub
#clojure-europe
<
2022-10-22
>
slipset10:10:54

As one might do on a Saturday, I was perusing http://ask.clojure.org, and was pointed to https://ask.clojure.org/index.php/11409/somewhat-confusing-sorted-set-behavior?show=11410#a11410 question where my colleague asks for the rationale for why (:foo (sorted-set (range 9) throws an exception. @alexmiller ends up responding that the behaviour is “undefined”. Now given Zachs talk above which includes the principle of least surprise, I’d say that since (:foo (set (range 9)) gives nilit’s somewhat surprising that (:foo (sorted-set (range 9)) throws, and one could argue that it’s not well designed, at least following the principle of least surprise. Another way to look at this is that you could argue we’re looking at an interface for sets, ie the operations and the guarantees that those operations give, and I guess that we could look at this as get for set. Now the doc string for get says:

"Returns the value mapped to key, not-found or nil if key not present
  in associative collection, set, string, array, or ILookup instance."
Nowhere does this say “get might throw an exception”, but it also doesn’t specifically mention sorted-sets, but I’d perhaps be lead to think that sorted-set is a subtype of set. I guess the thing that’s problematic for me is that I’d like to think that I program against an ADT of type Set, and which concrete implementation of Set I pass to my fns shouldn’t change behaviour in exceptional ways, ie the “get me the :foo in this set if it exists” behaviour shouldn’t change just because someone upstream from me started sending me a sorted-set of ints rather than a normal set of ints. Wow, that was a lot. Sorry 🙂

1
vemv01:10:39

> If you have a sorted set of strings, asking whether it contains a keyword is an exceptional case. What should that even mean? I'm with Alex here and would even one-up it: not only it's an exceptional case, but it's a should-literally-never-happen case. Which is guarded by :pre, Spec and friends

vemv01:10:02

...for me an AssertionError (as thrown by :pre) is not an exception, it's more akin to a compilation error - just that it's thrown later because we're using a dynlang.

slipset08:10:48

Just to harp on this: Analogy: Imagine customs asking “Are there any contraband in your suitcase?” and then suddenly, because someone sorted their socks, the airport blows up?

😂 1
slipset09:10:17

And, you could argue that customs should wrap their checking in a try/catch because someone might sort their socks, but no where is there an indication that that would be prudent. Docstring for sorted-set says > “Returns a new sorted set with supplied keys. Any equal keys are > handled as if by repeated uses of conj.” It doesn’t say “and by the way, we’re leaking this detail of java comparators throwing on unequal types, please use sorted-set-by with a comparator that handles hetrogenous types if that’s ever going to be a problem”

slipset09:10:43

To give you a point though (and perhaps myself 🙂 the Javadoc for Sets (https://docs.oracle.com/javase/8/docs/api/java/util/Set.html) says in the last paragraph that “…attempting to query the presence of an ineligible element may throw an exception…“, which you may or may argue is good, but at least in Java, the behaviour is documented.

slipset09:10:19

Which one could argue would make the behaviour somewhat less surprising.

vemv09:10:41

Morning! > Imagine customs asking “Are there any contraband in your suitcase?” and then suddenly, because someone sorted their socks, the airport blows up? But imagine that that question is known trigger detonations. Then, only trained staff would ever ask it. So no detonations ever happen in the prod airport :)

slipset09:10:10

Yes, but how would they know?

slipset09:10:31

There is nothing AFAICT in the Clojure docs that would let you know this.

slipset09:10:01

And, one could argue (and I’m not, perhaps) that it’s a wasteful use of trained staff just because someone every once in a while would choose to sort their socks 🙂

vemv09:10:15

> Yes, but how would they know? x-rays! leaving our funky analogy aside, I do agree that clojure.core has its warts - quite a lot in fact. If I weren't so lazy I'd use the speculative library for instrumenting clojure.core, instead of hitting the same issue once a year

slipset09:10:47

xrays could be contains? which also throws 🙂

vemv09:10:55

for our practical case it seems well possible to say "this is a Set<Sock>" such that asking it about Contraband is simply a non-sensical q

slipset09:10:25

It just seems surprising to me, I guess, given my perception of Clojure.

vemv10:10:08

I'm not sure I perceive clojure.core as highly as many other wonderful things from our community 🥴

teodorlu11:10:31

I'm very much looking forward to reading that book he's writing.

teodorlu11:10:45

I think you're making a good point, Erik. I'm also surprised by that piece of behavior. Not sure what the right course of action is, though.

slipset11:10:01

I think a reasonable course of action is the one taken, leave it be. There are many considerations to be taken, principle of least surprise is but one.

👍 1
slipset11:10:55

But @U0ETXRFEW, you have a repl for your bash-scripts. it’s the terminal 🙂

😄 2
pez12:10:38

Norwegian humor... 😃 I did make this distinction clearer in the Twitter version of the post, though: https://twitter.com/pappapez/status/1583791897432453120

borkdude12:10:48

Does the bash shell clarify more as a REPL or as a shell given this table by Stuart Halloway? https://twitter.com/soulcutter/status/1304599836302376960/photo/1

borkdude12:10:26

At least it passes the "function redefinition is seen by callers" test

#!/usr/bin/env bash

g() {
  echo "hello"
}

f() {
    g
}

f

g() {
  echo "dude"
}

f

slipset12:10:45

That was exactly what I was testing too 🙂

slipset12:10:30

Which to me is one of the most important bits of working with Clojure in a REPL, you get to redefine fns in a “call stack” without re-evaluating everything above it in that stack.

slipset12:10:05

I’d argue you’re also showing “sequential evaluation of forms”

slipset12:10:48

We have eval

borkdude12:10:26

JavaScript also falls into this category

slipset12:10:16

Doesn’t that depend? Like if you start messing with objects/classes and such?

borkdude12:10:35

but I don't think JS qualifies as a REPL language since it's not expression-oriented and nowadays ES6 imports make the language more static than it has been

borkdude12:10:41

yes, it all depends

slipset12:10:49

You expert, you 🙂

borkdude12:10:03

A slide from upcoming presentation that shows my attempt to make a CLJS on ES6 dynamic again...

slipset12:10:13

I think it’s a repl if it invites you to do repl-driven development, and as such, neither bash nor js has a REPL 🙂

slipset12:10:55

Of course, I just sidestepped the whole thing of defining a REPL, by having us define REPL driven development instead.

borkdude12:10:11

I kind of took the REPL thing for granted when I did common lisp but when I took my next job that involved C# (because no lisp in industry in my area at the time) I had a @U07SQTAEM -like reaction feeling that it was a huge step back

borkdude12:10:13

And I was only 24, already dismayed with the industry!

😂 3
borkdude12:10:19

sorry for nostalgic ranting ;)

slipset12:10:27

Nothing to be sorry about. I’m on my recovery path from Covid, so looking for any kind of entertainment I can get, since I’m still not where I can go out and do the things I’d like.

❤️ 2
🍵 1
borkdude12:10:07

Hope you feel better soon. Just got my renewal shot last week - no guarantees of course 🤞

slipset12:10:35

I’ve got three shots, so it’s mainly just a cold.

👍 1
lread13:10:18

Ok, how has nobody commented on the photo of @U0ETXRFEW cosplaying as babashka yet? It's pretty awesome!

1
❤️ 1
lread13:10:14

Sorry you got sick @U04V5VAUN, hope you feel back to normal soon!

💜 1
borkdude13:10:24

Also, he's probably the first person on earth to be seen with a bb t-shirt!

lread13:10:01

Maybe even the first in whole universe! Yoiks, think of that!

wow 2
lread13:10:31

G:babashka:babashkad M:babashka:rning!

babashka 4
otfrom16:10:36

morning

1