Skip to content

Fix set 3rd round #619

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

Closed
wants to merge 10 commits into from
Closed

Fix set 3rd round #619

wants to merge 10 commits into from

Conversation

mmatera
Copy link
Contributor

@mmatera mmatera commented Nov 14, 2022

This completes the fixes needed to pass all the failing tests added in the first round.

rocky and others added 7 commits November 13, 2022 07:45
* More apply() -> eval() cutovers in the changed files
* Some <dt> indentation regularization.
* DRY redundant "argr" message definitions
Add SetAttributes length check and ...
…SyntaxAnnotation.m does not kill the interpreter
while the second,
``p[-4]/; -4>0``

This should be handled in the apply method of the BaseRule class.
Copy link
Member

@rocky rocky Nov 14, 2022

Choose a reason for hiding this comment

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

This was going to be my point as well. Too often it feels that when we try to run to run some WL code and that fails, the immediate solution is well, let's just add a bunch of flags and tests on symbols in Python code address the specific case we see.

This is done instead of seeing the problem as a manifestation of some larger structural problem, or feature lacking in the way particular built-in functions should work.

I would prefer to see fixing the root cause issues in favor of the workaround coding.

(You probably mean eval method, but okay.)

Copy link
Contributor Author

@mmatera mmatera Nov 14, 2022

Choose a reason for hiding this comment

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

This was going to be my point as well. Too often it feels that when we try to run to run some WL code and that fails, the immediate solution is well, let's just add a bunch of flags and tests on symbols in Python code address the specific case we see.

No, the idea is to identify these issues, and then try to understand how it works and how it should work, and then fix it.

This is done instead of seeing the problem as a manifestation of some larger structural problem, or feature lacking in the way particular built-in functions should work.

A manifestation of a large structural problem is the performance issue, and the fact that we can not load wl modules. All of this is about to narrow the different issues and try to determine what should be the pattern.

I would prefer to see fixing the root cause issues in favor of the workaround coding.

The workaround was there for a while. What I did here is to determine why this workaround was needed to reproduce the WMA behavior. As the picture gets clear, we can continue removing these issues, like the one with oneidentity. What I am trying to avoid is to pretend to fix many things in the same PR.

(You probably mean eval method, but okay.)

I said apply, because is the current name of the method. Then, if you think that is more clear/ accurate to say "evaluate a replacement rule over an expression" over "apply a replacement rule over an expression" let's change the name of the method.

Copy link
Member

@rocky rocky Nov 14, 2022

Choose a reason for hiding this comment

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

The workaround was there for a while. What I did here is to determine why this workaround was needed to reproduce the WMA behavior. As the picture gets clear, we can continue removing these issues, like the one with oneidentity. What I am trying to avoid is to pretend to fix many things in the same PR.

So what I am thinking is let's focus on removing the workarounds that we can fix rather than changing workarounds.

I know of some on the horizon but that could be fixed now, like #597 and the box precedence operator. Stuff like this keeps rolling in though which from my standpoint isn't helping as much as it is delaying getting more root issues fixed.

Copy link
Member

@rocky rocky Nov 14, 2022

Choose a reason for hiding this comment

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

I said apply, because is the current name of the method. Then, if you think that is more clear/ accurate to say "evaluate a replacement rule over an expression" over "apply a replacement rule over an expression" let's change the name of the method.

I just looked this up in the code. You are correct - this method named apply is doing application, not evaluation. And this reinforces why it would be better to have terminology cleaned up - I often do not know if a term is used in the right sense or the wrong sense and conceptually they mean different things so I get more confused.

@rocky
Copy link
Member

rocky commented Nov 14, 2022

No, the idea is to identify these issues,

Ok - it would be helpful create detailed and narrowed issues for these.

mmatera and others added 3 commits November 15, 2022 01:08
* improving clarity in Builtin.contribute

* adding comments. adding tests

* fix test for SetDelayed. Move special case for Set with LHS a list away from the conditional.

* more on modularize assignment. assign_elementary->assign

* fixing set_eval

* adding tests for OneIdentity

* fix OneIdentity

* remove comment

* fix pytest

* fix a bug that makes that URLSave always fails

* fix WriteString standard output

* catch not known attributes in ClearAttributes and SetAttributes

* Update 'attributes' for current standards

`mathics.builtin.attributes`:

* apply -> eval
* Add WMA links add
* Class names ordered alphabetically
* Hard breaks in docstring removed
* Some incorrect references to "leaves" changed to "attributes"

`mathics.core.attributes`:

* Add short comments above flag value

* adding comments. adding tests

* fix test for SetDelayed. Move special case for Set with LHS a list away from the conditional.

* more on modularize assignment. assign_elementary->assign

* Handle optional with a first element that is not a Pattern[]

* Update examples in OneIdentity

* More pervasive use of Symbols

symbols.py:
   system_symbols() -> symbol_set(); "systems_symbols" name is too close
Symbol( System`  to module systemsymbols. Also, we now require symbols as parameters),
   not strings.

systemsymbols.py: more system symbols

* Pattern_create -> Pattern.create

It appears this was originally Pattern.create. I suspect due to bad
modularity and a lack of understandig Python that an import could be added inside the
routine, this static method got moved outside of the class.

Later on, the modularity was fixed, but the hack persisted. These kinds
of code smells side effects of poor communication.

* Add function signature; straighten import issue

* Put test_rules_patterns tests where they belong

* Add note to add skipped example as a doctest ...

When it gets fixed.

* Changes suggested in PR review

Move core-like assignment interals out of builtins and into core.
(We may want to split up core more in the future though)

Better sort long list of assignment methods alphabetically

Some small RstT tagging in a docstring

Remove nonexistent word "evaluable"

Add yet another type annotation to a signature

Make test assert failure messages unique

* Move ASSIGNMENT_FUNCTION_MAP into core

Co-authored-by: R. Bernstein <rocky@users.noreply.github.com>
Co-authored-by: rocky <rb@dustyfeet.com>
@mmatera
Copy link
Contributor Author

mmatera commented Nov 19, 2022

Superseded by #625

@mmatera mmatera closed this Nov 19, 2022
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.

2 participants