Caml/C - Page 2

C sux parce qu'il y a pas de garbage collection

C# ça poutrerait

Hippopotamu
: - Pourquoi? C'est au contraire une force!

- Comment pourrait il en être autrement? (sans abandonner la sécurité!)

Ca pourrait alléger la syntaxe, mais ça rajoute tellement de contraintes sur le langage (suffit de voir comme il est pourri) que j'en viens à me demander si le jeu en vaut vraiment la chandelle...

Depuis quand le typage statique ne peut se faire qu'avec un typage à la Caml

Hippopotamu
:

Ca pourrait alléger la syntaxe, mais ça rajoute tellement de contraintes sur le langage (suffit de voir comme il est pourri) que j'en viens à me demander si le jeu en vaut vraiment la chandelle...

- syntaxe mille fois plus légère, comme tu dis.

- abstraction propre et sécurité (le programmeur ne peut pas aller écrire un int là où il y a un float, ce qui serait tout de même atroce)

Ca ne rajoute pas la moindre contrainte, mais au contraire des avantages : propreté, sécurité.

Depuis quand le typage statique ne peut se faire qu'avec un typage à la Caml

Si tu veux un typage sûr et strict, il est inutile de se passer du typage auto puisque le typage manuel donnerait le même résultat.
Si tu veux un typage pas sûr ou pas strict, alors abandonne les langages d'3l33t comme le caml et va programmer en scilab, barbare!

Ah... Devoir mettre le nom du type devant chaque appel de fonction, c ça une syntaxe légère ?

Sally :
Le typage manuel est tout à fait possible en caml hein Pollux ^^
au lieu de let id x = x, tu peux écrire let id (x:int) = x, auquel cas tu obtiens une fonction de type int -> int au lieu de 'a -> 'a
et tu peux aussi forcer le type de ta fonction (auquel cas si jamais tu te goures dedans ça refusera de compiler au lieu de te donner un type qui n'est pas celui que tu voulais, ceci dit ce dernier cas est en général très facile à détecter, soit en balançant ta fonction dans le toplevel juste après l'avoir écrite, pratique recommandée ^^, et constatant qu'elle n'a pas le bon type, soit, même si tu le fais pas, à l'utilisation de la fonction très vraisemblablement... mais si tu préfères forcer, rien ne t'en empêche )

Euh sinon, c'est quoi les contraintes dont tu parles Le typage auto « rajoute tellement de contraintes sur le langage... »
Là je ne vois pas *du tout* de quoi il peut bien s'agir

On peut avoir un typage statique sans avoir de typage automatique, hein

Sally
: Mon post est invisible ?

Ah... Devoir mettre le nom du type devant chaque appel de fonction, c ça une syntaxe légère ?

tu parles de quel langage là ?

let ajouter a b =
  ajouter_superlongnomdetypeno1 (superlongnomdetypeno1_of_superlongnomdetypeno2 a) (superlongnomdetypeno1_of_superlongnomdetypeno2 b)

let somme_des_longueurs a b =
  a.superlongnomdetype_longueur + b.superlongnomdetype_longueur

le java, où tout te retourne des Object et faut caster après, c'est ça ?

de même que le fait qu'il y ait un typage automatique impose, par exemple, que les namespaces des records soit totalement disjoints [une aberration, entre nous soit dit ]

Sally
:

de même que le fait qu'il y ait un typage automatique impose, par exemple, que les namespaces des records soit totalement disjoints [une aberration, entre nous soit dit ]

Euh, certes... les objets n'ont pas cette contrainte-là, pour les records je ne sais pas du tout s'ils ont l'intention de la retirer (en fait je ne sais pas si les records ont une utilité autre que locale maintenant qu'il y a les objets... et la contrainte dont tu parles n'est gênante que si le type record est exporté, sinon, elle ne vaut que pour l'intérieur d'un même fichier, où elle est gérable).

Ceci dit, tu te trompes de cause : ce n'est pas le typage automatique qui est responsable de cette contrainte, c'est l'absence de types polymorphes de la forme {bidule : type, ...} Je suppose que c'est réalisable pour les records puisque ça l'est pour les objets...

)# let f bidule = bidule.contents;;
val f : 'a ref -> 'a = <fun>
# type machin = {contents : int};;
type machin = { contents : int; }
# let f bidule = bidule.contents;;
val f : machin -> int = <fun>
# let f bidule = bidule.Pervasives.contents;;
val f : 'a ref -> 'a = <fun

Tiens au fait, est-ce qu'OCaml gère proprement les cross-references (comme Java ou C#), ou est-ce qu'il fait ça d'une manière gore ? (c'est un peu "adouci" par rapport au C avec les .mli faits automatiquement, j'ai l'impression, mais ça doit être assez primaire s'il gère tout comme si c'était tapé dans le top-level -- notamment ça pourrait foirer s'il fait ça naïvement avec des références cycliques, ou des forward references au sein d'un même fichier)

Arguments ending in .cmx are taken to be compiled object code. These files are linked together, along with the object files obtained by compiling .ml arguments (if any), and the Caml standard library, to produce a native-code executable program. The order in which .cmx and .ml arguments are presented on the command line is relevant: compilation units are initialized in that order at run-time, and it is a link-time error to use a component of a unit before having initialized it. Hence, a given x.cmx file must come before all .cmx files that refer to the unit x.

ce serait un peu con que le même code ne fasse pas la même chose à des endroits différents du prog, non ?

 :# module Asm = struct type statement = {label : int} end;;
module Asm : sig type statement = { label : int; } end
# module C = struct type statement = {label : bool} end;;
module C : sig type statement = { label : bool; } end
# open Asm;;
# let f s = s.label;;
val f : Asm.statement -> int = <fun>
# open C;;
# let f s = s.label;;
val f : C.statement -> bool = <fun>
# open Asm;;
# let f s = s.label;;
val f : Asm.statement -> int = <fu