Fork me on GitHub
#clojure-dev
<
2019-12-23
>
Jimmy Miller15:12:50

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

Alex Miller (Clojure team)15:12:12

it's an implementation detail of case

Alex Miller (Clojure team)15:12:30

you shouldn't use it directly

Alex Miller (Clojure team)15:12:59

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

Jimmy Miller16:12:30

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.

Alex Miller (Clojure team)16:12:37

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

👍 4
Alex Miller (Clojure team)16:12:55

case* is the transition point between those

leonoel16:12:57

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

leonoel16:12:02

that's not very helpful

Alex Miller (Clojure team)17:12:49

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

leonoel19:12:31

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

andy.fingerhut19:12:22

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.

leonoel19:12:19

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

andy.fingerhut19:12:00

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

andy.fingerhut19:12:37

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.

Alex Miller (Clojure team)19:12:54

In what way are you affected?

leonoel19:12:55

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

leonoel19:12:33

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

leonoel19:12:52

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

andy.fingerhut19:12:08

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

Alex Miller (Clojure team)19:12:21

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

Alex Miller (Clojure team)19:12:05

seems unimportant relative to many other things to me

leonoel19:12:30

I don't deny that

andy.fingerhut19:12:35

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

leonoel19:12:28

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

andy.fingerhut19:12:36

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.

leonoel19:12:27

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

potetm19:12:41

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

potetm19:12:11

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

leonoel19:12:03

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

andy.fingerhut19:12:01

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.

potetm19:12:34

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

potetm19:12:15

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

potetm19:12:32

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

andy.fingerhut19:12:33

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.

leonoel19:12:04

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

potetm19:12:41

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

leonoel19:12:51

I know that

potetm19:12:17

So what’s stopping you?

leonoel19:12:42

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

potetm19:12:30

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

potetm19:12:45

It’s easy to provide the latter.

4
potetm19:12:43

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

potetm19:12:05

of course, it’s not Just Easy

leonoel19:12:19

I get your point

Alex Miller (Clojure team)19:12:50

there is disinterest in having a specification

andy.fingerhut19:12:24

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.

Alex Miller (Clojure team)19:12:49

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

Alex Miller (Clojure team)19:12:24

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.

Alex Miller (Clojure team)20:12:46

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.

Alex Miller (Clojure team)20:12:49

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

andy.fingerhut20:12:56

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

Alex Miller (Clojure team)20:12:10

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.

👍 8
4
jumar11:12:40

That would be awesome. I found Clojure in Small Pieces a long time ago but lot of it is just copy pasted code without real explanations.

Alex Miller (Clojure team)20:12:06

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

seancorfield20:12:10

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.

seancorfield20:12:14

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.

seancorfield20:12:46

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

jaihindhreddy07:12:56

💯! I never quite understood the point of the standards. By publishing a standard, and by enabling people to make their own non-standard extensions, the language authors instantly forego a lot of freedom in evolving the language without trampling on these extensions. Also, LISPs already give users a lot more expressive power to mould the language to their needs making standards even less useful IMHO.

leonoel10:12:43

Is it reasonable to assume the non-breaking policy applies to this API ?

leonoel12:12:09

Then that's a highly valuable resource because that means we have a de facto specification of the clojure language

bronsa23:12:19

I can expand a bit the docs there if needed

mikerod23:12:09

tools.analyzer* are such awesome libs.

leonoel10:12:43

Is it reasonable to assume the non-breaking policy applies to this API ?

leonoel12:12:09

Then that's a highly valuable resource because that means we have a de facto specification of the clojure language