(Semi)Planned extension: "printf"

[alastairreid]

Motivation

We have not yet implemented the ASL1 feature of print that supports multiple arguments and, instead, we rely on overloading to have "print" map onto several different print functions. (In fact, this is the main use of overloading!)

Also, it would be good to have more control over print formatting to control use of decimal/hex, zero-padding, etc.

Also, ASLi does not do a great job of generating print functions for user defined types like records.
And for bitvectors with named fields, it would sometimes be good to split values into fields.

Plan (incomplete)

The first step is obviously to implement ASL1's print feature so that we can write print("The value of p is", x).
This would be implemented by having the typechecker recognize calls to "print" and expand it into a sequence of calls to type-specific print commands.

This could possibly be extended using a variant of the proposed named argument extension (#29) to provide values for type-specific formatting control variables. (This would work better if #29 also supported default values - but it is not clear whether that would be a good design choice)

Alternatively, it could be extended using a "printf"-like control string "like "The value of p is %08x"

Related

Instead of generating human-readable strings, it is often really useful to generate machine-readable output such as json/yaml/... We don't necessarily want to do this right away - but it would be good to sketch a design in the hope that there could be a shared mechanism.

In some cases, (e.g., floating point), we don't always want to see the raw record, we would rather use some user-defined formatting function. Can that fit into this design?