確認 - scala 型変換



Scalaコンパイラにとって特別な型は何ですか? (1)

コンパイラには「知られている」タイプがあり、さまざまな程度で特別です。 あなたはスカラックのDefinitions.scalaで完全なリストを見つけることができます。

おそらく彼らが持つ専門性の程度に応じてそれらを分類することができます。

免責事項:私はおそらくもう少し忘れてしまったでしょう。

タイプシステムのための特別な

Scalaの型システムにとっては、以下の型が重要です。 それらは型チェック自体がどのように行われるかに影響します。 これらのタイプはすべて仕様書に記載されています(少なくとも、間違いなく)。

  • AnyAnyRefAnyValNullNothing :Scalaの型システムの上部と下部にある5つの型。
  • scala.FunctionNは、匿名関数(η拡張を含む)を与えられた(正規の)型です。 匿名関数のSAM処理を持つ2.12であっても、 FunctionNは、いくつかの場合(特に、オーバーロードの解像度で)、特別なままです。
  • scala.PartialFunction (型推論の仕組みに影響を与えます)
  • Unit
  • リテラル表記のすべての型: IntLongFloatDoubleCharBooleanStringSymboljava.lang.Class
  • 弱い適合のためのすべての数値プリミティブ型とChar s(これらの2つの箇条書きは全てのプリミティブ型をカバーする)
  • Optionとタプル(パターンマッチングとオートチューリング用)
  • java.lang.Throwable
  • scala.Dynamic
  • scala.Singleton
  • scala.reflect.*ほとんど、特にClassTagTypeTagなど
  • scala.annotation.{,ClassFile,Static}Annotation
  • scala.annotation.*注釈のほとんどすべて( scala.annotation.* unchecked
  • scala.language.*
  • scala.math.ScalaNumber (あいまいな理由による)

コンパイラに知られているいくつかの言語機能のdesugaringとして

以下の型は、型システムにとって重要ではありません。 彼らは型チェックに影響を与えません。 しかし、Scala言語には、これらの型の表現に賛成するいくつかの構造があります。

これらのタイプは、本明細書でも言及される。

  • scala.collection.SeqNilWrappedArrayはvarargsパラメータに使用されます。
  • TupleN
  • ProductSerializable (ケースクラス用)
  • MatchError 、パターンマッチングコンストラクトによって生成される
  • scala.xml.*
  • scala.DelayedInit
  • List (コンパイラはList()Nilとして書き直すなど、それらに対して些細な最適化を実行します)

言語の実装に知られている

さまざまなバックエンドで何が異なるかを知ることに興味があったとすれば、これはおそらくあなたが気にするリストです。 前のカテゴリはコンパイラの初期(フロントエンド)段階で処理されるため、Scala / JVM、Scala.js、Scala Nativeで共有されます。 このカテゴリは、通常、コンパイラのバックエンドで知られているため、潜在的に異なる処理方法があります。 Scala.jsとScala Nativeの両方が、Scala / JVMのセマンティクスを妥当な程度に模倣しようとしていることに注意してください。

これらの型は、言語仕様そのものには言及されていないかもしれません。

バックエンドが同意するもの(私の知る限りでは、Scala Nativeです):

  • すべてのプリミティブ型: BooleanCharByteShortIntLongFloatDoubleUnit
  • scala.Array
  • Cloneable (Scala Nativeでは現在サポートされていません、 #334参照)
  • StringStringBuilder (主に文字列連結用)
  • Object 、事実上すべてのメソッド

そして、ここに彼らが同意しないところがあります:

  • プリミティブ型のボックス版( java.lang.Integerなど)
  • Serializable
  • java.rmi.Remoteおよびjava.rmi.RemoteException
  • scala.annotation.*注釈(例: strictfp
  • Scala / JVMが構造型を実装するために使用するjava.lang.reflect.*もの

また、 自体ではありませんが、基本的なメソッドの長いリストもバックエンドによって特別に扱われます。

プラットフォーム固有の型

すべてのプラットフォームで使用可能な上記のタイプに加えて、非JVMプラットフォームは相互運用性のために独自の特殊タイプを追加します。

Scala.js固有の型

JSDefinitions.scala参照してくださいJSDefinitions.scala

  • js.AnyAnyValAnyRef他に概念的にAny第3のサブタイプ。 Scalaのセマンティクスの代わりにJavaScriptセマンティクスを持っています。
  • Stringとすべてのプリミティブ型のボックス化されたバージョン(ひどく書き直されました - いわゆる "ハイジャック" - コンパイラによって)
  • js.ThisFunctionN :それらのapplyメソッドは、他のJavaScriptタイプとは異なる動作をします(最初の実際の引数は呼び出される関数のthisArgumentになります)
  • js.UndefOrjs.|js.Any拡張していなくてもJS型として動作します)
  • js.Objectnew js.Object()は空のJSオブジェクトリテラル{}として特別にnew js.Object()れます)
  • js.JavaScriptExceptionthrowcatchで非常に特別に動作する)
  • js.WrappedArray (varargsのdesugaringによって使用される)
  • js.ConstructorTagjs.ConstructorTag似ていClassTag
  • アノテーションjs.native 、およびjs.annotation.*すべてのアノテーション

プラス、十数のより原始的な方法

Scalaネイティブ固有の型

NirDefinitions.scala参照してくださいNirDefinitions.scala

  • 符号なし整数: UByteUShortUIntULong
  • Ptr 、ポインタ型
  • FunctionPtrN 、関数ポインタ型
  • native.*のアノテーションnative.*
  • scala.scalanative.runtimeいくつかの追加のプリミティブメソッド

Scalaは、言語機能のように見えるものがライブラリ機能としてどのように実装されているかについて大きな問題に取り組んでいます。

言語によって特別に扱われるタイプのリストはありますか?

仕様または実装の詳細のいずれか?

これには、例えば、タプルに対するマッチの最適化が含まれます。

どのようなパターンマッチングに関連する特別な慣習は、理解、try - catchブロックや他の言語の構造ですか?

ストリングはコンパイラにとって何となく特別ですか? 私は、文字列の拡張は単にライブラリの暗黙的な変換であり、その文字列の連結はPredefによってサポートされていPredef 、それは何らかの形で言語によって特殊化されていますか?

同様に、私は<:<<:<classOfasInstanceOfについての質問を見ていますが、何が魔法の本質的なものであるかははっきりしていません。 違いを伝える方法はありますか?コンパイラオプションを使うかバイトコードを調べますか?

Scala.JSやScala-nativeなどの実装で機能が一様にサポートされているかどうか、あるいはライブラリ実装によっては実装が実際に実装されている可能性があるかどうかを理解したいと思います。





scala