poke-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RFC] Syntax for fields with both explicit constraints and initializers


From: Matt Ihlenfield
Subject: [RFC] Syntax for fields with both explicit constraints and initializers
Date: Fri, 05 Mar 2021 03:22:30 +0000

Hi everyone!

It's currently not possible to have a field in poke that has both an 
initializer and an explicit constraint. This is limiting, as it prevents users 
from providing a default field value (making struct construction easier) and 
allowing a range of valid values for the field at the same time.

Take for example a file format that by default stores data in uncompressed 
chunks, but that provides the option to compress the data with a few different 
algorithms:

var COMP_LZO = 0;
var COMP_ZLIB = 1;
var COMP_NONE = 3;

type Chunks =
struct {
    uint<8> comp_type : comp_type in [COMP_NONE, COMP_LZO, COMP_ZLIB];
    uint<32> data_len;
    byte[data_len] data;
}

In this version we've restricted what the comp_type field can be, so if a user 
wants to create a Chunk they have to provide a compression value even though 
there is a supposed to be a default:

var chunk = Chunk { .comp_type = COMP_NONE }

We can't provide a default value for the compression type without also 
restricting the comp_type value to just that one type.

As a solution I propose the following new syntax for struct fields:

TYPE NAME [=INITVAL] [: EXPR]

where INITVAL is the default field value that is used if none is provided, and 
EXPR is a constraint expression. Here's how I would propose handling the 
different combinations of INITVAL and EXPR:

- No INITVAL or EXPR: No change
- Only INITVAL: No change
- Only EXPR: No change
- Both INITVAL and EXPR: INITVAL is treated as only a default value, and no 
implicit constraint is created based on it. The only constraint that will exist 
is the one declared by EXPR. The explicit constraint overrides the implicit 
constraint that would normally be created.

For example we could make the comp_type field above have a default of COMP_NONE 
like so:

...
uint<8> comp_type = COMP_NONE : comp_type in [COMP_NONE, COMP_LZO, COMP_ZLIB];
...

and then you can construct a chunk with just:

var chunk = Chunk {}
assert(chunk.comp_type == COMP_NONE);

Thoughts?

Matt Ihlenfield




reply via email to

[Prev in Thread] Current Thread [Next in Thread]