This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-05
Channels
- # announcements (23)
- # babashka (23)
- # beginners (48)
- # calva (41)
- # clj-kondo (41)
- # cljs-dev (75)
- # cljsrn (5)
- # clojure (85)
- # clojure-europe (46)
- # clojure-nl (2)
- # clojure-spec (70)
- # clojure-uk (4)
- # clojurescript (52)
- # core-async (2)
- # cursive (16)
- # datahike (2)
- # datomic (4)
- # emacs (15)
- # figwheel-main (2)
- # fulcro (5)
- # gratitude (5)
- # helix (14)
- # introduce-yourself (2)
- # jackdaw (13)
- # keyboards (2)
- # lsp (8)
- # luminus (5)
- # malli (3)
- # meander (12)
- # nextjournal (52)
- # off-topic (19)
- # other-languages (1)
- # overtone (3)
- # pathom (4)
- # podcasts-discuss (1)
- # re-frame (6)
- # reitit (1)
- # releases (2)
- # ring (3)
- # sci (22)
- # shadow-cljs (3)
- # specter (1)
- # testing (3)
- # tools-deps (100)
- # uncomplicate (2)
@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
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.
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
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)
reading can occur in multiple places
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
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
http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/read - see :features
option
it lets you change it when you call read
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
that is also true
it should be tolerant of features it doesn't understand
@alexmiller and Clojure controls the reading of source
you can't configure Clojure's reading of source
that part is closed
(until some possibly infinite time in the future :) )
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
from a language pov, yes. from a reader pov, it's more general.
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
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
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)
: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
if CLJS would one day emit ES6 (theoretically, for the sake of this argument), would it still matter what the platform was?
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
I would surprised if this implemented directly in V8, JavaScriptCore - maybe in SpiderMonkey
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))
?
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])