Fork me on GitHub
#cljs-dev
<
2021-11-05
>
lilactown14:11:14

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

dnolen15:11:18

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

dnolen19:11:11

@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

dnolen19:11:35

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

dnolen19:11:14

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

dnolen19:11:39

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

dnolen19:11:58

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.

dnolen19:11:20

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

dnolen19:11:32

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

borkdude19:11:40

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

borkdude19:11:16

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

dnolen19:11:53

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

dnolen19:11:04

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

dnolen19:11:58

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

dnolen19:11:02

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

borkdude19:11:34

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

dnolen19:11:30

@alexmiller and Clojure controls the reading of source

dnolen19:11:36

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

dnolen19:11:29

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

dnolen19:11:34

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

dnolen19:11:11

basically was trying to understand what the new callout really meant

dnolen19:11:32

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

borkdude19:11:36

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

dnolen19:11:56

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

dnolen19:11:59

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)

dnolen19:11:40

right I understand how this relates to calling read yourself

dnolen19:11:50

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

borkdude19:11:50

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

dnolen19:11:22

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

dnolen19:11:28

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

dnolen19:11:42

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

borkdude19:11:06

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

dnolen20:11:48

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

dnolen20:11:03

Just trying to understand what you are trying to imply

borkdude20:11:37

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

borkdude20:11:40

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

dnolen20:11:24

because JS had no standard library, no standard IO

dnolen20:11:47

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

dnolen20:11:33

also somebody has to implement ES6 import loading

dnolen20:11:01

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

dnolen20:11:13

but to your point

dnolen20:11:33

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

dnolen20:11:51

but not all of them

dnolen20:11:06

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

borkdude20:11:35

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)) ?

dnolen20:11:10

Yes because ClojureScript has a very different problem then Clojure

dnolen20:11:21

Java is a platform

borkdude20:11:22

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

dnolen20:11:36

JavaScript is just glue

borkdude20:11:45

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.

borkdude20:11:59

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])

borkdude20:11:30

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

dnolen20:11:08

I think both the error changed