This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (6)
- # aws (4)
- # babashka (77)
- # beginners (70)
- # calva (2)
- # cider (62)
- # clara (1)
- # clojars (5)
- # clojure (101)
- # clojure-dev (67)
- # clojure-europe (1)
- # clojure-nl (3)
- # clojure-uk (13)
- # core-async (15)
- # datomic (11)
- # defnpodcast (10)
- # duct (22)
- # emacs (6)
- # events (1)
- # fulcro (34)
- # kaocha (3)
- # off-topic (20)
- # pathom (1)
- # re-frame (8)
- # reagent (14)
- # remote-jobs (1)
- # shadow-cljs (58)
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
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.
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
to have implementation-detail special forms means the result of a macroexpansion is implementation-detail as well
it's not really helpful or harmful, it's a detail that few people ever see or are affected by
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 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.
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
so, this only affects people doing deep transformations on Clojure ASTs and there is an official lib that helps you do so
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?
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.
If you have had conversations or insights that might be generally useful, you could write them up.
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
I mean, there’s a difference between an Official Spec™ and, “Here’s the available information.”
“easy” — I mean “easier than convincing a bunch of people that something they don’t seem to want to do is worth their time”
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.
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.
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.
💯! 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.
Then that's a highly valuable resource because that means we have a de facto specification of the clojure language