Confusing overlap between dotted field access and cases pattern matching

[dbp]

When we introduce structured data on its own, we typically use dotted field access (e.g., this is how it shows up in https://dcic-world.org/2025-08-27/intro-struct-data.html#(part._.Extracting_.Fields_from_.Structured_.Data)).

When switching to conditional (& structured) data, a natural motivation for cases is that you don't know if a given variant will have that field, so having, e.g., mylist.first doesn't make sense, since myself may be empty (for example).

However, there is kind of a sideways step to how cases works, because we write:

  | empty => ...
  | link(f, r) => ...

And now in the link branch, rather than using mylist.first (essentially, using if splitting reasoning), there are the pattern matched fields, which are better for typechecking, but if we aren't using that, they seem confusing.

In some sense, assuming we continue to use dotted field access (which I think is good), it seems like it would be less confusing to have cases be able to match just on the tags, i.e.,:

cases (List) mylist:
  | empty => ...
  | link => ...

Have others thought about this?

[jpolitz]

That's a very HtDP way of looking at cases!

The analog of cond is ask, and the predicates are all defined, is there anything worth looking at with this pattern?

ask:
  | is-empty(l) then: ...
  | is-link(l) then: ...
end

[dbp]

I could use ask, but I really like that cases is structural, rather than just a series of boolean expressions (I actually wish we had better errors when cases didn't match constructors, or when no branches match, but that's a separate issue).