Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor for Dialect. #99

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Refactor for Dialect. #99

wants to merge 1 commit into from

Conversation

richardkiss
Copy link
Contributor

No description provided.

self.apply_kw = apply_kw
self.opcode_lookup = dict()
self.multi_op_fn = ChainableMultiOpFn(self.opcode_lookup, multi_op_fn)
self.to_python = to_python
Copy link
Contributor

Choose a reason for hiding this comment

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

I thought the convention these days was to declare members, with types and sometimes initial values in the class body, rather than just assigning them in the __init__() function.

from .casts import int_to_bytes
from .dialect import ConversionFn, Dialect, new_dialect, opcode_table_for_backend

KEYWORDS = (
Copy link
Contributor

Choose a reason for hiding this comment

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

is the dialect responsible for compiling clvm code into byte-code too? if not, we could just put the full function names in this list, removing the need for OP_REWRITE and some of the logic in op_atom_to_imp_table

from .types import CLVMObjectType, ConversionFn, MultiOpFn, OperatorDict


OP_REWRITE = {
Copy link
Contributor

Choose a reason for hiding this comment

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

this seems like it also would belong in the chia-specific dialect, no?

@@ -1,4 +1,4 @@
brun --backend=python -c -v '(x)'
brun -c -v '(x)'
Copy link
Contributor

Choose a reason for hiding this comment

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

this would cause the clvm_rs tests to fail, wouldn't it?

self.to_python = to_python

def update(self, d: OperatorDict) -> None:
self.opcode_lookup.update(d)
Copy link
Contributor

Choose a reason for hiding this comment

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

given that you have this update() function, why do you need to be able to chain the multi_op_fn with ChainableMultiOpFn? it looks more complex than it needs to be

quote_kw: bytes, apply_kw: bytes, strict: bool, to_python: ConversionFn
) -> Dialect:
unknown_op_callback = (
clvm_rs.NATIVE_OP_UNKNOWN_STRICT
Copy link
Contributor

Choose a reason for hiding this comment

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

are these flags or magic-values exported by the rust bindings, to indicate it's a native rust function?

# Test construction from an already existing OperatorDict
o2 = OperatorDict(o)
self.assertEqual(o2.apply_atom, 1)
self.assertEqual(o2.quote_atom, 2)
Copy link
Contributor

Choose a reason for hiding this comment

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

OperatorDict is still a type that exists. It's not clear why it shouldn't have a test

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.

None yet

2 participants