Discussion :

[JohnT-47]

Bonjour,

est ce que quelqu'un connaitrait une fonction qui permet de recuperer le type de n'importe quelle variable ?
( Par exemple qui renvoie float quant on a
# b;;
- : float = 3. )

Ou si elle n'exite pas, une piste pour la creer moi meme. J'ai deja tente plusieurs (...beaucoup meme...) de syntaxes différentes sans succes.

Merci de votre aide !!

[SpiceGuid]

Elle n'existe pas.
Et si elle existait, quelle serait son type ?

[JohnT-47]

Je ne sais pas je suppose que ca serait <fun>.....

[JohnT-47]

Plus serieusement :
ca devrait etre :
val f : 'a -> string = <fun>

Non ?

[SpiceGuid]

La fonctionnalité la plus proche qui me vient à l'esprit c'est le module Vprint qui, dans un certaine mesure, est capable d'afficher la représentation d'une valeur.

Mais c'est la mauvaise voie, la bonne voie c'est l'exploitation statique de l'information de type, sa récupération dynamique est indésirable et/ou impossible.

[InOCamlWeTrust]

Oui, effectivement, ça n'a pas de sens. En général, si on essaye de faire une chose dans ce genre-là, c'est qu'il y a un problème algorithmique à la base.

Pourquoi désires-tu faire une telle chose ?

[Garulfo]

Ce que tu demande JohnT est contraire à la philosophie du ocaml -_-

Il y a un antagonisme qu'on a retrouvé tout au long de l'histoire (et qui remonte à Platon vs. Aristote) caché derrière.

En ocaml, le type est une méta-information. Dans d'autre langage, par exemple, CLOS ou Smalltalk ou récemment Java, la philosophie veut que le type soit lui-même un objet du langage et manipulable comme un autre objet. On tombe éventuellement alors dans les problèmes hiérarchiques:
La méta-catégorie des catégories est-elle une catégorie ?
Le méta-ensemble des ensembles est-il un ensemble ?
La méta-classe des classes est-elle une classe ?
Le méta-type des types est-il un type ?

En tout cas le choix de ocaml est très clair et peut très bien se comprendre, ainsi que celui des autres. Ils ont chacun leurs avantages et défauts.

Chacun sa philosophie
Idéaliste ou réaliste, un long débat s'en suit. C'est la querelle des universaux du moyen-âge.

[LLB]

Si ça te manque vraiment, utilise F#.

Comme tu peux le voir dans l'exemple ci-dessous, c'est parfaitement typé, avec le type que tu souhaitais ('a -> unit).

Code F# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
> let print x =
    printf "- : %s = %A\n" ((x :> obj).GetType().Name) x;;
val print : 'a -> unit
 
> print 3;;
- : Int32 = 3
 
> print "test";;
- : String = "test"
 
> print [|1..5|];;
- : Int32[] = [|1; 2; 3; 4; 5|]

Mais c'est la mauvaise voie, la bonne voie c'est l'exploitation statique de l'information de type, sa récupération dynamique est indésirable et/ou impossible.

Dans la majorité des cas, oui, c'est mieux quand tout est statique.

Mais certains cas, comme l'affichage générique, c'est très utile d'avoir les informations de type à l'exécution. Par exemple, pour afficher une liste, on voudrait la fonction 'a list -> unit. En Caml, on ne peut pas. Soit, on doit spécialiser la fonction (int list -> unit, string list -> unit). Soit, il faut passer une fonction en argument, mais le code peut devenir lourd.

Pouvoir écrire :

Code :

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

let print_list l = List.iter (printf "%A\n") l

est quand même vachement agréable. Bien sûr, ce n'est jamais indispensable, mais c'est agréable. La fonction est correctement typée et elle est safe.

[gasche]

Ou sinon, une version modifiée de OCaml pour supporter le typage ad-hoc : http://web.yl.is.s.u-tokyo.ac.jp/~furuse/gcaml/

[Jedai]

Dans la majorité des cas, oui, c'est mieux quand tout est statique.

Mais certains cas, comme l'affichage générique, c'est très utile d'avoir les informations de type à l'exécution. Par exemple, pour afficher une liste, on voudrait la fonction 'a list -> unit. En Caml, on ne peut pas. Soit, on doit spécialiser la fonction (int list -> unit, string list -> unit). Soit, il faut passer une fonction en argument, mais le code peut devenir lourd.

Pouvoir écrire :

Code :

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

let print_list l = List.iter (printf "%A\n") l

est quand même vachement agréable. Bien sûr, ce n'est jamais indispensable, mais c'est agréable. La fonction est correctement typée et elle est safe.

Et en Haskell tu pourrais écrire simplement :

Code :

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

1
2
3
-- l'annotation de type n'est pas indispensable, elle est inférée
printList :: (Show a) => [a] -> IO ()
printList = mapM_ print

Il faut tout de même que le type dans la liste soit une instance de Show, mais c'est le cas de tous les types de la librairie standard et cela peut-être fait automatiquement pour un nouveau type en rajoutant "deriving Show" derrière sa définition (bien sûr on peut coder soi-même l'instance de Show si on tient à un affichage particulier).

