Maybe it is a silly question, but I am trying to use Allow for testing equivalence of FOL formulas. In the case of counter-models, is there any way to show them? For instance
sig Value {}
pred p [x: Value] {
// ...
}
assert bla {
(all x: Value | p [x]) iff (some x: Value | p [x])
}
// run p for 2 Value
check bla for 5 Value
It says
Executing "Check bla for 5 Value"
Solver=minisat(jni) Bitwidth=0 MaxSeq=0 SkolemDepth=1 Symmetry=20
16 vars. 5 primary vars. 15 clauses. 1ms.
Counterexample found. Assertion is invalid. 2ms.
But when I click in Counterexample, it opens a window with no instances.
I ran your model for you. There is an instance. Notice that it says "Due to your theme settings, every atom is hidden. Please click Theme and adjust your settings". This means that an instance is being shown, and that if it contains any atoms, they're not shown because of the theme that customizes the visualization. In this case, it's because unconnected integers are not shown in the default theme. You can see the instance either by viewing it in a different way (any of the other options -- Txt, Table, Tree), or by changing the theme.
Related
I have a grammer snippet like this
expr: left=expr '=' right=expr #exprassign
| atom #expratom
;
atom: TEXT
| ID
;
TEXT: '\''(.)*?'\'';
ID:[A-Z]+;
In my visitor method
visitExprAtom()
How can I find getparent context which is current. Lets say my method works under left side say it fromleft other is fromright
I need to change my approaches when I learn where does it come from fromleft or fromright
Thanks.
EDIT:
Let's assume I got a code snippet.
var varcompany='C1';// Creates an variable named company initialated C1
SELECT * FROM TABLE
WHERE COMPANY = varcompany; //COMPANY ='C1'
Above expr grammar is parsing for COMPANY = varcompany
this approach my parser think for COMPANY as a variable and tries to find in my map for it. Or I use atom expression other Dsl scenerios and I need its acting differently. on SQL it must return like 'C1' but other scenerios it must return C1
The first code, couldn't find any instances at Alloy Analyzer 4.2, but the second one, finds well!
What is the differences? My expectation is that, # > 0 and # = 1 acts as the same, when I execute "run show for 1".
1:
sig Fruit {}
pred show() { #Fruit > 0}
run show for 1
2:
sig Fruit {}
pred show() { #Fruit = 1}
run show for 1
When you run a command you will see that the bitwidth (which determines the max Int for Alloy) is 0.
Executing "Run show for 1"
Solver=sat4j Bitwidth=0 MaxSeq=0 SkolemDepth=1 Symmetry=20
0 vars. 0 primary vars. 0 clauses. 2ms.
No instance found. Predicate may be inconsistent. 0ms.
You can change this by explicitly changing bitwidth:
sig Fruit {}
pred show() { #Fruit>0}
run show for 1 but 2 int
Executing "Run show for 1 but 2 int"
Solver=sat4j Bitwidth=2 MaxSeq=1 SkolemDepth=1 Symmetry=20
1 vars. 1 primary vars. 1 clauses. 3ms.
. found. Predicate is consistent. 3ms.
I think when you use '>' operator you will need bitwidth but when you use '=' it is not required.
Working with Int is really discouraged in Alloy.
I'm going to use megaparsec for parsing a programming language for university project. However, I searched for finding a way to report multiple errors.
I know about withRecovery and I saw this issue but I didn't find about the case where errors happen on different positions.
for example in this java code :
class A
{
public get() // line 3 column 10
{
return x // line 5 column 22
}
}
There are error1 "expected type at line 3 column 10" and error2 "missing semicolon at line 5 column 22"
I know I can combine error messages with failure but how about multiple positions ? How do I do that ?
If you're sure about Alec's suggestion, but don't want to have Either (ParseError ...) (Either (ParseError ...) a), you can just use Control.Monad.join on that value to turn it into an Either (ParseError ...) a. Sorry if this wasn't too helpful
I'm writing some specifications of a system in B-method. I have the following variables which are subsets of a general set:
First Notation:
a :={x,y,z,v}
b :={x,y,z}
I want to state a rule that whenever something exists in set "b", it also exists in set "a" which helps writing the above specifications as the following:
second Notation:
a :={v}
b :={x,y,z}
Explanation of second notation: I want the machine to infer that a :={x,y,z,v} from a :={v}, b :={x,y,z}, and the rule.
How can I express the rule so I avoid the first notation and instead write the second notation?
I tried the following but it didn't work
INITIALISATION
a :={v} &
b :={x,y,z}
ASSERTIONS
!x.(x:b => x:a)
First of all, the predicate !x.(x:b => x:a) can be more easily expressed just by b<:a.
It's not clear to me what exactly you want to express: Should b always be a subset of a or just in the initialisation?
If always, the INVARIANT would be the correct location for that. ASSERTIONS are similar but should be an implication by the other invariants.
But then you must explicitly ensure that in your initialisation.
Another point which is unclear to me is what you mean by "infer". Do you just not want to specify the details?
An initialisation where you assign a set with one element more than b could look like the following (assuming that a and b contain elements of S):
INITIALISATION
ANY v,s
WHERE
v:S
& s<:S
THEN
a := s\/{v}
|| b := s
END
(Disclaimer: I haven't actually tested it.)
If a should always be larger than b, you could add something like v/:s.
Your description does not make it clear what exactly you want to achieve.
Another approach would use the "becomes such substitution" (but in my opinion it is less readable):
INITIALISATION
a,b :( a:S & b:S &
b={x,y,z} &
#x.( x:S & a=b\/{x} ))
First, and foremost, the B machine does not infer anything by itself. It provides a language where the user can express properties and a mechanism that generates proof obligations that must be successfully processed by the prover (automatically or with human assistance) to guarantee that the properties hold.
In your example, if you want to express that every element of set bb is always an element of set aa, then as observed by danielp, just write
bb <: aa
Next, if you want to write that aa apossesses an element that is not in bb, then you can express it as
aa /= bb & not(aa = {})
or as
#(elem).(elem : S & elem : bb & not(elem : aa))
If you rather want to express that the specific value vv is in aa but not in bb, then the following applies
vv : bb & not(vv : aa)
These expressions may be used at several locations of the B machine, depending whether you want to assert properties on parameters, constants or variables.
For instance, say you have a machine with two variables va and vb, where both are sets of elements of a given set s1, and that you want they are initialized in such a way that every element of vb is also an element of va, and that there exists an element of va that is not in vb. Observe first that this means that vb is a strict subset of va.
INITIALISATION
ANY inia, inib WHERE
inia <: s1 & inib <: s2 & inib <<: inia
THEN
va := inia || vb := inib
END
/*
sig a {
}
sig b {
}
*/
pred rel_test(r : univ -> univ) {
# r = 1
}
run {
some r : univ -> univ {
rel_test [r]
}
} for 2
Running this small test, $r contains one element in every generated instance. When sig a and sig b are uncommented, however, the first instance is this:
In my explanation, $r has 9 tuples here and still, the predicate which asks for a one tuple relation succeeds. Where am I wrong?
An auxiliary question: are these two declarations equivalent?
pred rel_test(r : univ -> univ)
pred rel_test(r : set univ -> univ)
The problem is that with the Forbid Overflow option set to No the integer semantics in Alloy is wrap around, and with the default scope of 3 (bits), then indeed 9=1, as you can confirm in the evaluator.
With the signatures a and b commented the biggest relation that can be generated with scope 2 has 4 tuples (since the max size of univ is 2), so the problem does not occur.
It also does not occur in the latest build because I believe it comes with the Forbid Overflow option set to Yes by default, and with that option the semantics of integers rules out instances where overflows occur, precisely the case when you compute the size of the relation with 9 tuples. More details about this alternative integer semantics can be found in the paper "Preventing arithmetic overflows in Alloy" by Aleksandar Milicevic and Daniel Jackson.
On the main question: what version of Alloy are you using? I'm unable to replicate the behavior you describe (using Alloy 4.2 of 22 Feb 2015 on OS X 10.6.8).
On the auxiliary question: it appears so. (The language reference is not quite as explicit as one might wish, but it begins one part of its discussion of multiplicities with "If the right-hand expression denotes a unary relation ..." and (in what I take to be the context so defined) "the default multiplicity is one"; the conditional would make no sense if the default multiplicity were always one.
On the other hand, the same interpretive logic would lead to the conclusion that the language reference believes that unary multiplicity keywords are only allowed before expressions denoting unary relations (which would appear to make r: set univ -> univ ungrammatical). But Alloy accepts the expression and parses it as set (univ -> univ). (The alternative parse, (set univ) -> univ, would be very hard to assign a meaning to.)