Question based on the following MWE

MyType: {
    someTag
    numVal: Number <val:37>
    choiceField: MyChoiceType <val:Choice1>
}

MyChoiceType: Choice
Choice1:MyChoiceType { tag1 }
Choice2:MyChoiceType { tag2 }

My expectation is that upon running instantiate(mwe::MyType) I would see an instance with a value of 37 in the numVal field and a tag1 marker. It doesn't appear to work that way as the result I get is

{
  "spec": "mwe::MyType",
  "dis": "MyType",
  "someTag": "marker",
  "numVal": "37",
  "choiceField": {
    "spec": "mwe::MyChoiceType"
  }
}

How do I set a default choice field? In other words, given the choices A, B, C allow any of the choices but make A the default.

Good question. Choices are getting skipped during instantiate right now - see the line of code here.

What you have does seem kind of like perhaps how it should work....

But it leads to a question that have talked about for Haystack 5 and that is replacing choices as tags to be more normal fields. Its quite a significant breaking change though, but it would clear up a lot of semantics. For example:

// haystack 4 ductSection choice
discharge duct equip

// potential Haystack 5 using choices as fields
duct equip ductSection:@DischargeDuctSection

But without breaking everything, we would want to filters to work the old way so that you could match that with a query for "discharge and duct". I think its something we should discuss in Labs WG to nail down exactly what we want to do Haystack 5, then we can clean up this specific detail.

I feel better now because the documentation looks like it was conveying this as the way it should work and I was really struggling.

Choices feel like they should operate just as a mechanism for validation of application of tags which in the end should just behave as if the tags were applied without having ever been a choice. As a secondary benefit of choices being part of the definition/instantiation but not carried through to the instantiated instance is that use can be a little more intuitive as you could set the default value for a choice the same way you set the default value for other types.

As a user it feels to me like choices are ways that I can either apply or validate tags by way of an abstraction, but generate instances that just look like they were tagged manually. I do get this goes back to structural rather than being nominal, but it feels intuitive coming from existing haystack. Plus, my instance should have a nominal spec type assigned, so I can still do nominal type checking, just on the instance, not its choices.

Is it too late to get involved in the WG?

Related tangent: In the example above the numVal field is typed as a number, but unless the default is explicitly set as <val: Number 37> the value upon instantiation is a string, not a number. Shouldn't the typing on the field default to instantiating as the type specified on that slot?

Shouldn't the typing on the field default to instantiating as the type specified on that slot?

Yes, good catch - that an oversight. I pushed a fix. But in the meantime it work correctly if you do declare it like this:

numVal: Number 37