construction implicite de classe [Résolu]

[gorgonite]

Salut,


Ayant (enfin) réussi à compiler F# avec mono, je tente de me familiariser quelque peu avec ce langage en recodant un de mes projets OCaml

j'essaie d'utiliser la construction implicite des classes pour gagner en concision, mais sans succès

Code :

1
2
3
4
5
6
7
8
9
type 'a type_inf = MaxInf | MinInf | Type of 'a

type 'a Interval() =
	let mutable up = MaxInf
	let mutable down = MinInf

	member self.Up
		with	get() = up
		and	set(u) = up <- u

[SpiceGuid]

Pardon de jouer au rabat-joie mais le bon type interval est un type somme, on ne répétera jamais assez l'importance des types somme (qui permettent le filtrage) :

Code :

1
2
3
4
type 'a interval =
  | Less of 'a
  | More of 'a
  | Interval of 'a * 'a

Et pas besoin de te justifier, car c'est moi qui te demande pardon pour cette parenthèse de hors-sujet.

[gorgonite]

Envoyé par SpiceGuid

Pardon de jouer au rabat-joie mais le bon type interval est un type somme,

tout dépend de l'utilisation que tu souhaites en faire... et dans mon cas, si je passe par un type somme, il faudrait que je développe tout un module autour, et j'aurais du mal à l'utiliser dans mon architecture (F# + C#)

[LLB]

Envoyé par gorgonite

j'essaie d'utiliser la construction implicite des classes pour gagner en concision, mais sans succès

Salut,

Le compilateur indique un problème de typage et te demande d'ajouter une annotation de type.

En lisant ton code, j'ai déduit que le paramètre 'a de Interval devait être utiliser aussi pour les variables up et down. Il faut l'indiquer, sinon le compilateur ne peut pas deviner que le paramètre est le même.

Donc :

Code :

let mutable (up: 'a type_inf) = MaxInf

et dans mon cas, si je passe par un type somme, il faudrait que je développe tout un module autour, et j'aurais du mal à l'utiliser dans mon architecture (F# + C#)

Les types sommes sont compilés comme une hiérarchie de classes. Normalement, tu devrais pouvoir les utiliser depuis C#, tu peux aussi ajouter des méthodes au type somme pour que ce soit plus agráble en C#.

Tu peux aussi utiliser le type somme de SpiceGuid en interne et créer une classe, juste pour l'interopérabilité avec C#.


Mais tout ça dépend surtout de tes besoins. Si tu n'as pas beaucoup d'algo à faire en F#, tu peux continuer avec ta classe.



Si ton problème était une erreur de syntaxe, deux solutions :
- soit tu utilises le mode #light (recommandé - sera bientôt mis par défaut), n'utilise pas de tabulations ;
- sinon, tu dois ajouter les mots-cle's "class" et "end".

[gorgonite]

Envoyé par LLB

Le compilateur indique un problème de typage et te demande d'ajouter une annotation de type.

ben malheureusement, ça ne m'a rien dit de tel

Code :

1
2
3
4
5
6
7
8
/media/sda3/home_directory/these/tests/fsharp_code_analyzer> mono /usr/local/FSharp-1.9.3.7/bin/fscp10.exe -c interval.fs

interval.fs(4,1): error: syntax error.

interval.fs(7,1): error: syntax error.

interval.fs(7,1): error: error: parse error
Process mono exited with code 1

Envoyé par LLB

Les types sommes sont compilés comme une hiérarchie de classes. Normalement, tu devrais pouvoir les utiliser depuis C#, tu peux aussi ajouter des méthodes au type somme pour que ce soit plus agráble en C#.

j'avais pas compris qu'on pouvait mixer ainsi types somme et classes

Envoyé par LLB

Tu peux aussi utiliser le type somme de SpiceGuid en interne et créer une classe, juste pour l'interopérabilité avec C#.

je verrais ce qui me convient le mieux, quand je passerais mon projet sous Visual Studio... pour le moment, je veux comparer la facilité d'utilisation et les perfs (c'est un "gros" projet d'analyse statique )

Envoyé par LLB

PS : le mode "#light" est recommandé (et sera mis par défaut prochainement). Même si tu ne veux pas l'utiliser, évite d'utiliser des tabulations.

ben j'aime bien mes tabulations... mais j'essaierais le #light dès que j'aurais un module complet qui fonctionne bien

[LLB]

J'ai modifié mon message entre temps. D'après ton erreur, il faut juste ajouter les mots-clés "class" et "end".

Code :

1
2
3
type 'a foo = class
...
end

[gorgonite]

Envoyé par LLB

J'ai modifié mon message entre temps. D'après ton erreur, il faut juste ajouter les mots-clés "class" et "end".

effectivement, j'avais trouvé autre chose sur internet, alors que c'est bien expliqué ici :

http://blogs.msdn.com/dsyme/archive/...r-1-9-1-8.aspx

[gorgonite]

pour infos, voici ma classe (presque finale, mais je ne peux pas tout mettre pour le moment )
http://www.developpez.net/forums/sho...89&postcount=2


si vous avez des commentaires, n'hésitez surtout pas

[LLB]

Quelques remarques en vrac :

Vu que tu es passé au mode light, tu peux supprimer tous les "class", "begin" et "end" de ton code.

"min" et "max" sont des fonctions disponibles par défaut, comme dans Caml. Donc, évite d'utiliser ces noms pour tes valeurs (enfin, c'est pas trop grave) et pense à les utiliser (tu peux les utiliser de nombreuses fois dans ton code).

Tu peux remplacer " new 'a Interval() " par "Interval()". new est facultatif pour les objets qui n'implémentent pas l'interface IDisposable.

Code :

1
2
3
let res = Interval()
res.Down <- foo
res.Up <- bar

peut s'écrire

Code :

let res = Interval(Down = foo, Up = bar)

Le coding-style .NET utilise des noms comme "MatchValue" plutôt que "match_value" pour toutes les méthodes.

Printf.sprintf "%A" est équivalent à la fonction any_to_string.

[gorgonite]

Envoyé par LLB

Vu que tu es passé au mode light, tu peux supprimer tous les "class", "begin" et "end" de ton code.

ça ne veut pas sur le type_inf

Code :

1
2
3
4
5
6
7
8
type 'a type_inf =
  MaxInf | MinInf | Type of 'a
with
  override this.ToString () = 
    match this with
    |Type(t) -> Printf.sprintf "%A" t
    |_ -> Printf.sprintf "%A" this
end

pourtant je n'ai vu que des exemples sans le end

Envoyé par LLB

"min" et "max" sont des fonctions disponibles par défaut, comme dans Caml. Donc, évite d'utiliser ces noms pour tes valeurs (enfin, c'est pas trop grave) et pense à les utiliser (tu peux les utiliser de nombreuses fois dans ton code).

