Re: [Caml-list] single-line comment request

[Brian Hurt <brian.hurt@qlogic.com>]

On Tue, 8 Apr 2003, Chris Hecker wrote:

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

No, it's a "this doesn't give us anything" argument.  Well, except for a) 
it saves having to type three whole extra characters in single line 
comments, and b) it shuts up the people who demand single-line comments.

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

If we're going to be introducing gratuitous backwards incompatiblities, 
can we please do it for something usefull?  Like say replacing begin/end 
with { and }.  This would be incredibly usefull, allowing vi users to yank 
and put whole code branchs with y% and d%.  Of course, we'd need a new 
syntax for structures.  But hey, it's all just cosmetic changes anyways- 
just use an awk script if you need to back port.

I'm half joking here, but only half.

As for having arguments with technical objectivity, I'll agree they've 
been light on the ground.  Backwards compatibility is the only one I've 
seen/made against.  Saving the three keystrokes is the only one I've 
see in favor.

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

Bwuh?  What macros do you need?  Oh sorry.  Yes, if you want to save those 
last three keystrokes.  Generally not worth the effort.

Maybe this is my problem.  I'm a fast enough typer that another 2-3 
characters aren't even noticed.  Not to mention the fact that in my 
experience programmers spend more time not typing than they do typing.  So 
I don't bother to macroize anything.  Maybe you could give me some 
examples?

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

I program in so many different languages that I don't bother to have
special macros for any of them.

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

So are we arguing that we should do away with (* *) comments?  Because as 
long as (* *) still exists in the language, you have to deal with these 
problems anyways.

> 
> 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! :), 

Knowing the issue even exists is 99% of the problem.

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

Ocaml is such a fundamentally radically different programming paradigm
from C++, that I don't think matching people's C++ intuitions (or Java
intuitions) is a benefit.  In fact, it might even be a detriment.  
Consider for a few seconds a.(i) <- 3 vr.s a[i] = 3.  Or 31-bit ints, for
that matter.

FAQs are how you deal with questions to the list.

Brian

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