Quelle est la différence entre “égal (=)” et “à l'identique (==)” en ocaml?

Edit: cette réponse se plonge dans les détails de l'intérieur de OCaml, basé sur la Obj module. Que la connaissance n'est pas destiné à être utilisé sans soin (permettez-moi l'accent sur ce point, très important, une fois de plus: ne l'utilisez pas pour votre programme, mais uniquement si vous le souhaitez expérience avec OCaml runtime). Cette information est également disponible, quoique peut-être dans une forme plus compréhensible dans le O'Reilly livre sur OCaml, disponible en ligne (assez bon livre, bien qu'un peu daté maintenant).

La = opérateur est la vérification de l'égalité structurelle, tandis que == ne vérifie la présence physique de l'égalité.

L'égalité de contrôle est basé sur la façon dont les valeurs sont attribuées et stockées dans la mémoire. Une valeur d'exécution en OCaml peut à peu près s'insérer dans 2 catégories différentes : soit boîte ou unboxed. L'ancien signifie que la valeur est accessible en mémoire par une indirection, et, plus tard, signifie que la valeur est directement accessible.

Depuis int (int31 sur les systèmes 32 bit, ou int63 sur les systèmes 64 bits) sont unboxed valeurs, les deux opérateurs se comportent de la même chose avec eux. Quelques autres types de valeurs, dont l'exécution des implémentations sont en fait int, sera également de voir les deux opérateurs se comportant avec eux, comme unité (), la liste vide [], des constantes dans algébrique de types et variantes polymorphes, etc.

Une fois que vous commencez à jouer avec plus de valeurs complexes impliquant des structures, comme les listes, les tableaux, les tuples, les enregistrements (C struct équivalent), la différence entre ces deux opérateurs se dégage: les valeurs au sein de structures qui vont être mis en boîte, sauf s'ils peuvent être d'exécution représentée en tant que natif ints (1). Cette nécessité découle de la façon dont le système d'exécution doit gérer des valeurs, et de gérer la mémoire de manière efficace. Structuré valeurs sont attribués lors de la construite à partir d'autres valeurs, qui peuvent être eux-mêmes structurés de valeurs, auquel cas les références sont utilisées (car ils sont en boîte).

Parce que des allocations, il est très peu probable que les deux valeurs instanciées à différents points d'un programme pourrait être égales sur le plan physique, bien qu'ils seraient structurellement l'égalité. Chacun des champs, ou des éléments internes au sein de l'valeurs peuvent être identiques, même jusqu'à l'identité physique, mais si ces deux valeurs sont construites dynamiquement, alors ils seraient à l'aide de différents espaces de la mémoire, et donc être physiquement différents, mais structurellement l'égalité.

L'exécution essaie d'éviter d'inutiles allocations de bien: par exemple, si vous avez une fonction retournant toujours la même valeur (en d'autres termes, si la fonction est constante), soit simple ou structurée, cette fonction retournera toujours la même valeur (c'est à dire, les mêmes données en mémoire), ainsi que des tests de physique de l'égalité à la suite de deux appels de cette fonction sera couronnée de succès.

Un moyen d'observer si l'opérateur fait retour true est d'utiliser le Obj.is_block fonction de son exécution de la représentation (C'est-à-dire, le résultat de Obj.repr). Cette fonction indique simplement si son paramètre d'exécution de la représentation est en boîte.

Un plus factice est d'utiliser la fonction suivante:

let phy x : int = Obj.magic (Obj.repr x);;

Cette fonction retournera un int qui est la valeur réelle de l'indicateur de la valeur liée à x dans la mémoire, si cette valeur est boîte. Si vous l'essayez sur une int littéral, vous obtiendrez exactement la même valeur! C'est parce que les int sont unboxed (ie. la valeur est stockée directement dans la mémoire, non pas grâce à une référence).

Maintenant que nous savons que boxed valeurs sont en fait des "référencé" valeurs", nous pouvons en déduire que ces valeurs peuvent être modifiées, même si le langage dit qu'ils sont immuables.

considérons par exemple le type de référence:

# type 'a ref = {mutable contents : 'a };;

Nous pourrions définir une immuable ref comme ceci:

# type 'a imm = {i : 'a };;
type 'a imm = {i : 'a; }

Et ensuite utiliser le Obj.magic fonction de forcer un type à l'autre, parce que structurellement, ces types de être réduit à la même exécution de la représentation.

Par exemple:

# let x = { i = 1 };;
- : val x : int imm = { i = 1 }
# let y : int ref = Obj.magic x;;
- : val y : int ref = { contents = 1 }
# y := 2;;
- : unit = ()
# x
- : int imm = { i = 2 }

Il y a quelques exceptions à cela:

• si les valeurs sont des objets, alors même apparemment structurellement identique valeurs de retour false sur la comparaison structurelle

  # let o1 = object end;;
  val o1 : < > = <obj>
  # let o2 = object end;;
  val o2 : < > = <obj>
  # o1 = o2;;
  - :  bool = false
  # o1 = o1;;
  - :  bool = true

  ici, nous voyons que = revient à l'équivalence physique.

• Si les valeurs sont des fonctions, vous ne pouvez pas les comparer structurellement, mais la comparaison fonctionne comme prévu.

• paresseux valeurs peuvent ou peuvent ne pas être structurellement comparables, selon qu'ils ont été forcés ou non (respectivement).

  # let l1 = lazy (40 + 2);;
  val l1 : lazy_t = <lazy>
  # let l2 = lazy (40 + 2);;
  val l2 : lazy_t = <lazy>
  # l1 = l2;;
  Exception: Invalid_argument "equal: functional value".
  # Lazy.force l1;;
  - :  int = 42
  # Lazy.force l2;;
  - :  int = 42
  # l1 = l2;;
  - :  bool = true 

• module ou d'enregistrer les valeurs sont comparables si elles ne contiennent pas de valeur fonctionnelle.

En général, je pense qu'il est sûr de dire que les valeurs qui sont liées à des fonctions ou peuvent avoir des fonctions à l'intérieur ne sont pas comparables avec =, mais peut être comparé avec ==.

Vous devez évidemment être très prudent avec tout ce: s'appuyer sur les détails de mise en œuvre de l'exécution est incorrect (Note: je blague utilisé le mot mal dans ma première version de cette réponse, mais modifiée par la peur d'être pris trop au sérieux). Comme vous l'avez justement souligné dans les commentaires, le comportement de l'javascript mise en œuvre est différente pour les flotteurs (structurellement équivalent en javascript, mais pas dans l'implémentation de référence, et ce sur le java?).

---

(1) Si je me souviens bien, les flotteurs sont aussi "unboxed" lorsqu'il est stocké dans tableaux pour éviter une double indirection, mais ils deviennent en boîte une fois extrait, vous ne devriez pas voir une différence de comportement avec boîte valeurs.

OriginalL'auteur didierc

selon http://rigaux.org/language-study/syntax-across-languages-per-language/OCaml.html, == vérifie peu profondes de l'égalité, et = vérifie la profondeur de l'égalité

OriginalL'auteur Sam I am