Fork me on GitHub
#clojure-dev
<
2016-04-07
>
alexmiller16:04:40

Rich and I have been working on some new syntax for namespaced maps http://dev.clojure.org/jira/browse/CLJ-1910

arrdem16:04:32

Interesting.

bronsa17:04:04

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

alexmiller17:04:14

yeah, already fixed

bronsa17:04:39

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}

bronsa17:04:08

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

bronsa17:04:30

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

alexmiller18:04:07

that's an interesting idea

alexmiller18:04:27

but yeah wouldn't work for symbols

arrdem18:04:36

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

alexmiller18: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

alexmiller18:04:14

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

alexmiller18:04:42

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

alexmiller18:04:41

and the impl would be really gross

arrdem18:04:56

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...

alexmiller18:04:44

maybe, but bleh

alexmiller18:04:51

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

bronsa18:04:35

I'd rather disallow it than making _ special

alexmiller18:04:20

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

alexmiller18:04:42

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

bronsa18:04:27

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

alexmiller18:04:55

ditto but thinking of some future uses

bronsa18:04:57

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

bronsa18:04:25

so that's a precedent

alexmiller18:04:28

changes may be coming there too

alexmiller18:04:41

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

alexmiller18:04:21

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

bronsa18:04:32

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

bronsa18:04:52

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

alexmiller18:04:54

symbol support is necessary

bronsa18:04:16

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

alexmiller18:04:28

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

bronsa18:04:33

cool, thanks

bronsa18:04:02

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

alexmiller18:04:45

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

bronsa18:04:54

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)

alexmiller18:04:16

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

alexmiller18:04:48

this actually ties into ideas around the macro grammars too

bronsa18:04:15

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

alexmiller18:04:43

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

bronsa18:04:06

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

alexmiller18:04:35

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

alexmiller18:04:42

in expressiveness or utility somehow

alexmiller18:04:15

I'm not sure _ meets that bar here

alexmiller18:04:50

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

seancorfield19:04:18

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

bronsa19:04:20

not arguing against that, just on the proposed syntax

seancorfield19:04:23

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.

seancorfield19:04:23

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?

seancorfield19:04:46

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

seancorfield19:04:18

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

bronsa19:04:47

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

bronsa19:04:25

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

seancorfield19:04:27

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

bronsa19:04:28

ditto for :_

bronsa19:04:51

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

seancorfield19:04:01

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

seancorfield19:04:19

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

bronsa19:04:17

sure, its meaning is resolve in the current context

bronsa19:04:34

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

alexmiller19:04:14

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

alexmiller19:04:43

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

alexmiller19:04:11

oh, you mean inside the map

alexmiller19:04:49

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

hiredman19:04:26

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

bronsa19:04:29

@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

alexmiller19:04:15

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

bronsa19:04:30

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)

bronsa19:04:02

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

alexmiller19:04:46

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

bronsa19:04:56

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