Discussion :

[bm]

Est ce que avec un langage fonctionnel comme Caml , c'est possible
d'ajouter dans les programmes des lignes de commentaires ?

// ---- Passe avec Matlab



// --- Ne passe pas avec Caml

Aplus

[Twinside]

les commentaires en caml ont la syntaxe suivante :
(* commentaire *)

c'est différent de la plupart des langages, mais on s'y fait, surtout qu'on peut imbriquer les commentaires (ce qui n'est pas possible avec les commentaires multiligne du C par exemple), ce qui est bien pratique par moment.

Malheureusement pas de commentaire mono ligne à ma connaissance

[InOCamlWeTrust]

Tiens... ça serait une idée pour faire un module en Camlp4 : permettre à un code source d'avoir des commentaires sur une seule ligne. Ou pourquoi pas, implanter une sorte de Literate OCaml...

Personnellement, je préférerais quelque chose à la Haskell, plus élégant.

Code :

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

1
2
3
4
5
6
7
 
-- un commentaire sur une seule ligne
-- un deuxième commentaire sur une seule ligne
 
let a = 5 in
 
print_inr a

[LLB]

La syntaxe la plus fréquente est // (que F# supporte), mais ça fait un conflit avec la division sur les grands nombres. La syntaxe # est tout aussi (voire plus) fréquente (cf she-bang), mais c'est gênant pour l'objet. Si on veut garder un syntaxe "standard" (utilisée dans d'autres langages), il n'y a plus beaucoup de choix : le point-virgule du Lisp poserait autant de problèmes.

Il ne reste plus que le "--" (Ada, Haskell, Eiffel, Lua...) et le "%" (Erlang, Oz, Tex...). Je n'aime pas trop ces deux, puisqu'il est parfois pratique de les définir comme des opérateurs. Mais c'est sans doute la meilleure solution. Ca me semble en effet utile de pouvoir faire des commentaires sur une ligne.

[SpiceGuid]

Il ne reste plus que le "--" (Ada, Haskell, Eiffel, Lua...)

C'est souvent l'opérateur de soustraction sur les grands nombres, donc ça poserait le même conflit que "//".

Perso j'ai défini une macro pour Crimson Editor qui me met la ligne en commentaire. Ce genre de questions cosmétiques n'est ni du ressort du langage, ni du ressort du préprocesseur, c'est le boulot de l'éditeur de code. Si le votre n'est pas assez puissant changez-en.

[LLB]

C'est souvent l'opérateur de soustraction sur les grands nombres, donc ça poserait le même conflit que "//".

Pour le type Num, c'est "-/". J'ai fait un grep "--" dans le répertoire Caml, je n'ai rien trouvé.

Ce genre de questions cosmétiques n'est ni du ressort du langage, ni du ressort du préprocesseur, c'est le boulot de l'éditeur de code.

Je n'ai pas d'avis arrêté sur la question. Des langages comme le C++ ont ajouté les commentaires sur une ligne, mais c'est surtout parce que les commentaires de blocs ne s'imbriquent comme en Caml. Mais, je trouve parfois un intérêt au commentaire sur une ligne. Un exemple d'utilisation, quand certains blocs doivent fréquemment être (dé)commentés :

Code :

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

1
2
3
4
 