je ne sais pas comment en OCaml ça aurait réagi avec des types non comparables... j'attendais donc pour imposer une "interface" à ce type

Envoyé par LLB

Tu peux remplacer " new 'a Interval() " par "Interval()". new est facultatif pour les objets qui n'implémentent pas l'interface IDisposable.

ben étant donné que je ne pouvais pas faire new Interval() (alors que ça passe en OCaml), je pensais qu'il fallait continuer de préciser le 'a

Envoyé par LLB

Code :

peut s'écrire

Code :

let res = Interval(Down = foo, Up = bar)

effectivement, ça simplifie beaucoup

Envoyé par LLB

Le coding-style .NET utilise des noms comme "MatchValue" plutôt que "match_value" pour toutes les méthodes.

je préfère matchValue

Envoyé par LLB

Printf.sprintf "%A" est équivalent à la fonction any_to_string.

effectivement, ça aide... (et ça enrichit ma liste de mots-clés pour jEdit )

[LLB]

Envoyé par gorgonite

ça ne veut pas sur le type_inf

J'imagine que ta version de F# date un peu.

je ne sais pas comment en OCaml ça aurait réagi avec des types non comparables... j'attendais donc pour imposer une "interface" à ce type

Comment ça ? Tu utilisais les opérateurs > et <. min et max se comportent de la même façon.

effectivement, ça simplifie beaucoup

Et par la même occasion :

Code :

1
2
let res = Interval(Up=Type(min mx max_i))
res

peut se simplifier en

Code :

Interval(Up=Type(min mx max_i))

[gorgonite]

Envoyé par LLB

J'imagine que ta version de F# date un peu.

FSharp-1.9.3.7 qui date de fin 2007, si mes souvenirs sont bons

il y a une 1-9.4.* sorti début mai 2008, mais elle ne marche pas avec mono, une dll est foireuse... il aurait fallu que je récupère celle du msi, mais j'ai pas encore eu le temps de mettre à jour mon F# sous Visual Studio

Envoyé par LLB

Comment ça ? Tu utilisais les opérateurs > et <. min et max se comportent de la même façon.

ça m'aurait obligé à refaire tout proprement... je ne suis pas satisfait de l'ergonomie de cette classe côté utilisation dans un analyseur

Envoyé par LLB

Et par la même occasion :

Code :

peut se simplifier en

Code :

Interval(Up=Type(min mx max_i))

effectivement, à force de simplifier, on pense pas à regarder le cas trivial

[LLB]

Je ne me suis pas plongé dans ton code au niveau algo, mais je suis convaincu qu'on peut le faire beaucoup plus court.

Tu peux commencer par déclarer ton type de cette façon :

Code :

1
2
type 'a type_inf =
  MinInf | Type of 'a | MaxInf

Cela permet d'avoir les opérateurs de comparaison qui fonctionnent de façon intuitive.

En Caml, cette astuce ne fonctionne pas. Même sans connaitre ça, tu aurais pu au moins écrire une fonction de comparaison sur les type_inf, ça aurait beaucoup réduit ton code.

J'aurais tendance (à un check près) à écrire la méthode intersect de cette façon :

Code :

