Skip to content

Conversation

@ttuegel
Copy link
Contributor

@ttuegel ttuegel commented Feb 11, 2020

After: #1537

This long-awaited refactoring of the SortedVariable class is necessary to (safely) state certain injectivity properties of toVariable. That allows us to change SideCondition.Representation in turn, yielding a 46% speed-up of the sum-to-n proof.

See also: #1399
Fixes: #1472


Reviewer checklist
  • Test coverage: stack test --coverage
  • Public API documentation: stack haddock

Copy link
Contributor

@traiansf traiansf left a comment

Choose a reason for hiding this comment

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

Although there are a lot of changes, they seem for the better, and code tends to look cleaner now. However, I'll let Virgil approve it, as I know he is more thorough in reviewing it.

@ttuegel
Copy link
Contributor Author

ttuegel commented Feb 12, 2020

There are a lot fewer changes after #1537 is merged.

Copy link
Contributor

@virgil-serbanuta virgil-serbanuta left a comment

Choose a reason for hiding this comment

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

Approving a draft feels a bit weird.

instance Show Representation where
showsPrec prec (Representation typeRep1 _) =
showParen (prec >= 10)
$ showString "Representation " . shows typeRep1 . showString " _"
Copy link
Contributor

Choose a reason for hiding this comment

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

I kind of agree with this, but I'm curious: why didn't you add a Show a requirement besides the Ord one in Representation's definition above, and show the hashed here? Was it to make the output of showing a simplified term manageable?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's exactly it: I'm not sure it would be useful to show the condition, and it would dominate the output to the point that I'm afraid it wouldn't be useful.

from = mkRepresentation
{-# INLINE from #-}

fromText :: Text -> Representation
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we still need this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nope!

@ttuegel ttuegel marked this pull request as ready for review February 12, 2020 18:23
Store the Condition (with its variable names mapped down to Variable) instead of
the unparsed Condition. Using the dynamic representation in this way is Slightly
Evil, but 50% faster.
Taking both the side condition and the configuration as arguments, instead of
only a set of free variables, helps ensure that the rule variables are renamed
to avoid both the configuration AND the side condition.
@ttuegel ttuegel force-pushed the refactor--VariableName branch from 51c59cb to 4536334 Compare February 12, 2020 18:24
@ttuegel ttuegel merged commit 1266149 into runtimeverification:master Feb 12, 2020
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.

Hot-spot: Kore.Internal.SideCondition.fromCondition

3 participants