[polymorphisme] fonction pour trouver le type d'une variable

Invité · 28/11/2007, 00h19

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** · 28/11/2007, 09h27

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** · 28/11/2007, 12h49

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é · 28/11/2007, 15h15

@ 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** · 28/11/2007, 15h57

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** · 28/11/2007, 16h15

Envoyé par LLB

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

**SpiceGuid** · 28/11/2007, 16h47

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** · 28/11/2007, 18h12

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.

Invité · 29/11/2007, 09h17

Envoyé par LLB

Envoyé par hellfoust

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

**gorgonite** · 29/11/2007, 10h55

Envoyé par hellfoust

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).

en quoi le mécanisme de surcharge serait-il plus lourd ?
c'est un des points forts de la POO... le point faible étant la nécessité de calculer la véritable adresse des méthodes virtuelles lorsqu'on utilise un type "plus générique"

Envoyé par hellfoust

@ 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 ...

faudrait quand même arrêter de dire que le C n'est pas fait pour être utilisé en pratique... le plus important c'est souvent le respect de certaines conventions qui vont apporter une certaine sécurité, bien plus que le langage lui-même.

Invité · 30/11/2007, 07h26

Envoyé par gorgonite

en quoi le mécanisme de surcharge serait-il plus lourd ?

Je ne savais pas qu'est ce que c'était.

alex_pi · 30/11/2007, 10h30

Il faudrait peut être commencer une mini-FAQ caml, et à la question "peut-on acceder au type d'un élément à l'execution", répondre "non" :-)

**InOCamlWeTrust** · 30/11/2007, 11h50

Envoyé par hellfoust

@ 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.

Dans les codes numériques bien faits, la robustesse à proprement parler représente plus de 90% du code... donc on imagine bien les pertes sèches en termes de performances...

**gorgonite** · 30/11/2007, 12h00

Envoyé par InOCamlWeTrust

Dans les codes numériques bien faits, la robustesse à proprement parler représente plus de 90% du code... donc on imagine bien les pertes sèches en termes de performances...

manque flagrant de librairies ou volonté de réinventer la roue à chaque projet

?

il y a pas mal de langages qui ont des types numériques "sûrs" dans leur librairie standard... et donc où l'on n'est pas toujours forcé de tout retester

le problème venant souvent des mélanges entre les types sûrs et et les autres dans le style de programmation ; ou dans les possibilités de "transtypage sale" dans les possibilités du langage, ie sans suffisamment de vérification à la compilation et/ou à l'exécution... mais je n'ai pas dit que ces fonctionnalités ne pouvaient pas être très utiles dans d'autres cas