> For example, CONST parameters
>
> https://github.com/m2sf/m2bsk/wiki/Language-Description#formal-parameters
>
> indeterminate records (called VLA structs in C)
>
> https://github.com/m2sf/m2bsk/wiki/Language-Description#indeterminate-types
>
> the foreign function interface identifier mapping pragma
>
> https://github.com/m2sf/m2bsk/wiki/Language-Description#ffident-pragma
>
> Other than that, take a look at the chapter on low-level facilities
> for further inspiration
>
> https://github.com/m2sf/m2bsk/wiki/Language-Description#low-level-facilities
yes well I guess I'll be starting this summer
sounds good.
- as I'm not going anywhere :-) for a while.
Make sure you stay healthy.
The ordering seems sensible above in ease of implementation
Indeed.
However, allow me a caveat on indeterminate record types ...
We had moved away from using an additional reserved word prefix in the declaration syntax for indeterminate record types.
Instead we allow such a declaration only in implementation modules and use POINTER TO RECORD for their declaration.
In our case this is unambiguous because we do not otherwise permit POINTER TO RECORD, but only POINTER TO <identifier>.
This means if you want to add indeterminate record types as a GM2 extension to PIM and ISO mode, then POINTER TO RECORD would be ambiguous as it could be either a pointer type declaration to an ordinary record or a declaration of an indeterminate record.
The ambiguity can be resolved by looking for the last field. If it is prefixed by a + then it is an indeterminate record declaration.
However, this is not LL(1) then. If your parser is bottom up, that won't be an issue, but if it is recursive descent, then you may want to introduce a prefix for the indeterminate record declaration to allow your grammar to remain LL(1).
Anyway, something to keep in mind when adding features from R10 to PIM or ISO modes.