Discussion :

[Invité]

Bonjour,
je cherche une fonction pour trouver le type d'une variable.

Je voudrait quelque chose du genre

Code :

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

1
2
3
4
5
let le_type (x) = match x with
     | int -> "entier"
     | float -> "flottant"
     | _ -> "indefini"
;;

Un exemple de l'utilité de cette fonction, pour calculer la valeur absolue de x :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
let abs x =
     if le_type (x) = "entier"
          then
               if x>0
                    then x
                    else -x
          else
               if le_type (x) = "flottant"
                    then
                         if x>0
                              then x
                              else -. x
                    else failwith "erreur"
     ;;

Comme ça j'ai la même fonction pour trouver la valeur absolue d'un entier ou la valeur absolue d'un flottant.

[gorgonite]

en gros tu veux une fonction dont la signature serait

Code :

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

 mon_typeur : 'a -> type

les questions à se poser :

• les types sont-ils des valeurs en OCaml ?
• si non, serait-il possible de passer par une monade Num ?
  http://gorgonite.developpez.com/livr...age=numbers#LX

[LLB]

On avait parler de quelque chose de similaire ici : http://www.developpez.net/forums/sho...d.php?t=407058

Pour faire court, tu ne peux pas dans Caml. Mais surtout, l'exemple que tu donnes est mauvais. Ta fonction accepterait n'importe quel type, ce qui affaiblirait considérablement le typage. Imagine, si tu appelles abs avec une chaine de caractères, le compilateur ne pourrait pas détecter l'erreur et tu te trouverais avec une exception à l'exécution. Tu perdrais ce qui est l'une force de Caml. Je t'assure : le code que tu proposes est dangereux.

Si jamais ce style de programmation t'intéresse, cherche plutôt du côté des langages interprétés (Lisp, Ruby, Perl, Python...). Si tu souhaites plutôt conserver le typage statique et avoir la surcharge, tu peux regarder du côté de Haskell, F# ou utiliser extension de Caml pour ça.

Pour l'exemple que tu donnes, utilise une fonction absf pour les float. C'est de loin la meilleure solution (ma réponse au dessus répondait à la question de façon générale).

[Invité]

@ Gorgonite : j'aimerait bien que les types soient des valeurs pour les stocker en mémoire et travailler avec mais j'ai l'impression que c'est mal barré ... Et pour ta solution, je suis débutant, je crois que c'est plus simple de faire sans.

@ LLB : oui actuellement j'ai une fonction abs_i qui calcul l'absolue d'un entier et une fonction abs_f qui calcul l'abolue d'un flottant, et il aurait été plus "confortable" pour moi d'utiliser une fonction abs qui utilise la fonction abs_i si l'argument est un entier ou la fonction abs_f si l'argument est un flottant.

Mais bon, je pourrait m'en sortir sans, même si ça rallonge pas mal le code parfois (faut tout faire en double, c'est ça que tu appelle la "surcharge" ?).

