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
next prev parent 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).