Skip to content

Support public key literals and tidy up handling of Raw vs PodId#319

Merged
robknight merged 2 commits intomainfrom
public_key_literals
Jul 1, 2025
Merged

Support public key literals and tidy up handling of Raw vs PodId#319
robknight merged 2 commits intomainfrom
public_key_literals

Conversation

@robknight
Copy link
Collaborator

Closes #299

PublicKeys can now be expressed as Podlang literals:

PublicKey(base58string)

I've also tidied up the handling of PodId vs Raw. Now, any bare hex string (0x-prefixed) is interpreted as a PodId, unless wrapped in Raw(), in which case it will be interpreted as a RawValue.

I'm open to changing these if the wrappers seem too verbose. For instance, maybe we could use a special character prefix for public keys, like + or @, but I thought that it would be better to start with something verbose and then introduce shortcuts if the verbose version is too annoying.

}
write!(f, "…")
} else {
write!(f, "0x{}", self.encode_hex::<String>())
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's more convenient (for me!) if the default is printing the full string, and the alternate version prints the truncated form.

See the test of inserting literals into Podlang code in lang/mod.rs for an example.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have github actions to run the examples. Could you remove the :# in

Equal(?points_pod["{key_signer}"], {game_pk:#})
so that it keeps working?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the MockMainPod we use alternate for Display to print the padding None statements and arguments.
So in MockMainPod alternate leads to more verbosity.
With this change the PublicKey becomes less verbose with alternate.

Maybe we should swap the usage of alternate in the MainMockPod to be consistent? So that alternate always means less verbose by showing less data.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reverted this change.

I think the long-term solution here might be a "to_podlang_string" function, so that we don't have to overload Display with lots of variants for different use-cases. In the meantime I'll stick to the existing convention of using # for more verbosity.

@robknight robknight force-pushed the public_key_literals branch from d31aef8 to 63bae41 Compare June 27, 2025 09:50
@robknight robknight force-pushed the public_key_literals branch from 63bae41 to dba645a Compare June 27, 2025 09:50
Copy link
Collaborator

@ed255 ed255 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall! Please take a look at my comments and suggestions.

}
write!(f, "…")
} else {
write!(f, "0x{}", self.encode_hex::<String>())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have github actions to run the examples. Could you remove the :# in

Equal(?points_pod["{key_signer}"], {game_pk:#})
so that it keeps working?

}
write!(f, "…")
} else {
write!(f, "0x{}", self.encode_hex::<String>())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the MockMainPod we use alternate for Display to print the padding None statements and arguments.
So in MockMainPod alternate leads to more verbosity.
With this change the PublicKey becomes less verbose with alternate.

Maybe we should swap the usage of alternate in the MainMockPod to be consistent? So that alternate always means less verbose by showing less data.

@robknight robknight merged commit b123185 into main Jul 1, 2025
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Representation of new Typed Value types in Podlang

2 participants