Syntax to refer to context / args

[Gozala]

I think we have considered various options, but we need to make some decision so I'll list out them here

1. Refer to the UCAN as $ and get args as [".args", "$", "?args"].
   • 💚 Allows us to expose more things like .cmd and .exp in the future as paths.
   • 💔 You always need to start with .args which is verbose
2. Refer to the args as $ because that is only thing we support right now anyway
   • 💚 No need to select .args all the time.
   • 💔 Can not expose .cmd or .exp as that may collide with args of the same name.
3. Refer to the context as ? which makes it a pre-bound variable
   • 💚 Removes a need for another special character
   • 💔 Can not expose .cmd or .exp as that may collide with args of the same name.

[Gozala]

My personal preference would be to reserve ? as pre-bound variable that refers to the args. And reserve ?@ or ?self as a pre-bound variable for { args }. Because

1. No need to introduce more concepts (less is more), which also makes implementation easy.
2. Pathing into args is majority of use cases so it makes sense to optimize for it.
3. ? both fits the notion of the variable and is distinct enough from use space variables.
4. By reserving a second variable we make it possible to expose cmd, exp and other things in the future.

[Gozala]

One other thing that occured to me we could simply allow selectors anywhere we allow variables, which will eliminate most of the cases where we use $ or ? right now. And if you want to bind you'll be able to express it as follows

[
  [".mail[].to[]", ".", "?email"],
  ["match", "?email", "*.fission.codes"]
]

We would still want to reserve some path so we could put future extensions there, but otherwise it seems nicer and pretty clean IMO.

[Gozala]

You also would be able to simplify above policy as without introducing any variables

[
  ["match", ".mail[].to[]", "*.fission.codes"]
]

[expede]

1. Refer to the UCAN as $ and get args as [".args", "$", "?args"].
   • 💚 Allows us to expose more things like .cmd and .exp in the future as paths.
   • 💔 You always need to start with .args which is verbose

What I like about this one is it's the closest to jq/jQuery/JSONPath/JSONSelector, though none of those use lisp-y syntax

2. Refer to the args as $ because that is only thing we support right now anyway
   • 💚 No need to select .args all the time.
   • 💔 Can not expose .cmd or .exp as that may collide with args of the same name.

I personally like separating our $env syntactically. I find it very clear, and we can attach anything we want to it over time ($, $now, $current-node-did, etc). This is not unlike your suggestion in the thread to allow extension with ?@ and so on, but not having to reserve all possible identifiers is a strength of using a different namespace

3. Refer to the context as ? which makes it a pre-bound variable
   • 💚 Removes a need for another special character
   • 💔 Can not expose .cmd or .exp as that may collide with args of the same name.

I won't block it, but for the reasons on #2, I think this parsimony could cause more problems down the road than it solves today.

You also would be able to simplify above policy as without introducing any variables

[
  ["match", ".mail[].to[]", "*.fission.codes"]
]

Hmm yeah, it's just syntactic sugar that unpacks into the same form. It's another form to track, but I'm certainly not against it! Since it's just sugar, we could also ship the more general syntax to start (with explicit bindings, which we always need), and add this later. Thoughts?

[expede]

My order of preference for binding ucan.args is as follows:

• $.args (most favourite)
• $
• ?args
• ?
• . (least favourite)

[expede]

(We chatted live about this; my task is to run the options past a few people now that I better understand the rationale)

[expede]

From asking around, here's the basic takeaway (sorted from most to least popular):

"$" // Popular because jq
"$.args" // meh
"?args" // meh
"?" // Not an over my dead body, but unpopular
"." // Very much the *least* favourite, even once explained

Switching to slash synatx was less preferred to dot syntax (the refrain: "just do what jq does"), but it changed the order:

"/" // Reasonable because similar to URLs
"/args" // meh

---

Dot selectors were expected to work both with and without $

[">", ".foo", 0]
// Same as
[">", "$.foo", 0]
// ...because that's what jq does

[expede]

Oh, also: we don't have an issue for this but mentioning here: folks seem to like that this is a JSON embedding 👍 (instead of a giant string)

[Gozala]

I want to call out on thing that we have arrived to in the private channel. Despite ['.foo', '.', '?foo'] been unpopular it would work despite our preferences if we allow passing selectors in other places like ['>', '.size', 0] because . refers to top in jq.

I also really do not want $ because that would take up another $ string prefix along with . and ?. Here is an example illustrating the issue

["match", "$.foo", "/*"]

Is second element a string or a reference or a selector ? We could limit it to just "$" but only reduces space for ambiguity it does not remove it, which I find hard to justify given that we can express the same without introducing new symbols.

[Gozala]

I also since have realized that we actually can express same without having to have selector operation if we allow selectors in operands, because instead of writing this

[
  [".mail[].to[]", ".", "?email"],
  ["match", "?email", "*.fission.codes"]
]

One could instead white this

[
  ["==", ".mail[].to[]", "?email"],
  ["match", "?email", "*.fission.codes"]
]

So we can take out controversial . unless you do actually want to refer to the args as a whole

[
   ["==", ".", "?args"]
]