This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-07
Channels
- # admin-announcements (4)
- # aws (2)
- # beginners (25)
- # boot (116)
- # braid-chat (4)
- # cider (6)
- # cljsjs (4)
- # cljsrn (17)
- # clojure (196)
- # clojure-austin (23)
- # clojure-belgium (5)
- # clojure-dev (78)
- # clojure-dusseldorf (6)
- # clojure-italy (2)
- # clojure-japan (6)
- # clojure-poland (1)
- # clojure-russia (132)
- # clojure-sdn (1)
- # clojure-uk (26)
- # clojurescript (87)
- # code-reviews (3)
- # core-async (26)
- # cursive (8)
- # datomic (40)
- # devcards (8)
- # emacs (4)
- # funcool (32)
- # hoplon (30)
- # jaunt (34)
- # jobs (1)
- # lein-figwheel (1)
- # leiningen (5)
- # om (14)
- # onyx (8)
- # overtone (31)
- # parinfer (14)
- # proton (8)
- # protorepl (1)
- # re-frame (30)
- # reagent (10)
- # spacemacs (2)
- # untangled (107)
- # yada (3)
Rich and I have been working on some new syntax for namespaced maps http://dev.clojure.org/jira/browse/CLJ-1910
@alexmiller: should :ship
be :person/ship
in the first snippet? otherwise I'm not understanding how that would work
yeah, already fixed
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}
that's an interesting idea
but yeah wouldn't work for symbols
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
I don't think Rich is firm on the _ yet, that could still get pulled
the ::kw thing would raise all sorts of contextual questions with nested maps too
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...
maybe, but bleh
maybe there are other ways to notate "leave it alone" but there's not much to work with for symbols
me too, the question is whether that's important enough to special case
this is the tippy tip of many other ideas so it's hard to tell
ditto but thinking of some future uses
and stuff like auto-resolving :keys/:syms in desctructuring already only works on heterogeneously namespaced kws/symbols
changes may be coming there too
the idea being that you could avoid repeating the ns when destructuring namespaced keys
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
symbol support is necessary
agreed - I'm making that case to Rich, we'll see
@alexmiller: what's the motivation behind this btw? reducing the amount of noise in e.g. datomic schemas/queries?
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)
people rarely ask for things they've never heard of :)
this actually ties into ideas around the macro grammars too
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
for sure - syntax is cognitively expensive and has to pay for that
in expressiveness or utility somehow
I'm not sure _ meets that bar here
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.
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 assoc
d 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.
@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)
@seancorfield: this is purely a read feature - the namespace is not retained with the map at all
@bronsa - you said "The proposed syntax makes :
auto-qualify in some contexts" but I don't get that
oh, you mean inside the map
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
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 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
well I'm still arguing the _ but I'd consider the rest set unless someone comes up with a better idea