caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Chris Hecker <checker@d6.com>
To: Brian Hurt <brian.hurt@qlogic.com>
Cc: Nickolay Semyonov-Kolchin <snob@snob.spb.ru>,
	Brian Hurt <brian.hurt@qlogic.com>, <caml-list@inria.fr>
Subject: Re: [Caml-list] single-line comment request
Date: Tue, 08 Apr 2003 11:23:12 -0800	[thread overview]
Message-ID: <4.3.2.7.2.20030408110617.0389bde8@localhost> (raw)
In-Reply-To: <Pine.LNX.4.33.0304081154300.2225-100000@eagle.ancor.com>


> > Actually, just to fuel the fire, it's not just stylish.  Single-line
> > comments are sometimes easier to work with programmatically
>Not noticeably in my experience.

Hmm, well I guess I have different experiences from you on this front.

This is starting to become a "you don't need that" argument.  The backwards 
compatibility argument is the only one you've given that has any actual 
technical objectivity behind it, and it's pretty weak because almost every 
iteration of caml isn't backwards compatible (if not in core language, then 
library functions, etc.) and I want it that way and think they should 
accelerate that.  Much better to get changes out of the way now than later 
when caml is more popular.

As for editor macros and parsing, I'm familiar with my editor, thanks.  The 
point is you need to write no macros when doing a lot of operations with 
single line comments, versus having to write macros to handle things as 
easily with multiline.  That indicates a complexity for operations that you 
don't seem to acknowledge.  If you're at a different editor and don't have 
your macros, who's better off?  And, the macros are nontrivial in the cases 
of mixed length code and nested comments and whatnot.  A lot of operations 
are just more complicated with bracketed comments since you have to keep 
state [that standard regexs can't handle].  I don't see how you can argue 
the contrary.

There's really no downside that I can see to supporting them besides minor 
backwards compatibility (but hey, if you want to port back, just write an 
editor macro to convert them since you argue they're so easy! :), using 
another token, and somebody has to go implement them.  There are many minor 
upsides, including a bunch that haven't been listed like avoiding questions 
about this topic on the list, and matching people's intuition from C++, 
etc.  It seems like a clear win to me.

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2003-04-08 18:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-08 12:56 Nickolay Semyonov-Kolchin
2003-04-08 15:17 ` Samuel Lacas
2003-04-08 14:27   ` Nickolay Semyonov-Kolchin
2003-04-08 16:21     ` Samuel Lacas
2003-04-09 15:15   ` Thierry SALSET
2003-04-08 15:19 ` Brian Hurt
2003-04-08 14:25   ` Nickolay Semyonov-Kolchin
2003-04-08 16:08     ` Brian Hurt
2003-04-08 15:38       ` Nickolay Semyonov-Kolchin
2003-04-08 17:42         ` Brian Hurt
2003-04-08 17:31     ` Chris Hecker
2003-04-08 16:29       ` Nickolay Semyonov-Kolchin
2003-04-08 19:26         ` Basile STARYNKEVITCH
2003-04-08 20:22           ` Brian Hurt
2003-04-08 21:37             ` Michal Moskal
2003-04-08 17:13       ` Brian Hurt
2003-04-08 19:23         ` Chris Hecker [this message]
2003-04-08 18:49           ` Karl Zilles
2003-04-08 19:04           ` Brian Hurt
2003-04-08 21:57             ` Daniel Andor
2003-04-08 22:07               ` Michal Moskal
2003-04-08 22:09               ` Brian Hurt
2003-04-10  2:59                 ` cashin
2003-04-10  7:58                   ` [Caml-list] { ... } vs ( ... ) vs begin ... end Frederic van der Plancke
2003-04-08 19:42           ` [Caml-list] single-line comment request Daniel M. Albro
2003-04-08 18:53             ` Alexander V. Voinov
2003-04-08 18:19               ` Nickolay Semyonov-Kolchin
2003-04-08 22:40             ` Joshua Scholar
2003-04-13 19:46             ` Andreas Rossberg
2003-04-13 22:57               ` Daniel M. Albro
2003-04-08 19:53           ` Jeff Henrikson
2003-04-08 20:31             ` Brian Hurt
2003-04-13 14:07     ` John Max Skaller
2003-04-08 15:28 ` Damien
2003-04-08 14:49   ` Nickolay Semyonov-Kolchin
2003-04-08 15:39   ` Brian Hurt
2003-04-08 15:45   ` malc
2003-04-08 15:45   ` Samuel Lacas

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=4.3.2.7.2.20030408110617.0389bde8@localhost \
    --to=checker@d6.com \
    --cc=brian.hurt@qlogic.com \
    --cc=caml-list@inria.fr \
    --cc=snob@snob.spb.ru \
    /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;
as well as URLs for NNTP newsgroup(s).