Most of the types that were missing are special magic types that the FATE operations such as the AENS take as inputs, that get hard-coded into the Sophia compiler's type checking environment.
Long term we could refactor this to be one of the things that the sophia compiler exposes, allowing us to extract the list of built-in types dynamically, even when multiple versions of Sophia are being switched between dynamically. For now, whatever, having a well-defined AACI is good enough.
This commit combines 13 separate commits, see https://git.qpq.swiss/QPQ-AG/hakuzaru/commits/branch/primtypes for the full development.
Most of the types that were missing are special magic types that the FATE operations such as the AENS take as inputs, that get hard-coded into the Sophia compiler's type checking environment.
Long term we could refactor this to be one of the things that the sophia compiler exposes, allowing us to extract the list of built-in types dynamically, even when multiple versions of Sophia are being switched between dynamically. For now, whatever, having a well-defined AACI is good enough.
This commit combines 13 separate commits:
add more atoms to AACI
serialize signatures
This took a surprising number of goose chases to work out... I had to
find out
- what is the gmser prefix for a signature (sg_)
- what is the gmb wrapper for a signature (none)
- what errors gmser can report when a signature is invalid
- what an example of a valid signature is
- what that example signature serializes to
coerce stringy booleans
coerce bytes
coerce bits
The thing to remember about bits is that they are actually integers...
It is tempting to present bits as binaries, but that hides the nuance of
the infinite leading zeroes, the potential for infinite leading ones,
etc.
coerce character
It's really just an integer... Should we flatten it to an integer
instead? I don't know.
Also coerce unicode strings to FATE
This is mainly so that gajudesk can pass text box content to hz as-is,
but also allows users to pass utf8 binaries in, if they want to, for
some reason.
Coerce binaries as-is
Sophia accepts both sg_... and #... as signatures, so we should probably
accept binaries as signatures directly. People might expect to be able
to put the listy string "#..." in too, but that is more complex to do.
coerce hashes
It turns out there are a lot of types that, like option, should only be
valid as an opaque/normalized type, but should be substituted for
something different in the flat representation. If we restructure things
a little then we can implement all of these in one go.
Refactor type normalization
Some of these checks were redundant, and we probably don't actually need
substitution to wrap success/failure, since it isn't expected to fail
anyway... Now the logic is much simpler, and adding more built-in type
definitions should be easy.
Add a map for builtin types
This makes it much easier to implement all these standard library
things.
In doing so I changed the convention for option, hash, unit, to be
stringy rather than atoms.
Also I changed some error messages based on what was more helpful during
debugging of the unit tests.
Add more builtin types
We probably should extract these from the standard library instead of
cherry picking the ones that are needed by the chain? e.g. Chain.tx
still doesn't work.
remaining types
`tx` isn't defined in all the same places that pointee, name, base_tx,
fr, fp are defined, but actually it is the only one not in the list I
was looking at, so we are all good. As demonstration, there is also a
test case for Set.set, despite Set.set not being defined as a builtin
type.
spivee
requested review from zxq9 2025-09-30 15:17:42 +09:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This commit combines 13 separate commits, see https://git.qpq.swiss/QPQ-AG/hakuzaru/commits/branch/primtypes for the full development.
Most of the types that were missing are special magic types that the FATE operations such as the AENS take as inputs, that get hard-coded into the Sophia compiler's type checking environment.
Long term we could refactor this to be one of the things that the sophia compiler exposes, allowing us to extract the list of built-in types dynamically, even when multiple versions of Sophia are being switched between dynamically. For now, whatever, having a well-defined AACI is good enough.
This works as far as I've used it. Going ahead with a merge and we can revisit it next week once @spivee is finished getting hitched.