Discussion :

[Garulfo]

Que je ne maîtrisais pas bien par ailleurs -_-

Donc voici mon problème, voyez vous même :

Code :

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

1
2
3
4
5
6
7
8
9
10
# open Ebs_parser ;;
# get_from_file ;;
- : file_name:string ->
    ((Lexing.lexbuf -> Ebs_parser_rules.token) -> Lexing.lexbuf -> 'a) -> 'a
= <fun>
# let fn = "spec.txt" ;;
val fn : string = "spec.txt"
# let f = get_from_file fn ;;
This expression has type string but is here used with type
  (Lexing.lexbuf -> Ebs_parser_rules.token) -> Lexing.lexbuf -> 'a

Le typage de la fonction get_from_file dit bien qu'elle prend une string en premier argument. La variable fn (pour filename) est bien une string.
Alors pourquoi m'emmerde-t-il pour la définition de f !?

Au cas où ça peut aider

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
let get_from from parser_entry_rules =
    let raw = let s = ref ""
              in try while true do s := (!s ^ (input_line from) ^ "\n") done ; ""
                 with End_of_file -> !s
    in let raw_spec = Lexing.from_string raw 
    in parser_entry_rules Ebs_lexer_rules.token raw_spec
;;

let get_from_file ~file_name per = let ic = open_in file_name
                                   in let result = get_from ic per 
                                      in begin
                                         close_in ic ;
                                         result
                                         end
;;

[LLB]

C'est un argument nommé !

Je suis d'accord pour dire que le comportement n'est pas très intuitif ici. Pour simplifier, il vaut mieux que tu nommes l'argument quand tu appelles la fonction.

Code :

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

1
2
3
4
5
6
7
8
# let f ~x y = x+1, y+.1.;;
val f : x:int -> float -> int * float = <fun>
# f 2;;
This expression has type int but is here used with type float
# f ~x:2;;
- : float -> int * float = <fun>
# let foo y = f 2 y;;
val foo : float -> int * float = <fun>

Pour info, ce code n'est pas compatible F#. F# a une syntaxe et des règles différentes.


Si tu réfléchis un peu au problème, tu verras que combiner les arguments nommés (on peut ensuite les mettre dans n'importe quel ordre au moment de l'appel), les arguments anonymes et l'application partielle, fait que l'inférence de type est difficile à réaliser. En général, il faut soit nommer les arguments, soit tous les donner.

[Garulfo]

J'ai fini par comprendre que ça venait de là car une fois enlevé, tout va bien.

C'est la première fois qu'il me fait ça -_-
C'est la première fois par contre que je ne mets qu'une étiquette.

Pourquoi fait-il ça tout d'un coup ?!

Dans ce genre de code je n'ai jamais eu de problème.

Code :

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

1
2
3
4
let translation_directe ~x ~y ~z = ([|[| 1.; 0.; 0.; x  |];
                                      [| 0.; 1.; 0.; y  |];
                                      [| 0.; 0.; 1.; z  |];
                                      [| 0.; 0.; 0.; 1. |]|] : matrice)

Sais-tu pourquoi ?
Ce n'est pas bien documenté ça hélas.

[LLB]

J'ai édité mon message, je ne sais pas si tu as tout lu.

Le problème vient du mélange arguments nommés et application partielle. Si tu donnes tous les arguments, il s'en sort bien. S'ils n'y sont pas tous, je crois qu'il commence par ceux qui ne sont pas nommés.

[Garulfo]

Bon je viens de voir qu'il faut que l'application soit totale pour qu'il n'y ait pas besoin de nommer les variables. Je ne comprends pas bien car je ne l'ai utilisé (dans mon programme, pas dans l'exemple) qu'en application totale. Menfinbon.

[EDIT] !!! Ahhh non j'ai compris. Effectivement en remontant plus loin, ce n'était pas total, mais partiel [/EDIT]

Merci encore ^_^

[InOCamlWeTrust]

Il y a l'option -nolabels du compilateur pour ne pas prendre en compte les labels, mais pouvoir les inclure dans le code source... pratique si tu ne veux que documenter/annoter le code source. Ahhhh ! les T.I.P.E., que de souvenirs !

Autre chose : pour les labels, pour savoir comment ça marche, il n'y a qu'une seule source complète. Je te laisse deviner ?

[Garulfo]

Il y a l'option -nolabels du compilateur pour ne pas prendre en compte les labels, mais pouvoir les inclure dans le code source... pratique si tu ne veux que documenter/annoter le code source. Ahhhh ! les T.I.P.E., que de souvenirs !

Autre chose : pour les labels, pour savoir comment ça marche, il n'y a qu'une seule source complète. Je te laisse deviner ?

Oui je me doute bien qu'on peut aller mettre son nez dans les source... Menfinbon : on s'entend que parfois on aimerait avoir une doc plus « disponible »

En tout cas, merci pour ta remarque car pour moi, le but du label est surtout de documenter mon code.

[InOCamlWeTrust]

Non, là je parlais pas des sources, mais du manuel de référence, tout de même un peu plus clair .