From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA23678; Tue, 8 Apr 2003 21:00:44 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA23751 for ; Tue, 8 Apr 2003 21:00:42 +0200 (MET DST) Received: from epexch01.qlogic.org ([63.170.40.3]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h38J0e900789 for ; Tue, 8 Apr 2003 21:00:41 +0200 (MET DST) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Apr 2003 14:00:53 -0500 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Tue, 8 Apr 2003 14:00:52 -0500 Date: Tue, 8 Apr 2003 14:04:14 -0500 (CDT) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: Chris Hecker cc: Brian Hurt , Nickolay Semyonov-Kolchin , Ocaml Mailing List Subject: Re: [Caml-list] single-line comment request In-Reply-To: <4.3.2.7.2.20030408110617.0389bde8@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 08 Apr 2003 19:00:52.0786 (UTC) FILETIME=[2D473920:01C2FE01] X-Spam: no; 0.00; qlogic:01 caml-list:01 hecker:01 noticeably:01 gratuitous:01 joking:01 multiline:01 typer:01 nontrivial:01 avoiding:01 chris:01 -bit:01 ints:01 ocaml:01 caml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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