2017-12-19 6 views
1

食堂の哲学者の問題では、哲学者とフォークのテーブルがあります。合金の関係を構築する

P1 -> F1 
F1 -> P2 
P2 -> F2 
F2 -> P3 
P3 -> F3 
F3 -> P1 

すなわち:私はテーブルを表し、次の関係を望んでこの問題については

sig P {} 
sig F {} 

各PはFを指し、各FはPを指し、これは円を形成する。私はこの関係を取得するための関数を呼び出すしたいと思います:

fun table : (P+F) one -> one (P+F) { ... }   

私はこの仕事をするために努力してきたが、私はまた私が午前他の問題に関連しているという根本的な何かが欠けていますようにそれは感じています。どういうわけか私は 'コンストラクター'が欠けています。

任意のポインタ?

追加

@Hovercouchは、ヘルパーsigとワーキング溶液を得ました。しかし、これにはPとFの非自然拡張が必要で、新しいsigが導入されました。非天然の継承の問題に対処

sig P, F {} 
one sig Table { 
    setting : (P+F) one -> one (P+F) 
} { 
    # P = # F 
    all p : P, f : F | P in p.^setting and F in f.^setting 
} 
run {} for 6 

:これもによって解決することができます。

しかし、それはまだ非常にグローバルな問題と非常に単純な問題のために多くの仕事のようです。他のソリューションがあるかどうかを確認するために質問を開いたままにします。

答えて

2

あなたはヘルパーオブジェクトを追加するために喜んでいる場合は、我々はabstract sig Thingを作り、その後、ThingのPとFの両方のインスタンス作成することによってこれを行うことができますがあるかもしれません

abstract sig Thing { 
    next: Thing 
} { 
    Thing = this.^@next 
} 

sig F extends Thing {} { 
    next in P 
} 

sig P extends Thing {} { 
    next in F 
} 

fact SameNumberOfThings { 
    #P = #F 
} 

run {} for 6 

What it looks like

+0

ありがとう、良い解決策。しかし、私のコードにはたくさんの不動産が必要ですか?また、PおよびFに対して非自然拡張を必要とする。彼らの次の性格はテーブル設定の側面であり、PやFの側面ではありません。(OOではこれはコードの悪臭です) –

1

を表現力と扱いやすさとの間のデザイントレードオフ。

何がきれいで直感的であるかという問題は確かにあります。 PとFの「次の」性格は「テーブルの設定の一面」であり、「PやFの側面」ではないと言います。私はあなたの考えを理解していると思っていますが、PとFの「側面」とそれらが現れる領域との関係を区別するための原則的な方法を定義することで、それ以上の成功はないと思います。最後の数千年間、エッセンスと信憑性を確実に区別することを試みた哲学者たち。

そして、この区別は信頼できないが、それでもそれが有用であると認められるならば、問題は「署名の一部として定義される関係が個人の(本質的な)側面に関係しなければならない個人の側面ではない外的関係に関与しているのではないか」答えは、あなたがした、[合金の作成者]ではありませんでした。もし何かを表現するために使用しようとしている構造に関する直感を強く主張するなら、その表現が表現可能であるべきではなく、特定の構造を用いてそれを表現できるべきであると主張するリスクがある。そのような主張は、私たちに表記法について多くのことを教えてくれるかもしれませんが、表記のデザイナーも直感を持っていたということを受け入れる方が簡単です。

この一般的なトピックは、合金が宣言自立できるようにしてい質問の下ダニエル・ジャクソンのソフトウェア抽象で議論されていますか?(高次定量化のセクション3.5.3に続く議論の中で)およびすべての関係はフィールドとして宣言されなければならないか?(基本的なフィールド宣言のセクション4.2.2に続く議論の中で)。ディスカッションのナットは「既存のシグネチャに自然に属していないリレーションシップを宣言したい場合は、シングルトンシグネチャのフィールドとして宣言できます。」 Mutatis mutandis、与えられた例は、あなたの付録のTable sigをたくさん見ます。

TL;はい、ちょっと面倒なことがあるかもしれませんが、最初のメンバーに定義したくないリレーションシップを含むシングルトンsigは、実際に確立されたイディオムに近いです一種のもの。

+0

「ツールと戦わないでください」と言いますか?その感情に同意し、人々が責任を負っているツールを何かに変えようとすると、それを議論として使うことがよくあります。しかし、私はDanielと協力して、GithubでAlloytoolsを作成しました。私の目標は、Java開発者や一般的なオブジェクト指向設計でAlloyを有用にすることができるかどうかを確認することです。キーには読みやすさがあります。合金は今まで私が見つけた最高のものですが、まだ完璧であるとは思っていません。広範な答えbtw、ありがとう、ありがとう。 –

+0

私は「ツールと戦わないでください」と思っています。もちろん、そのルールが適用されない状況もあります。あなたは1つにいるかもしれません。 –

関連する問題