Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] single-line comment request
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Chris Hecker <checker@d...>
Subject: Re: [Caml-list] single-line comment request

> > 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