(* commenter cette ligne pour activer le code suivant
let test() = code optionnel - tests, etc...
// *)

En C, on pourrait mettre un "#if 0".

L'avantage aussi est d'être moins dépendant de son éditeur (je te rassure, mon Emacs est largement assez puissant), et en l'absence de coloration syntaxique, le commentaire sur une ligne est utile pour la lisibilité. Je suis quand même d'accord : ce n'est pas très important ; mais je ne peux m'empêcher de trouver ça agréable quand un langage me le propose.

[SpiceGuid]

Dans la bibliothèque Numérix de Michel Quercia, extrait de code:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
module Infixes(E : Int_type) : sig
  open E
  val ( ++ ) : t -> t -> t (* add *)
  val ( -- ) : t -> t -> t (* sub *)
  val ( ** ) : t -> t -> t (* mul *)
  val ( // ) : t -> t -> t (* quo *)
  val ( %% ) : t -> t -> t (* modulo *)
  val ( /% ) : t -> t -> t*t (* quomod *)
  val ( << ) : t -> int -> t (* shl *)
  val ( >> ) : t -> int -> t (* shr *)
  val ( ^^ ) : t -> int -> t (* pow *)
  ...

[bm]

Ocaml est le produit d'un consorsium ...

( Dassaut , Microsoft , ... ) , si c'est pas trop demander sur ce forum , quelle réalisation de taille industrielle est implémentée en Ocaml ?

Est ce la conception 3D avec SolidWorks et Autocad ?

[SpiceGuid]

Tu veux ajouter des lignes de commentaire à échelle industrielle ?
J'y avais pas pensé mais ça doit pouvoir se faire.

[InOCamlWeTrust]

Il y a déjà OCaml lui-même ! Puis il y a Coq, entièrement écrit en OCaml et très utilisé pour les systèmes critiques. Xavier Leroy travaille actuellement sur la preuve Coq d'un compilateur C-- certifié... donc là aussi, c'est, de façonb indircte de l'OCaml.

Sur la page de présentation, il y a une succes-story : tu retrouves entre autres le langage de Lexifi...

http://caml.inria.fr/about/successes.en.html

Pour le reste, il est très difficile de dire, étant donné qu'il existe de très nombreux projets réalisés en interne : il n'est d'ailleurs pas impossible que Dassault utilise OCaml pour concevoir des avions ou encore pour écrire des parties de leur caca Catia... mais il n'est pas impossible aussi qu'il s'agisse uniquement d'une participation financière, étant donné que Dassault est très présent à l'INRIA (Rocquencourt).

[alex_pi]

Il y a déjà OCaml lui-même ! Puis il y a Coq, entièrement écrit en OCaml et très utilisé pour les systèmes critiques.

Je précise que Coq est partiellement écrit en Coq (bootstrapé), mais ça n'a rien à voir avec le schimilibili

[bm]

Vu la taille des A 380 , toutes les commandes passent par un calculateur . Les commandes pneumatique étaient déjà limite sur les A 320 pour réduire la portance au décollage , l'avion roulait trop vite .

Sans les coups de bélier du pneumatique , faut pas que la mécanique des volets coince aussi à l'atterrissage . En phase d'approche le freinage repose sur le gain de portance des volets .

[Steki-kun]

Ou pourquoi pas, implanter une sorte de Literate OCaml...

Il existe OCamlweb pour ça

http://www.lri.fr/~filliatr/ocamlweb/index.fr.html

C'est pas CWeb mais en première approximation c'est déjà pas mal

Et pour revenir au sujet du topic, j'avoue ne pas comprendre le besoin pour des lignes de commentaire : qui peut le plus peut le moins, et dans n'importe quel éditeur un tant soit peu évolué (ou évoluable ), on (dé)commente tout aussi vite une ligne avec des (* .. *) qu'avec un -- ou un // non ? Y a-t-il un autre avantage des commentaires de ligne sur les commentaires encadrés ?

[InOCamlWeTrust]

Oui : on n'oublie pas de les fermer !

[SpiceGuid]

Impossible d'oublier d'en fermer un: si je ne ferme pas un commentaire tout le code passe en vert.
C'est une question d'éditeur, de macros, de coloration syntaxique...
Bref, configurez votre environnement de développement selons vos besoins.

[LLB]

Sous Emacs : M-; pour faire un commentaire. Si du texte est sélectionné (et à condition que le mode transient-mark soit activé), M-; commente la zone. Ca marche pour tous les langages. Tu ne devrais donc jamais à avoir à taper (* ou *) à la main.

Pour tous les autres éditeurs décents, on doit pouvoir trouver des raccourcis similaires.

[InOCamlWeTrust]

Impossible d'oublier d'en fermer un: si je ne ferme pas un commentaire tout le code passe en vert.
C'est une question d'éditeur, de macros, de coloration syntaxique...
Bref, configurez votre environnement de développement selons vos besoins.

C'est justement l'un des points qui buge traditionnellement le plus dans les éditeurs de texte, même avec Emacs !

[Steki-kun]

Ca je le reconnais volontiers, il faut même assez souvent désactiver le font-lock et le remettre pour revenir à une coloration correcte

Mais je crois que LLB a bien résumé le fond de ma pensée : jamais je ne *tape* moi-même une parenthèse suivie d'une *, donc je risque pas d'oublier sa petite copine à la fin de la ligne ou du paragraphe
Perso, chez moi F2 (resp. F3) commente (resp. décommente) la région s'il y en a une de sélectionnée, et la ligne courante sinon. Chacun son truc mais je ne ressens pas un besoin pour autre chose.