7

型クラスに関するフレーゲの考え方は、Haskellとは大きく異なるようです。特に：

  • 明らかな理由もなく、構文が異なっているように見えます。

  • 関数型はクラスインスタンスを持つことはできません。（かなり奇妙なルールのようです...）

  • 言語仕様は、サブクラスインスタンス宣言にスーパークラスを実装することについて何かを述べています。（ただし、ダイヤモンドの継承がある場合はそうではありません...エラーにはなりませんが、何らかの形で機能することが保証されているわけではありませんか？）

  • Fregeは、インスタンスがどのように見えるかについてあまり煩わしくありません。（型エイリアスは許可され、型変数は区別する必要はありませんなど）

  • メソッドはとして宣言できますがnative、これの意味が完全には明確ではありません。

  • type.methodメソッドにアクセスするために書くことができるようです。繰り返しますが、これが何を意味するのか、なぜそれが有用なのかについては何も示されていません。

  • サブクラス宣言は、スーパークラスメソッドのデフォルトの実装を提供できます。（？）

要するに、このようなものを知っている誰かがこのようなものがどのように機能するかについての説明を書くことができれば便利でしょう。言語仕様に記載されていますが、説明は少し簡潔です。

（構文に関して：Haskellのインスタンス構文はより論理的だと思います。「XがYとZのインスタンスである場合、次のようにQのインスタンスでもあります...」Haskellのクラス構文は常に少し奇妙に見えますXが実装する場合、それはそれが実装することを意味するEqのではなく、必要に応じて実装できることを意味します。しかし、より良いシンボルが何であるかはわかりません...）OrdOrd

インゴの答えによると：

  • スーパークラスメソッドのデフォルトの実装を提供することは、インスタンスを「一度に」宣言した場合にのみ機能すると思いますか？

たとえば、FooがのスーパークラスであるとしBarます。各クラスに3つのメソッド（、、、、、、）があり、のfoo1デフォルトfoo2の実装を提供するfoo3とします。それはそれを意味するはずですbar1bar2bar3Barfoo1

インスタンスバーFBここで
  foo2=..。
  foo3=..。
  bar1=..。
  bar2=..。
  bar3=..。

動作するはずです。しかし、これはうまくいくでしょうか：

インスタンスFooFBここで
  foo2=..。
  foo3=..。

インスタンスバーFBここで
  bar1=..。
  bar2=..。
  bar3=..。
  • それでnative、クラス宣言のようにメソッドを宣言すると、そのメソッドのデフォルトの実装が設定されるだけですか？

だから私が何かをするなら

クラスFoobarfここで
  foo :: f-> Int
  ネイティブfoo

  バー::f->文字列
  ネイティブバー

つまり、Javaネイティブクラスの空のインスタンス宣言を記述した場合、 Javaでfooマップするということobject.foo()です。

特に、クラスメソッドがとして宣言されている場合でも、必要に応じて他の実装をnative提供できますか？

  • すべての型[コンストラクター]は名前空間です。それが悪名高い名前付きフィールドの問題にどのように役立つかがわかります。この名前空間のスコープで他のものを宣言したい理由がわかりません...
4

1 に答える 1

6

あなたは言語仕様を非常に注意深く読んだようです。素晴らしい。しかし、いいえ、型クラス/インスタンスはHaskell 2010と実質的に違いはありません。ほんの少し、そしてそのビットは表記法です。

あなたのポイント：

広告1.はい。ルールは、制約がある場合はタイプに付加され、クラス名はキーワードの後に​​続くというものです。しかし、マルチパラメータ型クラスが言語に追加されると、これはHaskell構文を支持してすぐに変更されます。

ad 2.一方、関数型は完全にサポートされています。これは次のリリースに含まれる予定です。ただし、現在のリリースでは（a-> b）のみがサポートされています。

広告3.はい。カテゴリクラスの階層Functor->Applicative->Monadについて考えてみます。3つの別々のインスタンスの代わりに、次のように書くことができます。

instance Monad Foo where
    -- implementation of all methods that are due Monad, Applicative, Functor

