Discussion :

[james-mi]

J'espère que je poste dans le bon forum, impossible de poster dans le forum "langage fonctionnels" ...

je voudrais savoir si quelqu'un saurait :
-quelle différence de vitesse d'exécution il y a entre Anubis et OCaml
-si le typage d'OCaml est moins fin que celui d'Anubis, qui est décrit dans la doc comme "très fin" ?

[gorgonite]

déjà penses à lire ce débat...
http://www.developpez.net/forums/showthread.php?t=38275


OCaml est pour le moment bien meilleure côté vitesse d'exécution et gestion du garbage collector... mais une nouvelle version d'Anubis devrait bientot sortir, donc il faudra retester

Anubis est bien plus orienté "sûreté du développement", ce qui se traduit parfois par de lourds mécanismes pour les tests de valeurs de retour

côté typage, si je me rappelle bien, Anubis a des types déclarés (et non inférés comme avec OCaml)
en théorie, cela devrait "éviter" certains problèmes du typage à la ML qui survienne lorsqu'on atteint pas un point fixe en une itération... si l'on voulait continuer les itérations, il y a un moment un problème de semi-décidabilité

mais il faudrait étudier de plus prêt les types "à la Anubis" parce qu'il existe également des système de typage statique et explicite qui sont bien plus faibles que le système de typage statique et implicite de OCaml

[SpiceGuid]

quelle différence de vitesse d'exécution il y a entre Anubis et OCaml

OCaml est clairement en avance sur ce point, Anubis n'est pas à recommander pour du calcul intensif, cependant il convient très bien (et est utilisé) pour des applications web. La version à venir est la 1.8, à ma connaissance il ne faut s'attendre ni à une hausse spectaculaire de performance ni à un changement de technique de ramasse-miettes.

si le typage d'OCaml est moins fin que celui d'Anubis, qui est décrit dans la doc comme "très fin" ?

Le typage d'Anubis est légèrement plus fin que celui d'OCaml, il cumule l'inférence de types avec la surcharge (ou polysémie).

Enfin, il faut le signaler car en pratique je trouve que c'est un avantage précieux, OCaml possède un interpréteur interactif, ce n'est pas le cas d'Anubis.

En résumé:

• Anubis est plus simple dans sa conception, il est moins redondant car moins multi-paradigme, par contre les outils sont moins matures
• OCaml est plus facile d'utilisation mais nécessite un peu plus d'investissement personnel, notamment à cause de son approche multi-paradigme (fonctionnel, impératif, fonctors, POO)

[james-mi]

Merci de vos réponses éclairantes ...

C'est vrai qu'à première vue, Anubis a l'air plus simple et cela m'a attiré dans un premier temp, néanmoins ce n'est pas forcément un avantage. D'autant que la licence d'Anubis ne me semble pas d'une clarté limpide, ou en tout cas pas aussi souple que l'Open Source de OCaml

[james-mi]

déjà penses à lire ce débat...
http://www.developpez.net/forums/showthread.php?t=38275

C'était déjà lu, mais merci quand même

et merci pour les autres infos de ta réponse

[Garulfo]

[...] qui sont bien plus faibles [...]

« Faible » dans le sens ?

[james-mi]

« Faible » dans le sens ?

moins généraux peut-être ? J'ai retenu que OCaml infère toujours le type le + général (est-ce la bonne terminologie ?) ...

[gorgonite]

« Faible » dans le sens ?

je pense qu'un typage statique et explicite comme dans C est plus faible (ie laisse trop de possibilités de saletés dangereuses, mais parfois plus performantes )

moins généraux peut-être ? J'ai retenu que OCaml infère toujours le type le + général (est-ce la bonne terminologie ?) ...

OCaml essaie de générer le type le plus général possible, mais doit atteindre un point fixe en une itération... donc on a parfois du mal à typer des choses relativement simples, même si l'on donne une indication de typage (contrairement à Haskell )

[millie]

OCaml essaie de générer le type le plus général possible, mais doit atteindre un point fixe en une itération... donc on a parfois du mal à typer des choses relativement simples, même si l'on donne une indication de typage (contrairement à Haskell )

Tu parles de chose comme ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
let rec f n =
  if n = 0
      0
   else 
      f n-1;;

En mettant n dans Z et non dans N ?

[gorgonite]

Tu parles de chose comme ?

ben non, ocaml sait typer cela sans problème... ^^



je pense par exemple à un point fixe du lambda calcul


sinon tu peux jouer avec cela

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
# let f1 a lst = [];;
val f1 : 'a -> 'b -> 'c list = <fun>
# let app f lst =
      (f 2 lst, f 2.0 lst)
    ;;
This expression has type float but is here used with type int

pourtant si je considère app f1 lst, elle est théoriquement correct et renverra ([],[])


en Haskell

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Prelude> let f1 a lst = []
Prelude> let f1 a lst = [] in app f1 [1,2,3]
([],[])
Prelude>

on peut en sortir des tonnes ^^

[millie]

ben non, ocaml sait typer cela sans problème... ^^

Il me semblait que ocaml typait ça dans Z au lieu de typer ça dans N...

