"Nix Pointer"

[roberth]

Is your feature request related to a problem?

We tend to use attribute paths to refer to attributes, like packages.x86_64-linux.default, and we do so in the expression language, but also outside of it with an ad hoc syntax. Problems:

• The ad hoc attribute path syntax has not been formalized.
  • It's unclear how a different tool should parse it.
  • It's unclear how a different tool should generate it.
  • It may be unclear whether it embeds verbatim into other syntaxes (e.g. can it contain a %?). I assume all symbols are valid and escaping attribute paths in URLs etc should always be done.
• We don't have C++ functions for parsing or generating this format.
• It's undocumented and it doesn't have a name.
• It can't access list items

Proposed solution

Formalize "Nix Pointer", analogous to JSON pointer, but with a syntax that aligns with our conventions.

• no / but . for selection (breaking from JSON pointer and XPointer)
• Nix expression language-compatible quoting for attribute names
• Attribute-only Nix pointers are valid select-expressions when prefixed with the string v.

Alternative solutions

Additional context

We may want to bring a syntax for list selection into the Nix expression language so that all Nix pointers are valid expressions when prefixed with v. or some similar rule.

• [RFC 0181] List index syntax rfcs#181

Checklist

• checked latest Nix manual (source)
• checked open feature issues and pull requests for possible duplicates

---

Add 👍 to issues you find important.

[Lassulus]

the main reason we wrote https://github.com/clan-lol/nix-select was that the nix language is quite limited (but it doesn't have to be). We would be very happy if the builtin selection language inside nix could take some (or all?) of the features from nix-select :)

[roberth]

That's more like a query language, like XPath or jq. Those return multiple results, whereas a "pointer" language only returns one value. I've opened #13146 for this.

The pointer language could be a subset of the query language, and be suitable for things like single installable fragments on the command line.

[Lassulus]

I'm not sure the single value is the main difference, as selecting an attrset would return that attrset and the query language would also return one, although it is constructed based on the query. so the pointer language would only return subtrees of the root attrset, instead of the query language which can construct new ones by merging subsets.

I guess the pointer specification is what can be used in attrset definitons though? but I'm not sure the list index syntax would make sense there. since assigning a list value != 0 the preceding values in the list would be unspecified? example:

{
  x.1 = "hello world";
} 

not sure what x.0 should return here?

so maybe this is another subset of the language?

[roberth]

The pointer language is, in my mind, more of a CLI thing, a better --attr or a properly specified installable after-# syntax.

---

{
  x.1 = "hello world";
}

so maybe this is another subset of the language?

It wouldn't be part of the syntax for literals, but potentially (NixOS/rfcs#181) we could have:

hello = x.1.world;

That's if we can take care of the let x = "x"; in [ x.1 ] "ambiguity" gracefully.

[roberth]

We may want to bring a syntax for list selection into the Nix expression language so that all Nix pointers are valid expressions when prefixed with v. or some similar rule.

I don't believe this should be a requirement anymore. Harmonizing with the Nix language is good, but if it is a requirement for the "pointer" language, it would require the quoting of Nix language keywords.
Furthermore, expressions and pointers are fundamentally different. One evaluates to a value, another can not be evaluated without first applying it. It serves as a lens. Closest simple thing in the language would be a function, but that does not express lens-style reversibility.

Pointers are for use outside the language, where keywords shouldn't matter. Outside it's more important to have simple and predictable syntax. That makes integration with scripts and applications easier, which is more important than a guarantee of "copy-pastability" which happens tends to happen with human involvement or at least as part of an improvement cycle instead of completely unattended operations.

[roberth]

I'm not sure the single value is the main difference

I guess the pointer specification is what can be used in attrset definitons though?

I think it's simplicity and reversibility that make this different from a more versatile query language.

{
  x.1 = "hello world";
} 

not sure what x.0 should return here?

An error.
I think the only resolvable pointers here should be, categorized by return value / pointee:

• { x."1" = "hello world"; }
  • The empty string
  • . special root or "identity pointer" syntax (an empty string may be problematic in some usages)
• { "1" = "hello world"; }
  • x
  • "x"
• "hello world"
  • x."1"
  • "x"."1"

So some of the rules would be:

• Digit at start is either reserved or serves as list index
• Attribute names that don't need quoting can be quoted
• No escaping except for the typical \\, \", and perhaps \n and \r, again for easier embedding into other things.

so maybe this is another subset of the language?

Kind of. Not really a subset squarely as a language, but mentally it can be, somewhat, see my previous comment.