1
2
3
  member obj.intersect (i: 'a interval) =
      Interval(Down = max obj.Down a.Down,
                 Up = min obj.Up a.Up)

Pareil pour l'inclusion et le check.

J'ai aussi tendance à préférer du code fonctionnel pour pour ce genre de besoins. En utilisant un classique type somme et les outils de comparaison, ton code n'aura plus rien à envier au code Caml de SpaceGuid.

[gorgonite]

Merci pour l'astuce de l'ordre de déclaration du type somme... ça simplifie énormement d'un coup
(du coup, ça devient plus concis que la template C++ que j'utilise, et aussi sur que la classe OCaml que j'avais faite)

Envoyé par LLB

En utilisant un classique type somme et les outils de comparaison, ton code n'aura plus rien à envier au code Caml de SpaceGuid.

Le hic est que mon analyseur va aussi utiliser des structures plus complexes... en gros pas mal de polyèdres, l'intervalle n'étant que l'approximation la plus simple à coder. Je vais donc passer par une interface, mais j'attendais d'avoir une classe bien définie

je ne suis pas sûr de pouvoir faire cela en "fonctionnel pur" sans passer par une notion d'objet

[LLB]

Envoyé par gorgonite

Le hic est que mon analyseur va aussi utiliser des structures plus complexes... en gros pas mal de polyèdres, l'intervalle n'étant que l'approximation la plus simple à coder. Je vais donc passer par une interface, mais j'attendais d'avoir une classe bien définie

je ne suis pas sûr de pouvoir faire cela en "fonctionnel pur" sans passer par une notion d'objet

Je pensais surtout à éviter les effets de bords. Par exemple, quelque chose comme :

Code F# :

1
2
3
4
5
6
7
8
9
10
11
12
type 'a Interval(?up, ?down) =
    let down, up : 'a type_inf * 'a type_inf =
        let down = defaultArg down MinInf
        let up = defaultArg up MaxInf
        if up < down then MaxInf, MinInf
        else down, up

    member i.Up = up
    member i.Down = down

    member i.Intersect (int: 'a Interval) =
        Interval(max i.Down int.Down, min i.Up int.Up)

Les arguments optionnels peuvent aussi être nommés (tu gardes donc la possibilité de faire Interval(down = ..., up = ...)). J'ai mis le check dans le constructeur, ce qui garantit que tout Interval est valide.

Mais ton nouveau code est plutôt pas mal aussi, les effets de bords sont bien cachés.

[gorgonite]

Envoyé par LLB

Les arguments optionnels peuvent aussi être nommés (tu gardes donc la possibilité de faire Interval(down = ..., up = ...)). J'ai mis le check dans le constructeur, ce qui garantit que tout Interval est valide.

je fais y refléchir... faut que j'assimile les détails (et relise la doc )

une question, pour le moment les attributs Low (pas Down ) et Up ne sont qu'en lecture seule dans ta version ou j'ai loupé un détail ?

Envoyé par LLB

Mais ton nouveau code est plutôt pas mal aussi, les effets de bords sont bien cachés.

ma première version était surtout une version simplifiée d'une template C++ qu'on utilise dans le vrai projet, à laquelle j'avais ajoutée le pattern-matching pour être sûr de bien traiter tous les cas

[LLB]

Envoyé par gorgonite

une question, pour le moment les attributs Low (pas Down ) et Up ne sont qu'en lecture seule dans ta version ou j'ai loupé un détail ?

Oui, ils sont en lecture seule. J'évite en géneral tous les effets de bords qui ne sont pas nécessaires.

Mais ton code est bien aussi, tu peux le garder (et il est plus intuitif pour un développeur C#).

[gorgonite]

Envoyé par LLB

Oui, ils sont en lecture seule. J'évite en géneral tous les effets de bords qui ne sont pas nécessaires.

Mais ton code est bien aussi, tu peux le garder (et il est plus intuitif pour un développeur C#).

effectivement, si l'on se décide à migrer, on va sans doute commencer par convertir pas mal de code C++ en C# (car on n'est pas sûr que tout passe avec C++/CLI) ; je ne sais pas quelle proportion sera convertie en F#

Envoyé par gorgonite

effectivement, si l'on se décide à migrer, on va sans doute commencer par convertir pas mal de code C++ en C# (car on n'est pas sûr que tout passe avec C++/CLI) ; je ne sais pas quelle proportion sera convertie en F#

Pourtant un langage ML pour faire de l'analyse statique, c'est quand même un vrai bonheur ! Après, je ne sais pas à quel point l'absence de foncteur de F# (c'est toujours le cas ?) peut être dommageable dans ce cas

[gorgonite]

Envoyé par alex_pi

Pourtant un langage ML pour faire de l'analyse statique, c'est quand même un vrai bonheur ! Après, je ne sais pas à quel point l'absence de foncteur de F# (c'est toujours le cas ?) peut être dommageable dans ce cas

ben disons qu'on a besoin de pas mal de perfs sur certains morceaux, et C++/CLI ou C# seront sans doute plus adaptés... mais on fera des tests bien évidemment

je ne suis pas sûr qu'on ne puisse pas faire des foncteurs (ou quelque chose de proche) avec un couplage module/classe... faudra que je revois mes cours de sémantique, mais il ya certainement une transformation de l'un vers l'autre (tout comme des transformations exception -> pas d'exception, etc)