Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@nishantjr
Copy link
Contributor

  • Keep a dict: alias -> node_id
  • Create a short_id function that returns the alias if present, or else the shortened hash.
  • pretty_print and to_dot use short_ids instead of shorten_hash.

@nishantjr nishantjr requested a review from ehildenb June 7, 2022 21:59
@nishantjr
Copy link
Contributor Author

@ehildenb I went for short_id instead of alias cause I geel its more descriptive.

@nishantjr nishantjr requested a review from tothtamas28 June 21, 2022 16:02

def _resolve_all(self, short_id: str) -> List[str]:
return [node_id for node_id in self._nodes if compare_short_hashes(short_id, node_id)]
def _resolve_all(self, id_like: str) -> List[str]:
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd call this _resolve_hash, and keep its old behavior.

Then _resolve_or_none can be implemented as follows.

  • If id_like is a hash, then delegate to _resolve_hash, and raise an exception if there are multiple results.
  • Otherwise, we have an alias. If it starts with @, drop the first character.
  • Try to resolve the alias.

As a result, @ is optional, and can be used to enforce strings to be resolved as aliases (as something starting with @ is never a hash). So for example

  • abcd is resolved as a hash
  • @abcd is resolved as alias abcd
  • hello is resolved as alias hello
  • @hello is resolved as alias hello

Optionally, we can also refine _resolve to give a more specific error message if resolution fails:

  • If id_like is a hash: Unknown node hash: ...
  • Otherwise: Unknown alias: ...

What do you think?

Copy link
Contributor Author

@nishantjr nishantjr Jun 22, 2022

Choose a reason for hiding this comment

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

I like the refactoring. But wasn't the whole point of adding the @ to avoid confusion between the two?

Copy link
Contributor

@tothtamas28 tothtamas28 Jun 22, 2022

Choose a reason for hiding this comment

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

But wasn't the whole point of adding the @ to avoid confusion between the two?

My point is that if id_like is not a valid hash, we can omit the @, because we know we have an alias. But this is just a small usability improvement.

In any case, the input should be validated to be either a hash or an alias (if @ is optional, the latter does not have to be checked).

@nishantjr nishantjr requested a review from tothtamas28 June 22, 2022 17:32
@nishantjr nishantjr merged commit d25ac48 into master Jun 23, 2022
@nishantjr nishantjr deleted the pyk-kcfg-aliases branch June 23, 2022 21:01
h0nzZik pushed a commit to h0nzZik/k that referenced this pull request Nov 24, 2022
…untimeverification#2042)

* haskell-backend/src/main/native/haskell-backend: 9247a969d - Prune unsatisfiable state with unifyStringEq (runtimeverification#2647)

* haskell-backend/src/main/native/haskell-backend: 797767163 - modified matchEquation to accept new equation format (runtimeverification#2688)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants