Adding new bitvector literals and enum/struct Notations for constr #3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've been wasting some time creating / adapting some Koika notations to make the language a bit more usable.
(Examples shown here can be found and executed in
Parsing.v
)Features
New bitvector literals
The default bitvector literals (
|size 'd deciaml|
andOb~1~0~...
) seemed a bit inconsistent and tedious to me. Additionally, they did not support hex and the first one is only accessible from within Koika.The new proposed literals are usable from Koika as well as from normal Coq. They support 4 bases hex, decimal, octal and binary.
Their syntax looks like this
| prefix? "literal" postfix? size? |
.Either the prefix or the postfix must be present to declare which base is used.
Prefixes :=
0b 0o 0d 0x
Postfixes :=
:b :o :d :h
The size is also optional. If it is inferred, it will be derived from the length of the literal for binary, octal and hex, as for these bases the length directly corresponds with the bit vector length. For decimal, however, the bit vector length is the minimum necessary to encode the given value.
Examples:
Enum literals in Coq
To access enum values by their name, I am proposing a new notation for Coq (
enum e_name < FIELD >
). Unfortunately, I wasn't able to exactly match the enum notation which already exists inside Koika, which is using curly braces instead of angle brackets.Struct literals in Coq
Just like Koikas enums, structs did not have a syntax to construct them in Coq. They had to be built like this:
(Bits.of_N 3 1, (Bits.of_N 5 2, (... , tt)))
. Which made it hard to mentally associate the field's position with its purpose.The new syntax looks similar to the Koika syntax, again with the adaption of using angle brackets.
Example:
Adapting match
The old match syntax didn't accept sequences on the branches, they always had to be wrapped in parentheses. I don't see the need for keeping the branch level lower than the level of sequences. Consequently, I lifted the level to declutter the syntax a bit.
As the branch is completely enclosed within the arrow (
=>
) and the bar (|
) of the next guard, there should be no problem.So the following match could now be written without parentheses.
A new if
The default if always expects an else-branch (which is often left empty with
else pass
). Therefore, I see the need for an if statement that can be used without else. For the time being, I added one calledif' .. then ..
, but it doesn't fit very nice with the syntax.Future ideas for if
In the future, I would really like to have some kind of if in combination with an early return to write code with less nesting. Currently, with the if-statement that always needs the if- and the else-branch, code has to be nested very deep in certain situation.