(la fonction se termine toujours dans N mais pas dans Z et du coup, j'aurais préféré indiquer moi même le domaine)

[gorgonite]

Il me semblait que ocaml typait ça dans Z au lieu de typer ça dans N...

(la fonction se termine toujours dans N mais pas dans Z et du coup, j'aurais préféré indiquer moi même le domaine)

le fait de typer une fonction n'implique pas qu'elle se terminera

[millie]

le fait de typer une fonction n'implique pas qu'elle se terminera

Je parlais au niveau de la sécurité du typage automatique par ocaml.

En tant que développeur, j'aurais pu concevoir la fonction pour que ce soit OK sur N, donc si j'avais pu écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
let rec f (nat n) 
  if n=0 0 else f n-1;

La fonction aurait été plus sûre.

Alors qu'avec ocaml, pour permettre que la fonction plante pas, je suis obligé de modifier les spécifications de ma fonction pour que ce soit OK sur tout Z parce que ocaml me dit que la fonction marche sur Z.

Je sais pas si je suis clair ? J'ai un peu mal au crâne alors j'ai du mal à me concentrer

[gorgonite]

Je parlais au niveau de la sécurité du typage automatique par ocaml.

Alors qu'avec ocaml, pour permettre que la fonction plante pas, je suis obligé de modifier les spécifications de ma fonction pour que ce soit OK sur tout Z parce que ocaml me dit que la fonction marche sur Z.

non suffit d'avoir défini ton type correctement ^^

[Jedai]

Je sais pas si je suis clair ? J'ai un peu mal au crâne alors j'ai du mal à me concentrer

Ton problème n'en est pas un, tu peux tout à fait faire ce que tu demandes en OCaml, il suffit de créer un nouveau type pour les naturels. Ce n'est pas un type par défaut d'OCaml mais c'est tout à fait possible.

Par contre tu n'auras pas de relation entre int et nat, ni de partage des opérateurs, ce qui peut être considéré comme regrettable.

--
Jedaï

[gorgonite]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
# type nat = Zero | Succ of nat;;
type nat = Zero | Succ of nat
# let rec gen_nat n = match n with 0 -> Zero | n when n>0 -> Succ (gen_nat (n-1)) | _ -> failwith "nat negatif";;
val gen_nat : int -> nat = <fun>
# f (gen_nat (-1));;
Exception: Failure "nat negatif".
# f (gen_nat 4);;   
- : int = 0

en OCaml ça peut sembler assez lourd
mais sous Haskell il y aurait certainement moyen de pouvoir ajouter de manière transparente un entier et un nat et renvoyer un entier

[Jedai]

en OCaml ça peut sembler assez lourd
mais sous Haskell il y aurait certainement moyen de pouvoir ajouter de manière transparente un entier et un nat et renvoyer un entier

Non, ce que tu décris là est impossible en Haskell, et heureusement ! Il n'y a pas de cast automatique en Haskell et les opérateurs numériques binaires comme "+" prennent deux opérandes du même type.
La différence par rapport à OCaml, c'est que ce type n'est pas forcément Int, mais peut être Double ou Rational par exemple. Tout type instance de la classe de type Num convient.

Par ailleurs faire de Nat une instance de Num n'est pas forcément une bonne idée, vu que Num à la base décrit plutôt un anneau (negate est une fonction de Num).

--
Jedaï

[gorgonite]

Non, ce que tu décris là est impossible en Haskell, et heureusement ! Il n'y a pas de cast automatique en Haskell et les opérateurs numériques binaires comme "+" prennent deux opérandes du même type.
La différence par rapport à OCaml, c'est que ce type n'est pas forcément Int, mais peut être Double ou Rational par exemple. Tout type instance de la classe de type Num convient.

je suis au courant...

je pensais à une unique fonction pour cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Int -> Nat -> Int
Nat -> Int -> Int

Par ailleurs faire de Nat une instance de Num n'est pas forcément une bonne idée, vu que Num à la base décrit plutôt un anneau (negate est une fonction de Num).

pas cool forcemment cela
et on peut s'arranger pour que negate lance une exception ou un truc du style ?

[Jedai]

je suis au courant...

je pensais à une unique fonction pour cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Int -> Nat -> Int
Nat -> Int -> Int

Bien sûr dans ce cas c'est possible, mais tu peux faire de même en OCaml. (A moins que tu veuilles dire une seule fonction pour les deux types ? C'est peut-être possible mais je ne le recommanderais pas même si ça l'était)

et on peut s'arranger pour que negate lance une exception ou un truc du style ?

Tout à fait, on peut déclarer 'negate = error "Naturals don't have negatives"'.

--
Jedaï

[gasche]

De toute façon, si l'utilité de Nat est de prouver facilement par induction que les récursions sont bien fondées, on n'a probablement pas intérêt à le munir de tout un attirail de trucs encourageant à en complexifier l'usage : si on se retrouve avec un type somme multi-fonctions, quelle est la différence avec int (qui après tout n'est qu'un gros type somme, si on veut).

OCaml essaie de générer le type le plus général possible, mais doit atteindre un point fixe en une itération... donc on a parfois du mal à typer des choses relativement simples, même si l'on donne une indication de typage (contrairement à Haskell ) [...]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
# let app f lst =
      (f 2 lst, f 2.0 lst)
    ;;
This expression has type float but is here used with type int

pourtant si je considère app f1 lst, elle est théoriquement correct et renverra ([],[])

D'une part, ton code Haskell ne correspond pas au code OCaml donné (ou alors je n'ai pas compris ce que tu essaies de faire). Ensuite, la fonction app demande du polymorphisme de rang 2, et effectivement sans annotations de type cela échoue en OCaml comme en Haskell :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
# let app f x = (f () x, f "foo" x);;
This expression has type string but is here used with type unit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Prelude> let app f x = (f () x, f "foo" x)
<interactive>:1:23:
    Couldn't match expected type `[Char]' against inferred type `()'
      Expected type: [Char] -> t -> t1
      Inferred type: () -> t -> t2
    In the expression: f "foo" x
    In the expression: (f () x, f "foo" x)