From: Pierre Weis <Pierre.Weis@inria.fr>
To: Xavier.Leroy@inria.fr (Xavier Leroy)
Cc: caml-list@inria.fr
Subject: Re: per-line comments
Date: Tue, 23 Jun 1998 02:24:23 +0200 (MET DST) [thread overview]
Message-ID: <199806230024.CAA20345@pauillac.inria.fr> (raw)
In-Reply-To: <19980622105117.39832@pauillac.inria.fr> from "Xavier Leroy" at Jun 22, 98 10:51:17 am
[French abstract ahead]
> Caml's comment syntax is more a question of historical tradition than
> personal tastes. After all, the comment syntax is perhaps the only
> bit of syntax that hasn't changed between LCF ML, Caml, and Standard ML...
Even this bit of syntax has changed: LCF ML comments where % blabla %
> > but many good programmers use this
> > extensively in their in-line documentation.
>
> I don't quite get the point about in-line documentation. I write
> perfectly fine on-line documentation between (* and *). Why would it
> be any better with // or -- ?
Right. But many programmers feel it simpler to end the comment with a
carriage return (if not for the historical trick of being able to put
a new instruction after the comment and to reuse the same card upface
down! This is a dinosaure's story from the good old time of real
computers that knew the meaning of a column :)
> At any rate, the main problem with per-line comments (as with most
> syntax extension) is that they need a reserved symbol. Both // and --
> are valid OCaml infix identifiers; // is even used in the Num standard
> library module.
Perfectly exact and pertinent. Even the (* delimitor is a problem when
you want to name operators, since (+), (-), (/) work perfectly but you
must use extra spaces for the multiplication.
However, the old meaning of % in old LCF ML, was carried to Caml, and
may be for this historical reason the % character is not in the
list of operators for Caml Light or O'Caml. Thus it is usable as a
comment delimitor, if not more useful for another purpose.
In addition, per-line comments can be a simple way to have comments that are
``free style'' comments, as opposed to the actual comments that must
be a suite of lexically correct tokens.
Thus it is possible to add per-line comments, but Xavier pointed out
the main problem: is it desirable to add this feature to the langage?
[Résumé en Français]
Xavier a raison: -- et // sont déjà pris. D'ailleurs (* pose déjà un
problème avec la syntaxe des opérateurs infixes (il faut écrire ( * )
pour la multiplication alors que ces blancs sont non nécessaires pour
les autres opérateurs). Ceci dit % est inutilisé (et il a toujours
signifié début de commentaire depuis le début de ML et même en Caml
jusqu'à 1991) et pourrait servir à faire des commentaires uni-lignes
(et à l'occasion des commentaires qui ne sont pas une suite de lexèmes
valides du langage). Mais est-ce vraiment nécessaire ?
Pierre Weis
INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/
next prev parent reply other threads:[~1998-06-23 0:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-06-17 13:17 are initial values in class fields mandatory ? (ocaml) fbesnard
1998-06-18 2:05 ` Donald Syme
1998-06-22 8:51 ` per-line comments Xavier Leroy
1998-06-23 0:24 ` Pierre Weis [this message]
1998-06-18 6:40 ` are initial values in class fields mandatory ? (ocaml) Francois Pessaux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199806230024.CAA20345@pauillac.inria.fr \
--to=pierre.weis@inria.fr \
--cc=Xavier.Leroy@inria.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox