Clojurians Log v2

Other than looking at the compiler source, does any documentation for case* exist? I thought I’d find it here, but I don’t see any mention of it. https://clojure.org/reference/special_forms

it's an implementation detail of case

you shouldn't use it directly

like other foo* things in core, it's a hook into the Compiler

fn*, let*, etc

Yes I know that I shouldn't use it directly. I am doing some analysis on fully macroexpanded code and trying to understand what to means. So I was curious if there is documentation on it. If not that is fine.

nope

case is surprisingly complicated as there is a lot of work to try to set up a tableswitch byte code - that code is kind of half split between code in core and code in the Compiler

case* is the transition point between those

to have implementation-detail special forms means the result of a macroexpansion is implementation-detail as well

that's not very helpful

it's not really helpful or harmful, it's a detail that few people ever see or are affected by

so how to deal with this detail when you happen to be affected by it ?

learn more about it, and figure out what you need to do for your use case? It is kind of a wide-open question, without a particular situation in hand that requires dealing with it.

it's not wide-open, it's about what can we rely on vs what is implementation detail

It seems unlikely that anyone has the time to answer all such questions about every aspect of Clojure in advance -- that would take years.

I mean, if you are hitting an issue involving case* and you want to ask about that, go for it. But if you just want someone to go off and write down every aspect of case and case* that is detail vs. promised-for-N-future-versions, it is hard to see anyone motivated to do so.

In what way are you affected?

I was affected in the writing of cloroutine, and I'm pretty sure core.async faced similar issues

basically every non-trivial macro needing to deep walk the ast needs a way to do proper macroexpansion

today the only robust way to do that is to rely on the official analyzer

There are only about 3 non-trivial macros, by that definition 🙂

so, this only affects people doing deep transformations on Clojure ASTs and there is an official lib that helps you do so

seems unimportant relative to many other things to me

I don't deny that

In part, because such macros are painstaking to write and test, I know.

what I mean is, in general, it's hard to figure out where the implementation-detail frontier starts

No argument there. For particular questions, we have a liaison to an oracle 🙂 For some fraction of such questions in general, it has become semi-common knowledge among the kind of people that frequent this channel. For all such questions in general, there are too many to imagine and write answers for.

having an official tooling mitigates the problem, but we're still stuck with weird special forms like cljs's js* which are totally opaque

@leonoel Do you actually have a question, or are you wanting to complain about a previous experience?

It seems the latter. Especially given you didn’t even originate the discussion.

I don't have a specific question, but I'm interested in the big picture

Others can correct me if I veer from the truth here, but I think part of the big picture is that there is not, and likely never will be, a "formal specification" document for Clojure, the way there is for Common Lisp or Scheme.

This seems the type of thing that you could contribute to.

If you have had conversations or insights that might be generally useful, you could write them up.

If there are specific questions that you feel need answering, you could ask them.

And that irks some people, but Clojure is far from the only language in that situation. Such documents can be useful, but can be monumentally time consuming to write, maintain, and argue over.

I've thought about it but so far I've seen zero clue that this work would even be considerated

Alex is generally very helpful when you have a specific question.

I know that

So what’s stopping you?

is there interest in clojure team to have a specification for clojure ?

I mean, there’s a difference between an Official Spec™ and, “Here’s the available information.”

It’s easy to provide the latter.

“easy” — I mean “easier than convincing a bunch of people that something they don’t seem to want to do is worth their time”

of course, it’s not Just Easy

I get your point

there is disinterest in having a specification

I do not know others thinking on this, but one expectation that might be in some people's minds is that a specification is an invitation to get beat over the head with it in bug reports, after spending the enormous time required to write it.

it's not that (although, yes it would take a lot of time and effort to both write and vet)

it's that specifications constrain you. Rich believes there is more utility in being able to extend the language in useful ways over time than spending a lot of time creating boundaries. There are many places in Clojure where there is ambiguity. One type of person sees those as liabilities, another perceives them as opportunities. Rich is firmly in the latter camp.

Rich places a lot of value on being able to create sustainable software that can be updated over time as requirements change. You see that ideal in many aspects of Clojure's design, and you see it in the implementation itself. Creating a specification both takes time away from making Clojure better, while simultaneously erecting more barriers to extension in the future.

These are my own perceptions of Rich's beliefs, so I am not transmitting them as well as he would. Those errors are mine.

Why pour concrete when it is expensive, and more importantly, you did not want concrete there?

The reason I originally grabbed http://insideclojure.org was the thought that some day, maybe, I would write a book about the implementation of Clojure with that name.

doing so would be a multi year effort and I haven't started yet, so it may be a while :)

As someone who was a (paying) member of J16 for eight years, working on the ANSI C++ Standard, and peripherally involved with both the ISO C standardization process and early discussions about whether Java should have an ANSI or ISO standard or go through the ECMA process, I can say with my hand on my heart that I'm rather glad Clojure isn't going through that process.

Standards (and "Specifications") can and do change over time but it's a Big Deal(™) and it's nearly always a very slow and laborious process. And the reality is that most compilers for languages that have a standard are still incompatible in certain ways and nearly all have non-standard extensions requested by users -- that often end up being incompatible with whatever version of those features get standardized at some future date.

(so, yeah, I'm firmly in the Rich camp on this one)

@leonoel https://clojure.github.io/tools.analyzer.jvm/spec/quickref.html#case

I can expand a bit the docs there if needed

tools.analyzer* are such awesome libs.