Fork me on GitHub

I noticed that I don't get warned when a private var is referenced from another ns


@lilactown we definitely have that check (and hopefully a test), but maybe something about your arrangement prevents that?


@alexmiller re: I noticed today due to some other conversations that the conditional reading docs have loosened the rules a little bit - I'm assuming this was triggered by ClojureDart and other similar efforts - I don't remember hearing any announcement about this and perhaps there wasn't a desire to call it out


based on the docs - it seems we have the cases as before, but of course new implementation efforts might require new things


however that doesn't really address broader use patterns and whether that is also under consideration w/ this guidance chance, i.e. platform specific stuff not really language stuff


i.e. :cljs/browser :cljs/node - I wonder if you could shed some light on the thinking behind the change

Alex Miller (Clojure team)19:11:17

not sure what you're talking about, nothing has changed that I recall


Implementors of non-official Clojure platforms should use a qualified keyword for their platform feature to avoid name collisions. Unqualified platform features are reserved for official platforms.


I don't remember this language previously - but I haven't looked at this stuff in like 6 years (back when it seemed clear Rich just wanted :clj :cljs and :cljr


it could have been added a long time ago - I don't remember that being there in the beginning


That addition was triggered by a conversation between me and Alex, because babashka uses :bb. #nbb now uses :org.babashka/nbb .


It was afaik always possible to add :foobar branches without Clojure not working correctly for its own :clj branches, i.e. open to addition.

Alex Miller (Clojure team)19:11:35

oh yeah, that's been there for a while. it was always the intent and I think is probably in the original release notes / design stuff but was not clear enough in the docs


huh, ok don't remember that at all - @alexmiller still it's my understanding irregardless of how tools.reader works that conditional reading isn't really for generic feature stuff

Alex Miller (Clojure team)19:11:56

features have always been an open space though - the reader lets you plug stuff in there (it just also ensures the platform feature is set)

Alex Miller (Clojure team)19:11:25

reading can occur in multiple places

Alex Miller (Clojure team)19:11:03

when a platform (clojure or clojurescript) is reading .clj or .cljs or .cljc source files, or is reading code at the repl, the only feature that is included is the platform feature


ok, I distinctly remember these early conversation about Rich when this happened it wasn't intended to be an open set a la Common Lisp

Alex Miller (Clojure team)19:11:32

but when using the reader as a component, you can provide arbitrary features


@alexmiller right but Clojure itself doesn't let you change this right


that's what I mean

Alex Miller (Clojure team)19:11:13

it lets you change it when you call read

Alex Miller (Clojure team)19:11:22

but not when source code itself is loaded


That is not the problem here: a Clojure implementation should just read what it is interested in and not fail because others add more branches

Alex Miller (Clojure team)19:11:59

it should be tolerant of features it doesn't understand


@alexmiller and Clojure controls the reading of source


you cannot configure this is all I mean

Alex Miller (Clojure team)19:11:45

you can't configure Clojure's reading of source

Alex Miller (Clojure team)19:11:11

(until some possibly infinite time in the future :) )

Alex Miller (Clojure team)19:11:40

early in the impl that was open and configurable


but as a design point - I think the guidance is still - the conditional is really about a Clojure implementation


not general feature detection

Alex Miller (Clojure team)19:11:48

from a language pov, yes. from a reader pov, it's more general.

Alex Miller (Clojure team)19:11:34

so a program could choose to read with conditional features, either for the purpose of reading data, or reading code to eval, or reading for analysis purposes (with :read-cond :preserve ). but all of that is on the user and their invocation of read


basically was trying to understand what the new callout really meant


but I think still then :cljs/browser etc. is probably not a good idea


as far as I understand the callout was only added to prevent clashes with official Clojure implementations


but I can relate to the community interest because people want to use the same code in different contexts


and JavaScript defines nothing

Alex Miller (Clojure team)19:11:00

the guidance there is really - if you choose to do stuff in user space, you should use qualified features (as unqualified are preserved for the language)


right I understand how this relates to calling read yourself


which if you're implementing a Clojure - then you're the user etc.


:cljs/* can be treated as reserved for CLJS so it can still work, I don't think it's a bad idea necessarily


I'm not saying it is or isn't a bad idea - but not interested in going off the rails is all 🙂


an alternative of course is that ClojureScript could define a closed set - but JavaScript isn't a platform


it's glue - so it's not a small set of things


if CLJS would one day emit ES6 (theoretically, for the sake of this argument), would it still matter what the platform was?


I don't follow? We do emit ES6, since EcmaScript 2001 is a subset of ES6


Just trying to understand what you are trying to imply


I mean ES6 imports. There is now a target node, target browser etc. But if you emit ES6 modules, do these differences still matter?


E.g. shadow has an ESM target: you can use this for node, deno, browser, without specifying this, it seems it matters less there what you're compiling for


because JS had no standard library, no standard IO


Direct JS engine load, RN, Browser, Node are not the same things


also somebody has to implement ES6 import loading


I would surprised if this implemented directly in V8, JavaScriptCore - maybe in SpiderMonkey


but to your point


for the case of Browser vs. Node.js it would paper over one kind of problem


but not all of them


i.e. crypto etc. none of these things are going to get reconciled


ah you mean: if you wanted to write one single file to target multiple JS platforms, you could do #?(:cljs/node (crypto/foo) :cljs/browser (crypto/bar)) ?


Yes because ClojureScript has a very different problem then Clojure


Java is a platform


this can probably be solved dynamically as well, whereas namespace imports cannot


JavaScript is just glue


I have never had that problem of wanting to target Node + Browser in one file - perhaps others have asked for this? I only encountered the CJS / ESM namespace difference as a problem, which lead to this discussion, since @chris358 had problems with codox.


Since #nbb uses ESM and he also wants to compile for Node CJS, this is why he uses #?(:org.babashka/nbb [foo$default] :cljs [foo])


but it's not clear what tripped codox: the reader conditional or the string in the namespace - anyway.


I think both the error changed