(NB : Un simple print sur une liste marchera aussi, bien sûr, mais la sortie ne sera pas exactement la même que pour la fonction de LLB)

--
Jedaï

[LLB]

Ou sinon, une version modifiée de OCaml pour supporter le typage ad-hoc :

Est-ce une bonne idée de l'utiliser ?
Ca fait longtemps que j'en ai entendu parler. Si c'est vraiment bien, pourquoi n'est-ce pas intégré à Caml ? Si elle a des problèmes, il vaudrait peut-être mieux ne pas la conseiller, non ? À lire la page, ça me semble vraiment bien et ça résout beaucoup de problèmes de Caml. Pourtant, je ne rencontre jamais personne qui l'utilise pour de vrai (les utilisateurs de Caml ici, l'utilisez-vous ?).

Concernant les problèmes de typage et de philosophie évoqués au début de thread, je trouve ça un peu étrange. Si GCaml, Haskell, F# et beaucoup d'autres le font, pensez-vous vraiment que c'est gênant au niveau du typage ?

D'ailleurs, la surcharge permet une plus grande généricité. Par exemple, on peut écrire une fonction qui travaille indifféremment sur un 'a array ou sur un 'a list, plutôt que de copier-coller le code.

[code Haskell]

Il voulait afficher le type de la valeur. C'est possible en Haskell ? C'est vraiment pas une fonctionnalité importante, mais c'est juste par curiosité que je demande.

En tout cas le choix de ocaml est très clair et peut très bien se comprendre, ainsi que celui des autres. Ils ont chacun leurs avantages et défauts.

Pour moi, c'est juste une limitation supplémentaire. Qu'est-ce que ça apporte comme fonctionnalité, en dehors du fait que ça empêche certaines horreurs ?

[Jedai]

D'ailleurs, la surcharge permet une plus grande généricité. Par exemple, on peut écrire une fonction qui travaille indifféremment sur un 'a array ou sur un 'a list, plutôt que de copier-coller le code.

J'aurai tendance à être d'accord avec toi, par exemple ce que tu cites (travailler indifféremment sur un tableau ou une liste, je suppose en les considérant tous deux comme une suite d'éléments) est possible en utilisant la typeclass Foldable en Haskell, dont Array et List sont deux éléments. Si un concepteur de librairie en OCaml veut faire la même chose (proposer une fonction qui effectue une opération à partir d'une suite d'élément, un fold dans le cas de Foldable), il va devoir soit écrire deux version, une pour les array et une pour les list, soit laisser son utilisateur faire une conversion inefficace lui-même à chaque utilisation de sa fonction. Un spécialiste de OCaml peut-il me détromper ?
(Array et List sont bien sûr des instances communes d'autres Typeclass, comme Functor, Ord (ce qui est je crois implicite en OCaml, cela me semble un peu incohérent, pourquoi seul les opérateurs de comparaisons sont-ils surchargés !), ...)

Il voulait afficher le type de la valeur. C'est possible en Haskell ? C'est vraiment pas une fonctionnalité importante, mais c'est juste par curiosité que je demande.

Et bien je ne crois pas que ce soit possible en Haskell98, mais avec GHC, il suffit d'utiliser Data.Typeable.typeOf sur une instance de Typeable (ce que sont tous les types de la librairie standard, et il suffit de rajouter "deriving Typeable" à ses nouveaux types). Néanmoins je ne vois pas trop l'intérêt (Typeable sert à d'autres choses très puissantes, donc en sous-main ça peut être utile, mais dans une librairie "normale" ??? ). Autant utiliser ":type" sous GHCi si on s'interroge sur le type d'une expression.

--
Jedaï

[LLB]

(Array et List sont bien sûr des instances communes d'autres Typeclass, comme Functor, Ord (ce qui est je crois implicite en OCaml, cela me semble un peu incohérent, pourquoi seul les opérateurs de comparaisons sont-ils surchargés !), ...)

Les opérateurs de comparaison sont "surchargés", parce que sinon, le langage deviendrait quasiment inutilisable. Je suis d'accord avec toi, ce n'est pas consistant. Ce n'est d'ailleurs pas de la surcharge propre, c'est du type 'a -> 'a -> bool. La faille étant que 2 fonctions ne peuvent pas être comparées. Du coup, "let f x = x in f = f" génère une exception, à l'exécution. Niveau sûreté, on a vu mieux.

Les comparaisons sont "surchargées", puisque sinon il faudrait de nombreux opérateurs : =, >, <, >=, <= et <> devraient être codés pour chaque type. Et il faudrait créer les opérateurs à chaque type utilisateur. Du coup, des fonctions comme min, max, List.mem, les types Map ou Hashtbl ne pourraient plus exister en l'état.

Ce problème de lourdeur se pose déjà pour les nombres, puisqu'il existe de nombreux opérateurs (+, +., +/ ...). Et encore : certains types entiers n'ont pas leur propre opérateur (par exemple, int64). Et encore : le nombre de types entiers existants a été limité (int8 ? int16 ? unsigned ?). L'absence de surcharge ici aussi rend impossible également certaines fonctions (calculer la moyenne numérique d'un tableau ?).

En Haskell, la solution passe par les classes de types ; en F# par des interfaces communes et de la surcharge d'opérateurs.

Et bien je ne crois pas que ce soit possible en Haskell98, mais avec GHC, il suffit d'utiliser Data.Typeable.typeOf sur une instance de Typeable (ce que sont tous les types de la librairie standard, et il suffit de rajouter "deriving Typeable" à ses nouveaux types).

OK. Merci !

[HanLee]

En C++, on peut aussi utiliser les templates, alors en OCaml, j'ai trouvé ça : OCaml-Templates

Je pense que ça vaut le coup d'oeil.
Ils disent qu'on construit des abstractions beaucoup plus facilement qu'en C++, mais c'est dommage qu'il n'y a pas quelques comparaisons.

[JohnT-47]

Hum... j'avais déja regardé le module Vprint, ca ne me convient pas du tout. En fait je construit une bibliotheque perso a partir des modules fran ( ac le behavior et les events d'ou le OCaML) avec des varaibles et fonctions qui sont cencées pouvoir s'imbriquer entre elles selon certaines règles. Et donc je veux récuperer le type de mes fonctions et de mes variables pour trois raisons:
la vérification de la syntaxe
l'affichage
l'interpretation propre (calculs, ...etc.).
Du coup Vprint est inutile pour moi. Cela dit je regarde le code pour voir si je ne pourrai pas me resservir de quelques idées
La piste du F# à l'air intéressante mais meme si ca marche je prefererai trouver une solution en CaML, ne serai-ce que pour avoir la satifaction que les longues heures de recherche n'auront pas étées inutiles.
Bon je vais relire les réponses et j'y retourne.

++

[SpiceGuid]

En gros tu veux faire un interpréteur, non?

Si c'est le cas regarde plutôt la source de ce petit exemple d'interpréteur pour le lambda-calcul (enrichi avec let et let rec).

[JohnT-47]

Oui en fait je veux faire un interpreteur, mais un poil plus compliqué. Enfin mdisons plus varié au niveau des fonctions/types de variables. Donc pour le moment mon code ressemble au tient ( dans l'esprit quoi....) mais comme je souhaite ajouter des types et surtout travailler avec des types abstract et des flux de type event, je galère un peu par moments.
Je n'ai toujours pas reussi à faire mon affichage de manière satisfaisante, mais ca marche.
Pour l'interprétation Proprement dite ca marche bien, pas de problemes de ce coté la.
Par contre les types utilisés étant un peu compliqués a manier ( FRAN propose un nombre de chose incroyable et mon but c'est de tout passer dans mon propre interpréteur ), il me faut absolument un analyseur syntaxique parfait : mon prog est destiné a d'autres utilisateurs !!! Pas forcément familiers avec le CaML ou d'autres l'anguage d'ailleurs.
Bon bref tout ca pour dire que en fait je veut faire un interpreteur dans le genre du tient ( qui marche aa peu pres). Mais la récuperation de types me servira a "faciliter" son acces et sa comprehnsion aux non-Cameliens/istes...

++

[caouis]

Elle n'existe pas.
Et si elle existait, quelle serait son type ?

a->string ou a-> typ :

Code :

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

1
2
 
type typ = | Int | String | Float | Abstract of string | Function of typ array| Array of typ | List of typ | Tuple of typ array...

Mais effectivement vu qu'il n'y a pas de conservation du type à la compilation elle ne peut pas exister comme il le souhaite.
le compilateur et l'interpréteur le font , mais seulement sur sur le code source et pas sur une valeur au moment de l'exécution .
d'ailleur si quelqu'un connaissait la fonction utilisée par le compilateur je serais ravi de la connaitre .

[SpiceGuid]

caouis a (presque) tout compris, en effet le type de la fonction qui répond aux besoins de JohnT-47 est bien value -> string, où value est le type ainsi défini:

type value =
| Int of int
| String of string
| Float of float
| Tuple of value list
| Array of value array
| ...

1. cette fonction de type value -> string s'appelle un pretty-printer
2. le dual c'est une fonction de type string -> expression et ça s'appelle un analyseur syntaxique
3. entre les deux c'est une fonction de type expression -> value et ça s'appelle un interpréteur

[Garulfo]

[...]
Pour moi, c'est juste une limitation supplémentaire. Qu'est-ce que ça apporte comme fonctionnalité, en dehors du fait que ça empêche certaines horreurs ?

Tu réponds à ta question non ?
Encore une fois, ne cherches pas (enfin ça ne s'adresse pas à toi en particulier ) à surinterpréter ce que je n'ai pas dis. D'ailleurs, j'ai une préférence dans l'utilisation dans langage plus flexible (et notamment des langages sans types). Mais ça se comprend quand même et surtout, ce qui est très bien, c'est un choix philosophique complètement assumé.