Perhaps. I was thinking of it more in terms of speccing the grammar vs analysing the result

for a tx, [{:my-map myval}] the spec is really not anything about :my-map, but a vector of things, some of which may be maps, the keys of which are arguments to some transformation

so the key is “opaque” in that sense, it’s not specced as itself; map values are independent (gramatically) from the keys

think about what this would conform to: it would produce some kind of normalized ast with {:attribute-key :my-attr :attribute-scalar-value myval} for example

it’s hard to spec “both” at once, i.e. both the generic grammar and also some specific constraints on terms in it (constraints which would be enforced by an analyzer stage in a typical compiler)

I see. So to apply your compiler analogy to an “application”, you’re referring to the fundamental difference between, say, the description of some mutation (as data), and the new database that results (assuming db-as-a-value semantics). The keys in both could also be said to be grammatically separate (?)

yeah

your key inside the transaction mini-language means something different than your key in a map with your data in it

in the first, it’s a parameter to some invisible ast’s map key, in the later it’s the data itself

maybe map-as-syntax vs map-as-data

you can’t s/keys the keys inside a map-as-syntax, only s/map-of them

That’s where my mapping of these concepts to spec was failing. s/keys seems to imply that a key must mean the same thing everywhere it’s used, but there’s an assumption that you’ll be checking against map-as-data. It is inappropriate for map-as-snytax. s/map-of was the 💡 for me, the data there is purely syntax.

For some reason I seem to have this desire to write “the base specs” of a system, but specs really don’t make sense without a context…

yeah, for me that hurts most when the context is the type of record it’s in

I keep running into cases where a key has a wider domain, but can be narrowed/refined contextually by the type of its record.

this is a common feature of type systems inspired by class based inheritence or xsds

Interesting, I haven’t run into that yet. How have you been handling it? Seems you would need some ability to compose spec registries into hierarchies.

Or perhaps express that inheritance in the key itself, eg :slack.user/email

I handled it with this horrible macro: https://gist.github.com/favila/ab03ba63e6854a449d64d509aae74618

I think with spec2 schema I may not need it, I may be able to refine the spec inline

but I’m not sure, I haven’t tried spec2 at all