just realized the repo was private- is public now
I do wonder if it’s reader bug? haven’t had a chance to look closely
Seems true for normal :as aliases as well?
other reader tags are handling a space just fine
Yeah, clj handles the space just fine for map prefixes
Well, when you read ::b, you think :this.namespace/b, moreso than :alias.for.b/thing-a-number-of-white-spaces-from-here
So there's a slight argument for map namespace prefixes being slightly stricter than other reader tags, wrt whitespace
@john so you’re saying normal :as fails as well and the problem is #::b{...} vs #::b {…} - will update the description if this is what you mean
That's what I'm thinking, and seeing in the repl I think
I think that's what @lilactown was getting at
about the space. I think the as-alias is working without the space
@bronsa what do you think ^?
I'm a bit surprised the whitespace would be read into the symbol, but let me have a look
I'm pretty sure this behavior has always been there
Don't think it's a regression
Because I think I've wondered about the above rationale for the stricter syntax in the past
from working on perc in the past
I'm struggling to see how #::x{:foo 1} #::x {:foo 1} would be any different tbh. I don't think the whitespace matters, it may be a red herring
Is the reader tag for namespaced keys being checked prior to the one for catching map namepsace prefixes? If not, then the white space would be forcing a namespaced key read, right?
hrm actually maybe not the reader - since app.b is resolved in the reported error …
yeah that's what I'm thinking too
but they really should produce the same object, so something the reader produces is different -- perharps the meta?
the whitespace is immaterial during reading
how do you know you've reached the end of a locally namespaced some-key?
@john which makes it stranger that dropping the space works …
Maybe the clj one isn't trying to resolve, at the stage it's reading from the reader tag itself
is there a quick way I can repro in a cljs repl? sorry it's been a while since I've played with cljs
(ns user
(:require
[clojure.edn :as edn]))
(def data #::edn {:x 1 :y 2 :z 3})right
should do it. I just use calva to launch my cljs envs quickly these days
with shadow
@bronsa from ClojureScript repo - clj -M -m cljs.main -re node -r
I see the reported error after dropping the forms into the REPL
weird, I don't O.o
user=> (def data #::edn {:x 1 :y 2 :z 3})
#'user/data
user=> data
#:clojure.edn{:x 1, :y 2, :z 3}ClojureScript 1.11.54
let me try to upgrade
same on 1.11.132
Hmm, I wasn't seeing it in the node repl
if it's env specific it may point to the problem not being the reader
ah, I'm on an older version of cljs too
maybe it is a regression
@john out of curiosity, in wherever env you can repro, does (def data '#::edn {:x 1 :y 2 :z 3}) make a difference?
FWIW, can't reproduce the issue with :as and a space with the latest vanilla CLJS with both Node and browser-based REPL.
Can reproduce with shadow-cljs 2.28.3 (uses same CLJS version under the hood, 132). Adding a quote doesn't change anything.
@thheller Pinging you since you might want to know.
ok I tested removing the whitespace in cljs-alias-ns-map-bug and that doesn't seem to make a difference at least, so we can exclude that.
yeah I just tested this in that repo
$ clj -M -m cljs.main -re node -r
ClojureScript 1.11.132
cljs.user=> (ns a.b (:require [a.c :as-alias c]))
nil
a.b=> ::c/x
:a.c/x
a.b=> #::c{:x 1}
Syntax error reading source at (REPL:1).
No namespace: a.c found
:x
1
Syntax error reading source at (REPL:1).
<NO_SOURCE_FILE> [line 1, col 2] Unmatched delimiter }.
a.b=>can't repro the space issue with :as
clj -M -m cljs.main -re node -r
ClojureScript 1.11.132
cljs.user=> (ns a.b (:require [clojure.edn :as edn]))
nil
a.b=> ::edn/x
:clojure.edn/x
a.b=> #::edn{:x 1}
#:clojure.edn{:x 1}
a.b=> #::edn {:x 1}
#:clojure.edn{:x 1}(ns user.core
(:require [cljs.math :as m]))
::m/hi ;=> :cljs.math/hi
#::cljs.math {:hi :there} ;=> #:cljs.math{:hi :there}
#::cljs.math{:hi :there} ;=> #:cljs.math{:hi :there}
#::m {:hi :there} ;=> {:hi :there}
; No namespace: m found
#::m{:hi :there} ;=> :there
; No namespace: m foundSo, correction, what I'm seeing is happening regardless of a space, just aliasing in general, hmm.. But I'm seeing different behavior in the vanilla node repl I think
k thanks all for the extra info
(def data '#::edn {:x 1 :y 2 :z 3}) ;=> {:x 1, :y 2, :z 3}
; No namespace: edn found
; [line 1, col 2] Unmatched delimiter )doesn't even compile, but that map is returned and printed
How exactly did you check that? What was the command that started your REPL?
So I just started shadow via calva's "jack-in" command. And then I just evaluated the form in the editor
Did you see my comment above? Where I could reproduce it only in shadow-cljs but not in vanilla CLJS.
So if anything, the space-related issue seems to be purely on the shadow-cljs side.
I did see that. That could well be it. Might need to bring this to shadow-cljs
Right, that's why I pinged Thomas in that thread.
Did you try the latest cljs on a vanilla node repl and try it?
Yes, exactly as my comment mentions.
> can't reproduce the issue with :as and a space with the latest vanilla CLJS with both Node and browser-based REPL
Ah okay
ah, looks like Thomas has seen it in the shadow channel and is aware
so data is still not defined
So correction, this behavior doesn't appear to be present on 1.10.520
I believe I've found a bug in :as-alias when combined with namespaced maps.
$ cat src/app/a.cljs
(ns app.a
(:require
[app.b :as-alias b]))
;; works
#_(def data {::b/x 1 ::b/y 2 ::b/z 3})
;; broken
(def data #::b {:x 1 :y 2 :z 3})
$ clj -M --main cljs.main --compile app.a
Unexpected error compiling at (REPL:1).
No namespace: app.b found
Full report at:
/var/folders/28/7xm2frlx1cb_gt4nrscjpttw0000gn/T/clojure-10509037535418893124.edn
full repro here: https://github.com/lilactown/cljs-alias-ns-map-bug@lilactown thanks!!!