As in the following code, is there any way to make macros for the expressions NP + NF2 + NF1 + NT + NR and AnonActive + Aactive + AsetTurn + Astart + Acrit + Acheck + APF2 + APF1 + ATP + ATR + AF2R + AF1R, so that I can refer to them later by name rather than writing the expressions out directly?
sig NP{}
sig NF2{}
sig NF1{}
sig NT{}
sig NR{}
sig AnonActive{src:one NP, trg:one NP}
sig Aactive{src:one NP, trg:one NP}
sig AsetTurn{src:one NP, trg:one NP}
sig Astart{src:one NP, trg:one NP}
sig Acrit{src:one NP, trg:one NP}
sig Acheck{src:one NP, trg:one NP}
sig APF2{src:one NP, trg:one NF2}
sig APF1{src:one NP, trg:one NF1}
sig ATP{src:one NT, trg:one NP}
sig ATR{src:one NT, trg:one NR}
sig AF2R{src:one NF2, trg:one NR}
sig AF1R{src:one NF1, trg:one NR}
sig Graph{nodes:set NP+NF2+NF1+NT+NR,
arrows:set AnonActive + Aactive + AsetTurn + Astart
+ Acrit + Acheck + APF2 + APF1 + ATP + ATR
+ AF2R + AF1R}
One simple way would be to declare abstract signatures Node and Arrow, and declare each of your existing signatures as extending one or the other of them.
abstract sig Node {}
sig NP extends Node {}
sig NF2 extends Node {}
...
Since all your arrows have the same relations, the relations can be declared in the Arrow sig; the restrictions on the kinds of nodes allowed as source and target can be given using signature facts, as for example:
abstract sig Arrow {
src: one Node,
trg: one Node
}
sig AnonActive extends Arrow {}{
one + trg in NP
}
...
sig AF1R extends Arrow {}{
src in NF1
trg in NR
}
Now the declaration of Graph is quite simple (and, at least to some eyes, perhaps a bit clearer):
sig Graph {
nodes: set Node,
arrows: set Arrow
}
Another approach (less good in the case shown, I think, but useful in cases where the first approach cannot be applied) would be to define functions with the appropriate names:
fun Node : set univ {
NP + NF2 + NF1 + NT + NR
}
fun Arrow : set univ {
AnonActive + Aactive + AsetTurn + Astart
+ Acrit + Acheck + APF2 + APF1 + ATP + ATR
+ AF2R + AF1R
}
N.B. I have not checked these for syntax errors ...
Related
I have the following def. in Alloy:
sig A {b : set B}
sig B{}
sig Q {s: A , t: B}
I want to add a set of constraints such that for each relation b1:b there exists one and only one Q1:Q where Q1.s and Q1.t refers to the source and target of b1, respectively. For example, if I have an instance which contains A1 and B1 and b1 connects them (i.e., b1: A1->B1), then I also would like to have a Q1 where Q1.s=A1 and Q1.t=B1.
Obviously number (cardinality) of Q is equal to number (cardinality) of b relation.
I managed to write such a constraint as bellow:
t in s.b
all q1,q2:Q | q1.s=q2.s and q1.t=q2.t => q1=q2
all a1:A,b1:B | a1->b1 in b => some q:Q | q.s=a1 and q.t=b1
I am wondering if anyone has a bit more concise way to express my intentions in terms of an alloy fact. I am open to use Alloy util package if it makes life easier.
Thanks
sig A { b : set B }
sig B {}
sig Q { ab : A -> B }{ one ab }
fact { b = Q.ab and #Q = #b }
I would complete the #user1513683 answer by adding two relations s and t to make it the complete answer to the question:
sig A { b : set B }
sig B {}
sig Q { ab : A -> B , s:A, t:B}{ one ab and t=ab[s]}
fact { b = Q.ab and #Q = #b }
How do I write a predicate to check for a Horizontal, vertical or diagonal wins for a tictactoe game in Alloy? I'm kind of struggling with the syntax below is my code:
open util/ordering [Time] as T
sig Time {}
abstract sig Game {
turn, winner, loser: Game
}
abstract sig Player {
opponent:Player
}
sig X extends Player {}
sig O extends Player {}
fact {
all t:Time| all p: Player | no p.opponent
all t: Time | all p: Player | all g:Game | one g.turn
all t:Time | all g:Game | one g.winner & g.loser
}
pred HorizontalWin {
}
I think your model might not be appropriate for this game. For example, I don't see a 3x3 grid in your model, so it is not clear how to express any property about the state of the game.
There are several other issues with your model. For example, the Game sig is abstract and it has no concrete subsigs, so instances of this model can never contain any games (thus turn, winner, and loser fields will always be empty as well). Also, you probably want to use the Time signature somewhere (either put some fields in it, or make other fields use it, e.g., turn: Player -> Time) and then add some facts about every two consecutive time steps to properly connect the game moves. Here is an idea:
open util/ordering [Move] as M
abstract sig Player {}
one sig X, O extends Player {}
abstract sig Cell {}
one sig C00, C01, C02, C10, C11, C12, C20, C21, C22 extends Cell {}
sig Board {
grid: Cell -> lone Player
}
sig Move {
player: Player,
pos: Cell,
board, board': Board // pre and post board
} {
// must choose an empty grid cell
no board.grid[pos]
// set the `pos` cell to `player`
board'.grid[pos] = player
// all other grid cells remain the same
all c: Cell - pos | board'.grid[c] = board.grid[c]
}
fact {
// empty board at the beginning
no M/first.board.grid
all m: Move {
some M/next[m] => {
// alternate players each move
M/next[m].player != m.player
// connect boards
M/next[m].board = m.board'
}
}
}
run {} for 9 but 10 Board
I have an Alloy module
module WorkPlace
sig String{}
sig person{}
sig Employee extends person{
name :String, boss: Employee,worker: set Employee}
sig Employee1 extends person{
name :String, boss: Employee,worker: set Employee}
fact Employee{
all e1:Employee, e2:Employee| (e1.name = e2 && e2.name = e1) =>e1 = e2}
run{}
when i triad to run this mode it give me this massage :
"Syntax error at line 2 column 5:
There are 3 possible tokens that can appear here:
NAME seq this "
I don't know what its mean?
2\ If I have 2 Alloy models ,each model has same element i.e mode1/name, model2/name. how can I create a fact or pred which can say mode1/name = model2/name?
regards
As user1513683 already answered:
"String" is a reserved word. Use "string" instead (or, better, "Name")
You can open an existing module from another module, and then in that module you can use all sigs/relations present in any of the two modules. For example:
module 1 (file m1.als):
module m1
sig S1 {}
module 2 (file m2.als):
module m2
open m1
sig S2 {}
run { #S1 = #S2 }
Given the below definition:
sig Name,Addr{}
sig Book{ addr : Name -> some Addr}
Let Name = { (J),(t), (b)}
Addr = {(1), (2)}
Book = {(bb0)}
I was curious that in the relation addr : Name -> some Addr, what is the multiplicity of the Name in the second column. Moreover, is the below possible
addr = {(bbo, j , 1), (bb0, j, 2)}
I trying to learn if j can occur more than once in the second column
The short answer is yes, but I only figured it out by trying, you have to define your model properly though:
abstract sig Name,Addr{}
abstract sig Book{ addr : Name -> some Addr}
one sig J,t,b extends Name {}
one sig a1,a2 extends Addr {}
one sig bb0 extends Book {}
run { #addr > 3 } for 4 int
Execute it and use the evaluator to evaluate addr you will see that it contains more than 3 elements, two of which have the same Name atom.
I know the use of predicates in alloy but i was a little surprised by the below description:
pred locationConstraint(loc: Int -> Int){
loc in (Int[0] + Int[1] + Int[2] + Int[3] + Int[4] + Int[5] + Int[6]) -> (Int[2] + Int[3])
+ (Int[2] + Int[3]) -> (Int[0] + Int[1] + Int[2] + Int[3] + Int[4] + Int[5])
}
Can someone please explain the above to me.
Add run {} to your model, and type {x,y:Int | locationConstraint[x->y]} into the evaluator to get the result: