Discussion :

[RosaliMiriam]

Bonjour,

j'ai deux questions concernants plus ou moins la syntaxe de caml:

(1)
Dans une fonction, je voudrais écrire qqc comme:

if a=1 then j=w else j=v

et après je travaille avec j.

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
17
18
19
 
type lapin = {dy : int; adn : (int*int) list;};;
 
let etape l = 
  match l with
    |  [] -> None
    | (a,b)::ll ->
	if a = 1 
	  then let j = ll in
	    let l' = {dy = b; adn = j} in
              if l'.dy < 0 || l'.dy > 1000 
	        then None
	      else Some l'
	else let j = (a-1,b)::ll in
	  let l' = {dy = b; adn = j} in
            if l'.dy < 0 || l'.dy > 1000 
	      then None
	    else Some l'
;;

J'ai pas trouvé d'autre solution que redoubler le code. Qu'est-ce que je peux faire pour que j ne soit plus local dans le bloc?


(2)
En utilisant Graphics, dans une fonction, je voudrais faire les étapes suivantes:

set_color white
fill_circle (fst p.pos) (snd p.pos) 3
set_color black
fill_circle (fst x.pos) (snd x.pos) 3

Comment est-ce que je pourrais lier les quatre étapes? J'ai déjà essayé and et in...

Merci d'avance, et je m'excuse pour mes fautes de langue.

[Jedai]

(1)

Code :

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

let j = (if a = 1 then w else v) in ...

(2)

Code :

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

1
2
3
4
5
6
begin
  set_color white;
  fill_circle (fst p.pos) (snd p.pos) 3;
  set_color black;
  fill_circle (fst x.pos) (snd x.pos) 3;
end

(tu peux utiliser de simple parenthèses à la place de begin et end, mais parfois c'est plus clair avec les mots clés, question de goût)

--
Jedaï

[alex_pi]

La sytaxe let x = v in e est peut être peu conventionnel dans le monde des langages de programmation "mainstream", mais elle a tout de même un gros avantage : On voit facilement la portée de la variable x. C'est exactement e.
Donc quand tu écris

Code :

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

1
2
3
4
5
 
if cond then
  let y = v1 in e1
else
  let y = v2 in e2

dans e1, la variable y vaut v1, et dans e2, une autre variable y vaut v2. En revanche, dès que tu sors du if ... then ... else ..., il n'y a plus de variable y !

[Alp]

Il y a quelque chose d'équivalent, mais qui ne marche pas dans toutes les distributions OCaml :

Code :

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

let x = y + 1 where y = 2;;

Le where c'est équivalent au "in" sauf que la syntaxe c'est let x = e where v, autrement on "inverse" l'expression e et la variable v, et on remplace in par where.

Je crois que ça passe sous Caml Light, mais OCaml non.

[SpiceGuid]

Il y a une règle très simple à propos du where en Caml: n'utilisez jamais where en Caml.
(problème de portabilité et problème de lisibilité de la portée)

[gasche]

Je ne suis pas convaincu, et d'ailleurs j'apprécie assez where pour avoir codé une extension (pas encore complètement satisfaisante) syntaxique pour OCaml : pa_where.

Bien sûr, where apporte des possibilités d'ambiguités (si on l'utilise à l'excès avec une indentation volontairement fourbe, ça peut faire des chocapics), et c'est au programmeur de faire attention. Le confort (en lecture comme en écriture) apporté le récompensera de ce petit effort.

[Alp]

Je ne suis pas convaincu, et d'ailleurs j'apprécie assez where pour avoir codé une extension (pas encore complètement satisfaisante) syntaxique pour OCaml : pa_where.

Bien sûr, where apporte des possibilités d'ambiguités (si on l'utilise à l'excès avec une indentation volontairement fourbe, ça peut faire des chocapics), et c'est au programmeur de faire attention. Le confort (en lecture comme en écriture) apporté le récompensera de ce petit effort.

Oui. Le seul truc que je trouve dommage c'est que ça ne soit pas portable.

[alex_pi]

Oui. Le seul truc que je trouve dommage c'est que ça ne soit pas portable.

Comment ça pas portable ?? OCaml et CamlLight ne sont pas le même langage...

[Alp]

Oui, mais OCaml permet notamment le Caml non ?

[InOCamlWeTrust]

Il faut juste changer quelques trucs dans le code. Des changements minimes, mais qui sont là. Le where en est un.

[Alp]

Je sais bien. Quand j'ai fait mes premiers pas en OCaml, j'ai récupéré puis testé (et ensuite modifié) un code utilisant where. Je me suis pris une erreur
J'ai finalement compris que c'était le where qui n'allait pas et que le "let ... in" était la solution en OCaml.

[InOCamlWeTrust]

La syntaxe révisée de Daniel de Rauglaudre conserve le where mais pour un seul binding, à la différence du let ... and ... and ... in ....

[gasche]

Mais la syntaxe révisée a d'autres inconvénients (et d'autres avantages), et le fait de ne pouvoir faire qu'un seul binding est tout de même une énorme limitation. En Haskell ils utilisent des where avec plusieurs déclarations tout le temps, donc c'est qu'il y a un besoin.

[InOCamlWeTrust]

Question de goût, et non de besoin. Moi, quand je lis du Haskell, je trouve chelou de me retrouver nez à nez avec des identificateurs qui n'ont pas été introduits.

[SpiceGuid]

C'est pas chelou, c'est 'paresseux'

[gasche]

Moi je trouve que c'est à utiliser avec modération, mais quand c'est pas trop mal utilisé c'est vraiment agréable. Par exemple (tiré d'un code qui se promène sur mon DD) :

Code OCaml :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
let context_table =
    ["let", Let; "type", Type; "module", Module; "class", Class;
     "if", If; "then", Then; "else", Else;
     "for", For; "while", While;
     "match", Match; "try", Try;
     "with", With; "with", With_fields; "function", Function; "fun", Fun
     (* missing : Top, With_fields, Body, TBody, Infix *) ]
    @ List.map (fun (op, cl) -> op, Paren(op, cl)) paren_table
    @ List.map (fun (op, cl) -> op, Begin(op, cl)) begin_table
  where paren_table =
    ["(",")"; "{","}"; "[","]"; "[|","|]"]
  and begin_table =
    ["begin","end"; "struct","end"; "sig","end";
     "object","end"; "do","done"]

On pourrait très bien faire ça avec un let, mais je pense qu'on perdrait en lisibilité puisque "paren_table" n'a pas de justification intrinsèque tant qu'on n'essaie pas de définir context-table, et qu'il est plus agréable de commencer par lire le contenu de context-table avant les déclarations auxiliaires. De plus, la relative lisibilité des identifieurs rejetés en "where position" font qu'on ne s'affole pas à l'idée de ne pas les voir : quand on voit "paren_table" dans ce contexte, on se doute bien de ce que cela contient, que l'indentifieur soit définit avant ou après, ça ne perturbe pas.