Fork me on GitHub
Alex Miller (Clojure team)16:04:40

Rich and I have been working on some new syntax for namespaced maps




@alexmiller: should :ship be :person/ship in the first snippet? otherwise I'm not understanding how that would work


I really don't like :_. I think I'd rather have something that worked like this #:foo{::kw 1, :n/kw 2, :bare 3} -> {:foo/kw 1 :n/kw 2 :bare 3}


i.e. just having the prefix just bind current-ns in the context of reading map keys


but I can see how that wouldn't work for symbols..

Alex Miller (Clojure team)18:04:07

that's an interesting idea

Alex Miller (Clojure team)18:04:27

but yeah wouldn't work for symbols


IMO that's more obvious behavior, but definitely harder to implement.

Alex Miller (Clojure team)18:04:14

I'm pretty meh on the special _ too - my personal vote would be that you just can't get bare kw/sym in a namespaced map, so use a regular map in that case

Alex Miller (Clojure team)18:04:14

I don't think Rich is firm on the _ yet, that could still get pulled

Alex Miller (Clojure team)18:04:42

the ::kw thing would raise all sorts of contextual questions with nested maps too

Alex Miller (Clojure team)18:04:41

and the impl would be really gross


I don't think it'd be that bad if you write out reading k/v pairs and simply apply the binding when reading a key rather than punting to readDelimited. Maybe a perf complaint against that...

Alex Miller (Clojure team)18:04:51

maybe there are other ways to notate "leave it alone" but there's not much to work with for symbols


I'd rather disallow it than making _ special

Alex Miller (Clojure team)18:04:20

me too, the question is whether that's important enough to special case

Alex Miller (Clojure team)18:04:42

this is the tippy tip of many other ideas so it's hard to tell


I've hardly ever mixed non-namespaced and namespaced kws

Alex Miller (Clojure team)18:04:55

ditto but thinking of some future uses


and stuff like auto-resolving :keys/:syms in desctructuring already only works on heterogeneously namespaced kws/symbols


so that's a precedent

Alex Miller (Clojure team)18:04:28

changes may be coming there too

Alex Miller (Clojure team)18:04:41

the idea being that you could avoid repeating the ns when destructuring namespaced keys

Alex Miller (Clojure team)18:04:21

we haven't discussed what that would actually look like yet but probably some variant of :keys / :syms


TBH I'd even rather supporting only kws, and going with the syntax I proposed, which has the benefit of - being more consistent with currently auto-resolving kws - not requiring "special" tokens


people are already confused by [.. & _], thinking that _ means something special

Alex Miller (Clojure team)18:04:54

symbol support is necessary


if _ does become something special only somewhere.. that's not going to help

Alex Miller (Clojure team)18:04:28

agreed - I'm making that case to Rich, we'll see


cool, thanks


@alexmiller: what's the motivation behind this btw? reducing the amount of noise in e.g. datomic schemas/queries?

Alex Miller (Clojure team)18:04:45

like I said, this is just the tip of the iceberg, there are a bunch of things behind it


it's an interesting proposal but I've never seen anybody complain/ask for it (but probably because my sample size is way smaller than yours)

Alex Miller (Clojure team)18:04:16

people rarely ask for things they've never heard of :)

Alex Miller (Clojure team)18:04:48

this actually ties into ideas around the macro grammars too


ah, nice! can't wait for the rest then

Alex Miller (Clojure team)18:04:43

in terms of defining grammars for structural data, in terms of data


I'm just a bit concerned with adding additional syntax/special cases, but I'll wait to see how it ties with what you're hinting at

Alex Miller (Clojure team)18:04:35

for sure - syntax is cognitively expensive and has to pay for that

Alex Miller (Clojure team)18:04:42

in expressiveness or utility somehow

Alex Miller (Clojure team)18:04:15

I'm not sure _ meets that bar here

Alex Miller (Clojure team)18:04:50

but of course it's not my decision in the end :)


I think introducing syntax for namespaced-maps will lead to them being used more widely which I think would be a good thing.


not arguing against that, just on the proposed syntax


We’ve not yet adopted namespaced keywords widely at World Singles but we certainly have cases where they would help us from a self-documenting code p.o.v. and I like the idea of modifying our SQL layer to use :table/column key names instead of bare :column names so it’s much easier to see where data comes from.


I think there’s a reasonable argument for say that bare keywords/symbols should not be supported in a namespaced-map literal — but presumably they could just be assocd in?


(assoc #:user{:first "Sean" :last "Corfield"} :age 53)?


or does such a map retain its namespace and apply it to any bare keys added in?


an additional thing I don't like is that everywhere currently :: means auto-qualify, while : means not to. The proposed syntax makes : auto-qualify in some contexts


and if one of the selling points of lisps is that we avoid overloaded/context-dependent syntax, this would be a step in the opposite direction


But :: is contextual by definition (in my thinking) so that seems OK.


ditto for :_


@seancorfield: no, ::'s auto-resolver is contextual, not its meaning


Does it really have a meaning without being resolved implicitly tho’?


(I agree that :_ is a bit too cryptic / "clever" to be a good idea)


sure, its meaning is resolve in the current context


but the point is that we're making : resolve, rather than ::

Alex Miller (Clojure team)19:04:14

@seancorfield: this is purely a read feature - the namespace is not retained with the map at all

Alex Miller (Clojure team)19:04:43

@bronsa - you said "The proposed syntax makes : auto-qualify in some contexts" but I don't get that

Alex Miller (Clojure team)19:04:11

oh, you mean inside the map

Alex Miller (Clojure team)19:04:49

I have mild discomfort around that as well but I think the tradeoffs make it worth it


you can imagine some reader feature #:foo the-next-form, that just made all the resolution stuff ('::', syntax-quote) resolve to foo in the next form


@alexmiller: yes, inside the map -- seeing ::foo and :foo in isolation, I would expect the former to auto-qualify, while the latter not to. If we accept the assumption that (for example) #:foo means "make auto-resolution resolve to foo by default in this context", than there would be no incongruence with the existing syntax, while the current proposal goes against that

Alex Miller (Clojure team)19:04:15

if we weren't trying to cover symbols, I would agree with you


yeah, understandable position, I'm just hoping we can come up with a more consistent syntax simple_smile I cannot think of any right now (and I'm sure you & Rich evaluated the current proposal against alternatives)


if it turns out that this is the definitive syntax, meh, I'll live with it, not a huge deal

Alex Miller (Clojure team)19:04:46

well I'm still arguing the _ but I'd consider the rest set unless someone comes up with a better idea


maybe a post on the clojure-dev ML might spark some ideas around this, the reader-conditional discussion proved to be useful IIRC