Your misunderstanding comes from the type you give to fields. In your example the field root is not of type Node but of type BinaryTree -> Node as it relates a BinaryTree to a Node. Just like your the field root, the relation Node -> Node is also of arity...

I can think of two approaches. (But I realize, re-reading your question that I have no idea what your last paragraph means. So perhaps this is all irrelevant to your goals.) First: A disjoint union labels each member with a flag so you know which parent set it came from,...

To give some context, I tried to limit the domain of a relation and found, that using only + seems to be more efficient, even when the sets are completely known in advance. That is pretty much the right conclusion. The reason is the fact that the Alloy Analyzer...

Yes, this is one thing about Alloy's * operator that is occasionally surprising. Jackson discusses it in the questions after section 3.4.3.5 of Software Abstractions (pp. 65-66 in the revised edition). The explanation offered there is: Although this seems odd, it follows naturally from the definition of reflexive-transitive closure and...

To answer the direct question: I for one have never found a way to make the visualizer change its mind about which nodes should be on the same horizontal level. (That doesn't quite mean it's not possible, but it does mean that if it's possible it's not immediately obvious how...

If each of the signature extending another one have a well defined scope, (it is the case for the small exemple you gave, then the the analyzer is "smart enough" to understand that the scope of the top level signature is at least equal to the some of the scopes...

You can only declare an exact scope for String, e.g., run {} for 3 but exactly 5 String It is currently not possible to only give an upper bound for Strings, e.g., for 5 String, and ask Alloy to find a solution (with respect to other constraints) with up to...

Section 4.5.2 of Software Abstractions describes (among other things) what it calls the 'receiver' convention, that is the syntactic shorthand of writing functions and predicates as fun X.f[y : Y, ...] { ... this ... } instead of fun f[x : X, y : Y, ...] { ... x ......

By a bit of search I found the answer: It is only necessary to define a desired Theme in the demonstration window: click the Theme button in the toolbar and do what ever you'd like! In above specific case remove the tick from the "show as arcs" option of arrow...

Using the Alloy java API, you can easily evaluate expressions in an instance. Get the module the instance has been generated from using one of the methods of the CompUtil class. Then retrieve the instance you are interested in (that has been previously saved in an xml file) as follows...

This is very simple! my bad! You just need to push the Stop button in the toolbar! since always the execution was so fast, I never noticed that in alloy IDE, Execute button turns into Stop button during a model execution!...

Now i guess I would use some sort of set comprehension, but the issue is that set comprehension only works with unary sets, not binary sets. Right the first time (yes, use set comprehension), not quite right the second (set comprehensions work fine with relations). See section B.8 of...

High order quantification is often discouraged as, to my understanding, the Alloy Analyzer can't always deal with them. (it uses skolemization to get rid of them, but those can't always be applied) I would thus simplify your model as follows : sig Thing{ } run predicate for exactly 4 Thing...

question 1: what do square brackets indicate in the grammar? You rightly pointed out that the use of square brackets is inconsistent in the grammar you referred to. I think that grammar was copied from the first edition of the "Software Abstractions" book; I'm not sure if the second...

Alloy has unfortunately no Boolean type. Without a proper type, you can't declare arguments for your predicate. Your approach seems thus a lost cause. I can think of two ugly tricks both involving the use of util/boolean or your own Boolean definition to make things work. In both tricks your...

Thanks for all your help but I did it the following way eventually: First I restricted my bags to contain only elements with non-zero multiplicity module bags open util/natural open util/relation sig Element{} sig Bag{ elements: Element -> one Natural }{ all e: Element.elements | e != Zero } And...

Each instance of show should include one Book, labeled as being the b of show, which has two address pairs. But show does not say that every book must have two address pairs, only that at least one must have two address pairs. [Postscript] When you ask Alloy to show...

Bijection relation need to be injective and surjective. so the answer would be as following: sig A {} sig B{} sig C{r : one A+B} fact { all c1,c2: C | c1.r=c2.r implies c1=c2 // r is injective all ab: A+B | some c:C | c.r=ab // r in surjective...

Ask yourself two questions. First: in Go, what constitutes a group? You say yourself: it is a set of adjacent stones with the same color. Not that every stone in the group must be adjacent to every other; it suffices for every stone to be adjacent to another stone in...

They are checked. The phenomenon you are pointing out in your question is explained in the Software Abstraction Book page 126. It's basically written that the type checker will report an error if and only if the type of the argument declared in the predicate and the type of the...

For reasons I never quite understood, at some point Alloy's syntax changed from using (or allowing) parentheses around the arguments to predicates and functions, to requiring square brackets. So the relevant line of addLocal needs to be re-punctuated: add[b, b1, n, t] and n != n1 => lookup[b, n1] =...

It does look like it. If one replaces 'S' with 'univ', the expressions make sense and the Analyzer accepts the model.

Here is the solution to this problem ( I posted the question in mathematical notation in the math satck exchange here and got the solution ) I am converting it to Alloy. sig State {event : State} sig QArrow{ref: State -> State} fact { all q:univ | (q in QArrow...

sig A { b : set B } sig B {} sig Q { ab : A -> B }{ one ab } fact { b = Q.ab and #Q = #b } ...

I would express it as follows: signature fact : sig A{ rel: B->C }{ rel.C in B1 } or standalone fact: fact { rel[A].C in B1 } ...

In order to iterate over all the satisfiable solutions, you can simply loop over calls of the next() method on your A4Solution object, until the solution obtained is unsatisfiable (check with the satisfiable() method). You will have something like : A4Solution mySolution = TranslateAlloyToKodkod.execute_command(null, model.getAllReachableSigs(), cmd, new A4Options()); while(mySolution.satisfiable()){ mySolution=mySolution.next();...

There are three ways to assign a scope to your model. The first one is by assigning a scope to each signature of your model. e.g. : run ownGrandpa for 4 Person, 3 Name The second one is by giving a global scope that will be applied to all the...

In my previous answer I tried to address your "similarly between different signature" point, that is, I thought your main goal was to have a module that somehow enforces that there is a field named isA in the sig associated with parameter Q, and that isA is both injective and...

I don't know what that ord.als file is, but you should instead use the ordering library (ordering.als) that ships with Alloy. To access that file: click File -> Open Sample Models from main menu select util/ordering.als; to open it in your model, simply write open util/ordering[S] sig S {} ...