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.

Sign up for GitHub

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

Jump to bottom

upgrade pattern matching #15

Closed
andrewbutterfield opened this issue Jan 17, 2023 · 6 comments
Closed

upgrade pattern matching #15

andrewbutterfield opened this issue Jan 17, 2023 · 6 comments
Assignees
@GH-James

Comments

@andrewbutterfield
Copy link
Owner

Want to get away from Coconut, use p.m. in 3.10+
@andrewbutterfield andrewbutterfield mentioned this issue Jan 17, 2023
Open
9 tasks
@GH-James
Copy link
Collaborator

I was successfully able to rename all .coco files to .py and run them
This produced identical output and test files
However, it still does not appear to be standard python, and many errors appear in my IDE.

Having looked further into the code, it seems that the syntax_*.py files are not referenced in the testbuilder.py execution
The below output shows all files containing references to those alongside the relevant lines

grep -r -e "import.*testgen\|testgen.*py\|testgen.*coco" *
Makefile:       coverage run --branch -m pytest --capture=tee-sys -vv -s $(DIR_TESTS)/test_coverage_testgen.py $(DIR_TESTS)/test_coverage_spin2test.py
examples/draft/make.sh:coconut --target 3 testgen.coco --mypy --follow-imports silent --ignore-missing-imports --allow-redefinition
examples/draft/make.sh:exec python3 "$HOME0/testgen.py" "$@"
src/tests/library.coco:from src import testgen
src/tests/library.py:from src import testgen
src/tests/test_coverage_testgen.coco:from src import testgen
src/tests/test_coverage_testgen.coco:        testgen.copy_i fic1.name fic1.name
src/tests/test_coverage_testgen.coco:            testgen.copy_i fic1.name fic2.name
src/tests/test_coverage_testgen.coco:            testgen.copy_i (fic1.name, fic2)
src/tests/test_coverage_testgen.coco:            testgen.copy_i (fic1.name, fic2)
src/tests/test_coverage_testgen.coco:            testgen.copy_i (dir_test, fic2)
src/tests/test_coverage_testgen.py:from src import testgen
src/tests/test_coverage_testgen.py:        testgen.copy_i(fic1.name, fic1.name)
src/tests/test_coverage_testgen.py:            testgen.copy_i(fic1.name, fic2.name)
src/tests/test_coverage_testgen.py:            testgen.copy_i(fic1.name, fic2)
src/tests/test_coverage_testgen.py:            testgen.copy_i(fic1.name, fic2)
src/tests/test_coverage_testgen.py:            testgen.copy_i(dir_test, fic2)
testgen_ml.coco:import src.testgen
testgen_ml.py:import src.testgen
testgen_ml.sh:exec python3 "$HOME0/testgen_ml.py" "$@"
testgen_ml_spin.sh:exec python3 "$HOME0/testgen_ml.py" "$HOME0/../examples/model_checker/spin.pml" "$@"
testgen_yaml.coco:import src.testgen
testgen_yaml.py:import src.testgen
testgen_yaml.sh:exec python3 "$HOME0/testgen_yaml.py" "$@"
testgen_yaml_spin.sh:exec python3 "$HOME0/testgen_yaml.py" "$HOME0/../examples/model_checker/spin.pml" "$@"

Are the syntax_*.py files related to the automatic test generation process rather than the standard process I've been working on?

If so is there a different way to test them?

Aternatively, does it make more sense to merge my current work related to testbuilder.py, and move onto another issue for now?

@andrewbutterfield
Copy link
Owner Author

andrewbutterfield commented Feb 13, 2023 via email

@GH-James
Copy link
Collaborator

GH-James commented Feb 13, 2023 •
edited
Loading

There is use of coconut syntax in areas outside that match, add_pattern format that was seen in previous files.

Something like the following in syntax_yaml.coco line 79 is the most common.

def parse_directive (line):
    match (var_c, arg) in syntax_pml.directives_refine.parse line:
        match [[ty_name, ty_arity], var_pml] in safe_load arg if isinst_list (isinst_str, [ty_name, var_pml]) and (ty_arity is None or isinstance (ty_arity, int)):
            return (var_c, (ty_name, int (ty_arity) if ty_arity else None), var_pml)
        else:
            return None
    else:
        return None

from coco docs: https://coconut.readthedocs.io/en/latest/DOCS.html#match

match <pattern> [not] in <value> [if <cond>]:
    <body>
[else:
    <body>]

In standard python this would become

def parse_directive (line):
    match syntax_pml.directives_refine.parse(line).split():
        case [var_c, arg]:
            match safe_load(arg):
                case [[ty_name, ty_arity], var_pml]:
                    if isinst_list(isinst_str, [ty_name, var_pml]) and (ty_arity is None or isinstance(ty_arity, int)):
                        return (var_c, (ty_name, int (ty_arity) if ty_arity else None), var_pml)
                    else:
                        return None
                case _:
                    return None
        case _:
            return None

There are multiple cases of missing brackets which get put in place by coconut:

function args

compared to

function(args)

Other examples include syntax_yaml.coco line 91

unparse_annotation_cmd = (cmd, args) -> syntax_pml.unparse_annotation_cmd (json.dumps ([{cmd : args}]))

which is an unusual (I presume coconut) syntax for lambda functions

unparse_annotaction_cmd = lambda cmd, args: syntax_pml.unparse_annotation_cmd(json.dumps([{cmd:  args}]))

There are also examples of coconut

case:
    match:

Rather than python

match:
    case:

And the following from syntax_yaml.coco line 171:

group_max (syntax_pml.parse_annotations_directives $ parse_directive <*| strip_find_annot ([syntax_pml.make_annotations (False, cmds0, pos_file, pos_line, '')])):

Which converts to:

group_max((_coconut.functools.partial(_coconut.functools.partial, syntax_pml.parse_annotations_directives)(parse_directive))(*strip_find_annot([syntax_pml.make_annotations(False, cmds0, pos_file, pos_line, ''),])))

As far as I can tell in native python it would be something like:

group_max(syntax_pml.parse_annotations_directives(parse_directive(*strip_find_annot([syntax_pml.make_annotations(False, cmds0, pos_file, pos_line, '')]))))

Some significant refactoring needs to happen, as its unclear to me what is happening in lines like that

While I'm happy to translate from coconut to native python, I wouldn't be confident to push changes without a meaningful way to test the changes.

@andrewbutterfield
Copy link
Owner Author

A lot of this seems to be the code that reads in config data from comments in PML files. This comes in under issue #16 .

The approach might be see which scripts call which here - get a picture of the structure.

We'll discuss this at the meeting

@andrewbutterfield
Copy link
Owner Author

Fix .gitignores so relevant py files are tracked
do PR

@GH-James GH-James mentioned this issue Feb 17, 2023
Merged
@andrewbutterfield andrewbutterfield mentioned this issue Feb 17, 2023
Open
@andrewbutterfield
Copy link
Owner Author

Pattern matching updated.

As remaining Coconut has more to do with #16, we can close this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@GH-James GH-James

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@andrewbutterfield @GH-James