Quels sont les types spécifiques au compilateur Scala ?

Question

Scala fait grand cas de la façon dont ce qui semble être des caractéristiques du langage est mis en œuvre en tant que caractéristiques de la bibliothèque.

Existe-t-il une liste de types traités de manière particulière par le langage ?

Soit dans la spécification, soit en tant que détail de mise en œuvre ?

Il s'agirait, par exemple, d'optimiser les correspondances éloignées sur les tuples.

Qu'en est-il des conventions spéciales liées à la correspondance des motifs, aux compréhensions, aux blocs try-catch et à d'autres constructions linguistiques ?

Est-ce que String est quelque chose de spécial pour le compilateur ? Je vois que l'amélioration de String est juste une conversion implicite de la bibliothèque, et que la concaténation de String est supportée par Predef Mais est-ce un cas particulier de la langue ?

De même, je vois des questions sur <:< y classOf y asInstanceOf et on ne sait pas très bien ce qu'est un intrinsèque magique. Existe-t-il un moyen de faire la différence, soit avec une option du compilateur, soit en regardant le code des octets ?

J'aimerais savoir si une fonctionnalité est supportée uniformément par des implémentations telles que Scala.JS et Scala-native, ou si une fonctionnalité peut s'avérer dépendante de l'implémentation, en fonction de l'implémentation de la bibliothèque.

Answer 1

Il existe une quantité incroyable de types qui sont "connus" du compilateur et qui sont spéciaux à des degrés divers. Vous pouvez en trouver une liste complète dans la section Définitions.scala .

On peut probablement les classer en fonction du degré de spécialisation qu'ils présentent.

Avertissement : j'en ai probablement oublié d'autres.

Spécial pour le système de type

Les types suivants sont essentiels au système de types de Scala. Ils ont une influence sur la manière dont la vérification des types est effectuée. Tous ces types sont mentionnés dans la spécification (ou du moins, ils devraient l'être).

• Any , AnyRef , AnyVal , Null , Nothing : les cinq types qui se trouvent en haut et en bas du système de types de Scala.
• scala.FunctionN le type (canonique) donné des fonctions anonymes (y compris l'expansion eta). Même en 2.12, qui traite les fonctions anonymes avec SAM, FunctionN reste spécial dans certains cas (notamment dans la résolution des surcharges).
• scala.PartialFunction (a un impact sur le fonctionnement de l'inférence de type)
• Unit
• Tous les types avec notation littérale : Int , Long , Float , Double , Char , Boolean , String , Symbol , java.lang.Class
• Tous les types primitifs numériques et les Char pour une conformité faible (ensemble, ces deux puces couvrent tous les types primitifs)
• Option et tuples (pour la recherche de motifs et l'auto-tuplage)
• java.lang.Throwable
• scala.Dynamic
• scala.Singleton
• La plupart des scala.reflect.* et en particulier ClassTag , TypeTag , etc.
• scala.annotation.{,ClassFile,Static}Annotation
• La quasi-totalité des annotations dans les scala.annotation.* (par exemple, unchecked )
• scala.language.*
• scala.math.ScalaNumber (pour des raisons obscures)

Connu par le compilateur comme le désucrage de certaines caractéristiques du langage

Les types suivants ne sont pas essentiels au système des types. Ils n'ont pas d'influence sur la vérification des types. Cependant, le langage Scala comporte un certain nombre de constructions qui se désugarisent en expressions de ces types.

Ces types seront également mentionnés dans le cahier des charges.

• scala.collection.Seq , Nil y WrappedArray qui sont utilisés pour les paramètres varargs.
• TupleN types
• Product y Serializable (pour les classes de cas)
• MatchError , générés par des constructions de type "pattern matching" (recherche de motifs)
• scala.xml.*
• scala.DelayedInit
• List (le compilateur effectue quelques optimisations triviales sur ces derniers, comme la réécriture de List() como Nil )

Connu de la mise en œuvre de la langue

C'est probablement la liste qui vous intéresse le plus, étant donné que vous avez dit que vous vouliez savoir ce qui pouvait se passer différemment sur différents back-ends. Les catégories précédentes sont gérées par les premières phases (frontales) du compilateur, et sont donc partagées par Scala/JVM, Scala.js et Scala Native. Cette catégorie est typiquement connue du back-end du compilateur, et peut donc être traitée différemment. Notez que Scala.js et Scala Native tentent d'imiter la sémantique de Scala/JVM dans une mesure raisonnable.

Ces types peuvent ne pas être mentionnés dans la spécification du langage en tant que telle, du moins pas tous.

Voici ceux pour lesquels les back-ends sont d'accord (pour Scala Native, à ma connaissance) :

• Tous les types primitifs : Boolean , Char , Byte , Short , Int , Long , Float , Double , Unit .
• scala.Array .
• Cloneable (actuellement non supporté dans Scala Native, voir #334 )
• String y StringBuilder (principalement pour la concaténation de chaînes de caractères)
• Object pour la quasi-totalité de ses méthodes

Et voici les points sur lesquels ils sont en désaccord :

• Les versions encadrées des types primitifs (tels que les java.lang.Integer )
• Serializable
• java.rmi.Remote y java.rmi.RemoteException
• Certaines annotations dans scala.annotation.* (par exemple, strictfp )
• Quelques éléments dans java.lang.reflect.* utilisé par Scala/JVM pour implémenter les types structurels

En outre, bien que n'étant pas types en soi, mais une longue liste de méthodes primitives sont également gérées de manière spécifique par les back-ends.

Types spécifiques à la plate-forme

Outre les types mentionnés ci-dessus, qui sont disponibles sur toutes les plates-formes, les plates-formes non JVM ajoutent leurs propres types spéciaux à des fins d'interopérabilité.

Types spécifiques à Scala.js

Voir JSDefinitions.scala

• js.Any : conceptuellement un troisième sous-type de Any En outre AnyVal y AnyRef . Ils ont une sémantique JavaScript au lieu d'une sémantique Scala.
• String et les versions en boîte de tous les types primitifs (fortement réécrits - dits "détournés" - par le compilateur)
• js.ThisFunctionN : leur apply se comportent différemment de celles des autres types JavaScript (le premier argument réel devient la méthode thisArgument de la fonction appelée)
• js.UndefOr y js.| (ils se comportent comme des types JS même s'ils n'étendent pas les types js.Any )
• js.Object ( new js.Object() est considéré comme un objet JS littéral vide. {} )
• js.JavaScriptException (se comporte de manière très particulière en throw y catch )
• js.WrappedArray (utilisé par le désuglage des varargs)
• js.ConstructorTag (similaire à ClassTag )
• L'annotation js.native et toutes les annotations dans js.annotation.*

Plus une douzaine d'autres méthodes primitives .

Types spécifiques à Scala Native

Voir NirDefinitions.scala

• Entiers non signés : UByte , UShort , UInt y ULong
• Ptr , le type de pointeur
• FunctionPtrN les types de pointeurs de fonctions
• Les annotations dans native.*
• Un certain nombre de méthodes primitives supplémentaires dans scala.scalanative.runtime