ad 4.はい、現在。ただし、マルチパラメータ型クラスでは変更があります。lang仕様では、Haskell2010のルールを維持することを推奨しています。

ad 5.型クラスを使用してJavaクラス階層をモデル化する場合は、これが必要になります。ネイティブ関数の宣言は、型クラス/インスタンスにとって特別なことではありません。クラスにアノテーションとデフォルトの実装を含めることができるため（Haskell 2010の場合と同様）、これをネイティブ宣言の形式で含めることができます。これにより、a）タイプとb）実装（ Javaメソッド）。

ad6.それは直交性です。MがモジュールであるM.fooを記述できるのと同じように、Tが型（コンストラクター）の場合は両方とも名前空間であるため、T.fooを記述できます。さらに、「レコード」がある場合T.f x、フレーゲがのタイプを推測できないときに書き込む必要があるかもしれませんx。

foo x = x.a + x.b    -- this doesn't work, type of x is unknown
-- remedy 1: provide a type signature
foo :: Record -> Int  -- Record being some data type
-- remedy 2: access the field getter functions directly
foo x = Record.a x + Record.b x

ad 7.はい、たとえば、Ordには、比較に関して（==）のデフォルトの実装があります。したがって、実装せずに何かのOrdインスタンスを作成できます（==）。

お役に立てれば。一般的に、lang仕様にはa）完了とb）更新が必要であると言わなければなりません。その日だけが36時間だったら.....

構文の問題についてもここで説明します：https ：//groups.google.com/forum/？fromgroups＃！topic / frege-programming-language / 2mCNWMVg5eY

----第2部------------

instance Foo FB他のインスタンスやサブクラスに関係なく、これを定義する必要があるため、この例は機能しません。Barのデフォルトのfoo1メソッドは、Fooインスタンスが存在しない場合にのみ使用されます。

つまり、Javaネイティブクラスの空のインスタンス宣言を記述した場合、fooはJavaのobject.foo（）にマップされますか？

はい。ただし、ネイティブ宣言によって異なります。そのJavaクラスのJavaインスタンスメソッドである必要はありません。静的メソッドや別のクラスのメソッド、または単なるメンバーアクセスなどでもかまいません。

特に、クラスメソッドがネイティブとして宣言されている場合でも、必要に応じて他の実装を提供できますか？

もちろん、他のデフォルトのクラスメソッドと同じように。デフォルトのクラスメソッドがパターンガードを使用して実装されているとしましょう。これは、実装にパターンガードを使用する必要があるという意味ではありません。

見て、

native [pure] foo "javaspec" :: a -> b -> c

つまり、実装にjavaspecfooを使用するタイプa->b->cのfrege関数を作成してください。（言語リファレンスの第6章でどの程度正確に説明されているはずです。まだ完了していません。申し訳ありません。）例：

native pure int2long "(long)" :: Int -> Long

コンパイラーは、これが構文的にキャスト操作であると認識し、次のことを認識します。

 ... int2long val ...

次のようなJavaコードが生成されます。

((long)(unbox(val))

それとは別に、ラッパーも作成されるため、たとえば次のことができます。

map int2long [1,2,4]

重要なのは、私が言うと、関数XYzがある場合、ソースコードを見ないと、これがネイティブなのか通常の関数なのかを判断できないということです。したがって、nativeJavaメソッド、演算子などをFregeレルムに持ち上げる方法です。事実上、Haskellで「primOp」として知られているものはすべて、Fregeのネイティブ関数にすぎません。例えば、

pure native + :: Int -> Int -> Int

（もちろん、それは必ずしも簡単ではありません。）

すべての型[コンストラクター]は名前空間です。それが悪名高い名前付きフィールドの問題にどのように役立つかがわかります。この名前空間のスコープで他のものを宣言したい理由がわかりません...

これにより、最上位の名前空間に関する制御がいくらか向上します。それとは別に、そこに他のものを定義する必要はありません。レコードフィールドの問題に取り組むためのこの単純なアプローチにコミットした後は、それを禁止する理由がわかりませんでした。

于 2012-05-10T10:29:38.780 に答える