Значение ключевого слова «частное» в Alloy? Значение объявления enum?

грамматика Alloy 4 позволяет объявлениям подписи (и некоторым другим вещам) нести ключевое слово private. Это также позволяет разрешать спецификации содержать объявления перечисления в форме

enum nephews { hughie, louis, dewey }
enum ducks { donald, daisy, scrooge, nephews }

Справочник по языку не содержит (насколько насколько я могу судить) описывают значение либо ключевого слова private, либо конструкции enum.

Имеется ли документация? Или они присутствуют в грамматике как конструкции, зарезервированные для будущей спецификации?


person C. M. Sperberg-McQueen    schedule 16.08.2012    source источник


Ответы (2)


Это мое неофициальное понимание этих двух ключевых слов.

enum nephews { hughie, louis, dewey }

семантически эквивалентен

open util/ordering[nephews] as nephewsOrd

abstract sig nephews {}

one sig hughie extends nephews {}
one sig louis extends nephews {}
one sig dewey extends nephews {}

fact {
  nephewsOrd/first = hughie
  nephewsOrd/next = hughie -> louis + louis -> dewey
}

Ключевое слово private означает, что если сигнал имеет атрибут private, его метка является частной в пределах того же модуля. То же самое относится к приватным полям и приватным функциям.

person Aleksandar Milicevic    schedule 16.08.2012
comment
Спасибо; это полезно. Полагаю, из этого следует, что использование одного и того же имени как в перечислении, так и в качестве имени другого перечисления было бы ошибкой. (Ну, это легко проверить, почему я спрашиваю, когда я сам могу это выяснить? -- да, Alloy 4.2RC помечает это как ошибку. Хорошо, еще раз спасибо.) - person C. M. Sperberg-McQueen; 17.08.2012
comment
Я также вижу, что private задокументирован на alloy.mit.edu/alloy/documentation/ краткое руководство/private.html - person C. M. Sperberg-McQueen; 17.08.2012

В дополнение к предыдущему принятому ответу я хотел бы добавить некоторые полезные идеи, полученные в результате недельного опыта работы с Alloy на enums, в частности об основных отличиях от стандартного sig.

Если вы используете abstract sig + extend, вы получите модель, в которой есть много наборов, соответствующих одному и тому же понятию. Может быть, пример мог бы прояснить это лучше. Предположим, что-то вроде

sig Car {
    dameges: set Damage
}

У вас есть возможность использовать

abstract sig Damage {}
sig MajorDamage, MinorDamage extends Damage {}

vs

enum Damage {
    MajorDamage, MinorDamage
}

В первом случае мы можем придумать модель с разными атомами MinorDamage (MinorDamage0, MinorDamage1, ...), связанными с автомобилями, а во втором случае у вас всегда будет только один MinorDamage, на который могут ссылаться разные автомобили.

В этом случае может иметь смысл использовать форму abstract sig + extend (поскольку вы можете решить отслеживать разные элементы MinorDamage или MajorDamage).

С другой стороны, если вы хотите иметь currentState: set State, лучше использовать

enum State {Damaged, Parked, Driven}

чтобы сопоставить концепцию, чтобы иметь ровно три State, к которым может относиться каждый Car. Таким образом, в Visualizer вы можете спроецировать свою модель ровно на одно из состояний, и она выделит все Car, связанные с этим состоянием. Конечно, вы не можете сделать это с конструкцией abstract + extend, потому что проецирование на MajorDamage0 выделит только Car, связанное с этим Damage, и ничего больше.

Итак, в заключение, это действительно зависит от того, что вы должны делать.

Кроме того, имейте в виду, что если у вас есть перечисление, состоящее из X элементов, и выполните

run some_predicate for Y

где Y ‹ X, Alloy вообще не создает экземпляров. Итак, в нашем последнем примере у нас не может быть Y ‹ 3.

И последнее замечание: перечисления не всегда появляются в визуализаторе, если вы используете кнопку Magic Layout, но, как я уже говорил ранее, вы можете «проецировать» свою модель на перечисление и переключаться между различными элементами перечисления.

person tigerjack89    schedule 06.11.2016