Pour l'instant, je suis obligé de travailler avec caml (suis à la fac), mais j'en apprendrait bien un deuxième. Les langages interprétés ont l'air nazes puisqu'ils sont lents à l'exécution. Pour les applications qui n'ont pas besoin d'une sureté absolue, j'aimerait bien connaître un langage à typage statique, mais sans la surcharge (inutile vu que je ne fait pas d'erreurs ). Le C à l'air de correspondre mais en connaissez vous d'autres ?

[LLB]

Si tu sa besoin d'avoir les mêmes fonctions sur les entiers et les flottants, oui, tu vas devoir dupliquer ton code. Pour la valeur absolue, il existe déjà les fonctions abs et abs_float.

(faut tout faire en double, c'est ça que tu appelle la "surcharge" ?).

La surcharge, c'est quand on définit plusieurs fonctions, de même nom, qui varient selon le type ou le nombre d'arguments. Ca permet de définir abs en int -> int et float -> float. C'est supporté par la majorité des langages de programmation (mais Caml ne l'a pas).

Pour l'instant, je suis obligé de travailler avec caml (suis à la fac)

D'accord. Donc, tu devras te passer de ta fonction abs générique. Rassure-toi : si ce n'est pas très gênant en général. C'est surtout une question de philosophie : tous les types sont clairs et précis, et chaque valeur a un seul et unique type. Par ailleurs, Caml offre beaucoup d'autres fonctionnalités, et a beaucoup d'avantages sur les langages plus courants.

Les langages interprétés ont l'air nazes puisqu'ils sont lents à l'exécution.

Non. Dans la majorité des cas, on se fiche des performances et ce n'est pas grave de perdre quelques millisecondes dans une boucle. Tout dépend de ce que tu veux faire. En fonction du besoin, ils peuvent se révéler très puissants ou inutiles. Ca dépend.

Pour les applications qui n'ont pas besoin d'une sureté absolue, j'aimerait bien connaître un langage à typage statique, mais sans la surcharg

Je ne comprends pas ce que tu veux dire.
Typage statique : vérification des types à la compilation. Donc, le typage statique est important si on veut de la sûreté.
Typage dynamique : c'est le contraire, il n'y a pas de vérification. C'est souvent lié aux langages interprétés.

Le C à l'air de correspondre mais en connaissez vous d'autres ?

Dans la même logique, mais en plus haut niveau, il y a : C++, Java, C# (ces langages possèdent la surcharge, mais je crois que tu t'es mal exprimé). Là encore, ça dépend des besoins et des objectifs.

[Steki-kun]

Si tu sa besoin d'avoir les mêmes fonctions sur les entiers et les flottants, oui, tu vas devoir dupliquer ton code.

Juste pour pinailler, on ne peut pas avoir besoin des "mêmes fonctions" sur les entiers et les flottants, ou plus généralement sur deux types différents, puisque par définition ça peut pas être les mêmes fonctions. Donc, techniquement on ne "duplique" pas son code, on fait ce qu'on est obligé de faire de tte façon : définir une opération sur les entiers ne permet pas de l'étendre magiquement aux rationnels ou aux réels, et vice versa.
Si le langage permet d'utiliser la même phrase *syntaxique* pour définir deux fonctions différentes (en l'occurrence un truc du genre "if(x < 0) return -x; return x" en C par exemple), c'est parce qu'il fait le duplicage pour nous

[Invité]

Pour les applications qui n'ont pas besoin d'une sureté absolue, j'aimerait bien connaître un langage à typage statique, mais sans la surcharge

Je ne comprends pas ce que tu veux dire.
Typage statique : vérification des types à la compilation. Donc, le typage statique est important si on veut de la sûreté.
Typage dynamique : c'est le contraire, il n'y a pas de vérification. C'est souvent lié aux langages interprétés.

Je croyais que la surcharge était synonyme de plus de boulot, c'est pour ça que j'ai dit "sans surcharge" mais en fait c'est moins de boulot. Pour le typage statique, c'est pas vraiment pour la sûreté, c'est plus pour la vitesse d'exécution (même si ce n'est que peu important).

@ In ocaml we trust : c'est sûr, il faut de la "robustesse numérique", mais on est pas obligé de gâcher plus de vitesse d'exécution que nécessaire pour cela. C'est vrai que le C c'est pas mal pour s'amuser en passant d'un type à l'autre avec les mêmes octets mais pour travailler c'est sans doute différent ...

Merci pour vos réponses, j'ai eu la mienne

[SpiceGuid]

Tu peux certainement créer, pour ton éditeur de code, une macro qui remplace les fonctions sur les int + - * / abs_i par leur équivalents respectifs sur les float +. -. *. /. abs_f.

[InOCamlWeTrust]

Vitesse d'exécution et robustesse numérique font très mauvais ménage, en général. Avec un langage comme le C, il est probable que tu deviennes chauve avant l'âge si tu t'amuses à utiliser les règles de conversion explicites ou implicites, qu'il faut absolument connaître.