More Grammar Updates [4]

[AtomCrafty]

Round four.

10. extern function declarations

Issue #23 already notes that attributes are currently not supported on extern function declarations.

Another point is the fact that I removed support for abstract declarators a while back. So implementers are now forced to specify names for the parameters of extern function, instead of just the type. I believe this is a reasonable tradeoff compared to the complexity of abstract declarators. What do you think?

11. Decouple type declarations from variable declarations

User defined types (structs, unions and enums) can currently not be defined without declaring a variable of said type, because the entire type declaration syntax is hidden within the TypeSpecifier rule. I would propose to completely disallow the inline definition of types and instead force the user to declare all types on the ISA level.

@jopperm and I pondered possible use cases for (anonymous) inline type declarations and the only use we could come up with were global singletons, which were basically a workaround for the lack of namespaces in C.

We also discussed the option of removing the need for the struct, union and enum keywords when referring to a user defined type (i.e. allowing declarations like point p; instead of struct point p;), but this still remains as an open question. Since we have no plans to implement a typedef mechanism, this could save the users some typing, and I believe the grammar should still be unambiguous when allowing a single ID token as a type specifier. But I also recognize it would make it less obvious that type names live in a separate scope from variables (the C standard differentiates between identifiers and tag identifiers).

12. Designated initializers

The grammar currently allows the use of designated initializers in initializer lists:

struct point { int x; int y; } myPoint = {
    .x = 5,
    .y = 7
};

Do we really want to support these now? They are a rarely used feature of C, and seeing how we're working towards a minimum viable product at the moment, I would suggest removing them for now. We can always add them back in later on if needed.

[AtomCrafty]

Addendum to 11

Struct member declarations currently allow multiple declarators. Do we want to keep it that way?

struct point { int x, y; } myPoint;

[jopperm]

10. Yeah that's fine.
11. IMHO: Let's confine user-defined type declarations to the architectural_state, disallow variable declarations with anonymous structs/unions, but keep the keyword when referring to the type name. 11a. We do allow those outside of structs, don't we? If so, I'd say yes, let's keep it that way.
12. These initialisers should come back later, if there's demand.

[AtomCrafty]

Do we really want to constrain type declarations to a single ISA module? It might be more sensible to have them directly under the DescriptionContent, that way they could be shared across multiple ISAs.

[jopperm]

I'd say the benefit of types living in ISAs is that their visibility just follows other declarations. Otherwise, they would live in some kind of global scope that may be scattered across multiple files and is potentially dependent on the order of imports.

[AtomCrafty]

Good point. I guess having them in the arch state section is fine.

[AtomCrafty]

@jopperm another point for your todo list: please specify how duplicate type declarations should be handled during elaboration.

[jopperm]

Filed #47 for duplicate decls thing.