Inform user if a colliding constant overrides a field reference

[philrz]

A user asked in a community Slack thread:

I presume this is more or less expected, that if there's a name collision between a type and a field, the type is preferred:

❯ zq 'type foo={foo:int64} yield {foo:1} | shape(this,<foo>) | search foo==1'                     

❯ zq 'type foo={foo:int64} yield {foo:1} | shape(this,<foo>) | search is(<foo>)'
{foo:1}(=foo)

or if not "expected" - just a natural consequence of the collision?

Later adding:

i wonder if in the case of collisions like this, if a warning could be issued somehow

Details

Repro is with Zed 6b4afe5.

We explained to the user that one way to disambiguate the first example shown above would be to use the "Indexing" approach to Field Deference, i.e.,

$ zq -version
Version: v1.16.0-12-g6b4afe50

$ zq 'type foo={foo:int64} yield {foo:1} | shape(this,<foo>) | search this["foo"]==1'
{foo:1}(=foo)

Indeed, in a few places in the docs we touch on convenient Zed shorthand (e.g., referencing fields "bare" by their names) vs. longer/canonical form (e.g., field reference with indexing) and how the latter might be better suited for larger, more complex programs, which are the same kinds of programs likely to include type and const. However, the shorthand is convenient enough that users may continue using it until they're burned enough times to change their habits, and along the way they may get frustrated. So it may be appropriate to add some guardrails.

@nwt pointed out that the presence of the type effectively dooms the search from ever producing meaningful results since it means the search no longer in any way references the this values that represent the dataflow that search would see as input. Therefore it would become feasible for the tooling to provide some kind of warning of this at compile time as the user suggested.

We discussed as a team other guardrails we could offer also/instead. @mattnibs pointed out that we could require some kind of leading sigil for type and const definitions, e.g., like how $ is used in some languages. Indeed, in Zed programs we see from users, type and const are used rarely enough that it doesn't seem like such sigils would add a lot of visual clutter to a program. They would have helped avoid this particular collision, and it would also make the references to them more self-documenting.

Before hearing the sigil proposal, I also thought of use strict from Perl, i.e., we could offer some kind of mode that effectively requires a Zed program be written exclusively in canonical form so these kinds of collisions can't happen. I've worked in Perl shops in the past where all the code in the source control system needed to be written in use strict mode to pass muster, so a user that had an experience like this one could learn about Zed's "strict mode" and resolve to stick to it going forward. That said, I recognize it's probably too heavyweight for solving this particular problem.