From: Nicolas C. <war...@fr...> - 2003-02-28 03:28:31
Attachments:
extlib.mli
|
Hi list Here's most of the functions ( sorted by module ) that I been gathered from different mails here and there. There might me some mission functions but I tried to make the whole consisted and documented. You will see that I have included both Global and MList modules, since MList seems to be approved, and Global-like used by several people here. Please report any problem of understanding, naming convention, exception, usability.... on the list I think this is a good basis of work. Nicolas Cannasse |
From: Amit D. <adubey@CoLi.Uni-SB.DE> - 2003-02-28 16:53:43
|
Hi Everyone, Sorry for not participation in the discussion earlier, as I had a fairly tight deadline to work towards. I apologize if some of my comments (to come in the next few emails) may have already been discussed and decided against, as I haven't been able to read all of the messages this week. Thanks, Nicolas, for putting everyone's suggestions together. I have a couple of additions that I would like to suggest. To keep the discussion easy to follow for people who are new, or coming back after a bit (like me :), I'll reply to each module separately. -Amit |
From: Amit D. <adubey@CoLi.Uni-SB.DE> - 2003-02-28 17:03:06
|
> (* ****** Module ExtHash **** *) > > module ExtHash : > sig > > (* return all the keys of an Hashtable > if the key is several time in the Hashtable, the list will > contain it that many times *) > val keys : ('a,'b) Hashtbl.t -> 'a list > > (* return all the values of an Hashtable *) > val values : ('a,'b) Hashtbl.t -> 'b list > > (* remove all bindings for the given key *) > val remove_all : ('a,'b) Hashtbl.t -> 'a -> unit > > end I use hashtables extensively in my work, and there are two functions that I find invaluable. (The names, I admit, might be stupid :) (* return the element bound to the given key; if no such element exists, return a default value *) val find_always : ('a,'b) Hashtbl.t -> ~key : 'a -> ~default : 'b -> 'b val safe_find (* alternate name *) (* replace an old binding with a new one whose value depends on the old one. If no previous binding exists, use a default value *) val update : ('a, 'b) Hastbl.t -> ~key : 'a -> ~default : 'b -> ('b -> 'b) -> unit My primary use of hashtables is to store sparse arrays, which assume a value of `0.0' anywhere there is currently no binding. I'm not sure this is useful to people who don't use hashtables this way. -Amit |
From: Amit D. <adubey@CoLi.Uni-SB.DE> - 2003-02-28 17:20:26
|
I was about to reply about extentions to "Global", then I realized that it was not quite was I thought it was... I had been expecting a new pervasives, ooops :) The name ExtPervasives is misleading, because there functions are not "pervasive" in the truest sense, however the name does fit with the pattern Ext+OCaml core library name. I didn't document the obvious functions. module type ExtPervasives = sig (* SML-like names; other have suggested alternates: handling 'a options w/o match cases *) val val_of : 'a option -> 'a val is_some : 'a option -> bool val string_of_bool : bool -> string val print_bool : bool -> unit val prerr_bool : bool -> unit val output_int : out_channel -> int -> unit val output_float : out_channel -> float -> unit ...etc for basic types... end Also, although I don't have this, what do people think about: val input_int : in_channel -> int val input_float : in_channel -> float val input_string : in_channel -> string Which would have similar semantics to the C++ ">>" operators: whitespace delimits tokens, but is otherwise ignored, and line breaks are just another whitespace delimiter. -Amit |
From: Michal M. <mal...@pl...> - 2003-03-01 17:28:09
|
On Fri, Feb 28, 2003 at 06:19:21PM +0100, Amit Dubey wrote: > val output_int : out_channel -> int -> unit It's like: let output_int c i = Printf.fprintf c "%d" i ? Or maybe outputs binary representation? And output_float outputs with what precision? > val input_int : in_channel -> int I used this much writing code for programming contest: let input_int c = Scanf.fscanf c " %d" (fun x -> x) > val input_float : in_channel -> float > val input_string : in_channel -> string Didn't use these, but they can be probably usable in similar environments. -- : Michal Moskal ::::: malekith/at/pld-linux.org : GCS {C,UL}++++$ a? !tv : PLD Linux ::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h |
From: Nicolas C. <war...@fr...> - 2003-03-03 05:44:50
|
> The name ExtPervasives is misleading, because > there functions are not "pervasive" in the truest sense, > however the name does fit with the pattern Ext+OCaml core > library name. ExtStd is perhaps a better name > (* SML-like names; other have suggested alternates: > handling 'a options w/o match cases *) > val val_of : 'a option -> 'a > val is_some : 'a option -> bool I moved theses as well some functions sent previously by Olivier into a new module "Option" module Option : sig val may : ('a -> unit) -> 'a option -> unit val map : ('a -> 'b) -> 'a option -> 'b option val default : 'a -> 'a option -> 'a val is_some : 'a option -> bool val is_none : 'a option -> bool end > val string_of_bool : bool -> string this one already exists :) > val print_bool : bool -> unit > val prerr_bool : bool -> unit agree. ( When I agree and when it seems obvious that people will also agree, I'm automaticaly adding it to my local ExtLib file , and then later I 'll review it to do some commenting and renaming ) > val output_int : out_channel -> int -> unit > val output_float : out_channel -> float -> unit > ...etc for basic types... Too much verbose I think. Since most of the time you're printing mixed kind of values, fprintf is the best choice. I wouldn't like to promote such a programming style > Also, although I don't have this, what do people think about: > > val input_int : in_channel -> int > val input_float : in_channel -> float > val input_string : in_channel -> string > > Which would have similar semantics to the C++ ">>" operators: > whitespace delimits tokens, but is otherwise ignored, and line > breaks are just another whitespace delimiter. Same remark : use Scanf module ... or xml :) Nicolas Cannasse |
From: Manos R. <er...@cs...> - 2003-03-01 00:54:44
|
I don't know how other people feel, but to me, the short names in String (ftos, stoi, stof) look very ugly. String.to_float, String.to_int, and String.to_float seem much better, and more consistent with the choices in the standard library. An Int module with things like Int.of_string = int_of_string also sounds like a good idea, I'm tired of moving between Int32.t's and int's and having to change all sorts of functions. -- Manos |
From: Eric C. C. <ec...@cm...> - 2003-03-01 01:17:02
|
On Fri, Feb 28, 2003 at 07:54:29PM -0500, Manos Renieris wrote: > I don't know how other people feel, but to me, the short names in > String (ftos, stoi, stof) look very ugly. I agree. > String.to_float, String.to_int, and String.to_float seem much better, > and more consistent with the choices in the standard library. > An Int module with things like Int.of_string = int_of_string also > sounds like a good idea, I'm tired of moving between Int32.t's and > int's and having to change all sorts of functions. Good suggestions. Another issue: I see (at least) two philosophies of exception naming. (1) The standard library only defines a few, and uses string arguments (to Failure and Invalid_argument) for specifics. (2) Nicolas's collection uses more numerous and specific exceptions: Invalid_index Invalid_string No_such_element ... I guess I'm used to the first approach, and the generality hasn't been a problem. I've almost always been able to write something like try ... with Failure _ -> ... and often just try ... with _ -> ... rather than being more specific. What has been the experience of others on this list? -- Eric C. Cooper e c c @ c m u . e d u |
From: Nicolas C. <war...@fr...> - 2003-03-03 05:52:29
|
> Good suggestions. > > Another issue: I see (at least) two philosophies of exception naming. > > (1) The standard library only defines a few, and uses string arguments (to > Failure and Invalid_argument) for specifics. > > (2) Nicolas's collection uses more numerous and specific exceptions: > Invalid_index > Invalid_string > No_such_element > ... > > I guess I'm used to the first approach, and the generality hasn't been > a problem. I've almost always been able to write something like > try ... with Failure _ -> ... > and often just > try ... with _ -> ... > rather than being more specific. What has been the experience of > others on this list? We have already been discussing about that ( see the list archives ). The probleme here is that you cannot enclose a large blocs of code within try...with because catching Failure _ or even worst _ can be a very bad thing. So most of the time I suppose you're doing something like : let i = (try int_of_string s with _ -> raise MyException) in .... and then MyException is catched by the up/calling function. This would be easier to have int_of_string directly raising your exception. Exceptions are made to propagate, and Failure / Invalid_arguments are good for either immediate catching or no-catching at all . Nicolas Cannasse |
From: Michal M. <mal...@pl...> - 2003-03-01 17:31:11
|
On Fri, Feb 28, 2003 at 07:54:29PM -0500, Manos Renieris wrote: > I don't know how other people feel, but to me, the short names in > String (ftos, stoi, stof) look very ugly. > > String.to_float, String.to_int, and String.to_float seem much better, > and more consistent with the choices in the standard library. > An Int module with things like Int.of_string = int_of_string also > sounds like a good idea, I'm tired of moving between Int32.t's and > int's and having to change all sorts of functions. Int module could be also useful for Map.Make. -- : Michal Moskal ::::: malekith/at/pld-linux.org : GCS {C,UL}++++$ a? !tv : PLD Linux ::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h |
From: Nicolas C. <war...@fr...> - 2003-03-03 05:44:50
|
> I don't know how other people feel, but to me, the short names in > String (ftos, stoi, stof) look very ugly. I agree :) > String.to_float, String.to_int, and String.to_float seem much better, > and more consistent with the choices in the standard library. Perhaps, but don't forget to add the Ext in front. It's important because will users really write : ExtString.to_float or prefer to open ExtString ( and in this case usage of to_float without namespace is meaningless ) and perhaps then for full qualified names we could just name the modules EString, EHashtbl or maybe XString, XHashtbl, etc... for fully qualified easy path access. > An Int module with things like Int.of_string = int_of_string also > sounds like a good idea, I'm tired of moving between Int32.t's and > int's and having to change all sorts of functions. Agree If you're willing to write it fully ( MLI spec + doc + impl ).... Nicolas Cannasse |
From: Blair Z. <bl...@or...> - 2003-03-01 21:38:12
|
Nicolas Cannasse wrote: > > Hi list > > Here's most of the functions ( sorted by module ) that I been gathered from > different mails here and there. There might me some mission functions but I > tried to make the whole consisted and documented. You will see that I have > included both Global and MList modules, since MList seems to be approved, > and Global-like used by several people here. Looks great. Can we rename MList to something more descriptive, such as List_Mutable? I'd prefer to see the object type first, such as List, followed by a object qualifier, in this case Mutable. So all Lists would begin with List*. This would make module sorting and searching easier in COAN. I think this would be relevant and consistent with other module distributions, such as different XML parsing modules that would all be named with an XML* prefix. Best, Blair -- Blair Zajac <bl...@or...> Plots of your system's performance - http://www.orcaware.com/orca/ |
From: Nicolas C. <war...@fr...> - 2003-03-03 05:44:49
|
> > Hi list > > > > Here's most of the functions ( sorted by module ) that I been gathered from > > different mails here and there. There might me some mission functions but I > > tried to make the whole consisted and documented. You will see that I have > > included both Global and MList modules, since MList seems to be approved, > > and Global-like used by several people here. > > Looks great. > > Can we rename MList to something more descriptive, such as List_Mutable? I don't think so... Because lots of people ( including me ) are not actually opening the List module for example, and are using the fully qualified namespace "List.iter" to call functions. And after several times List_Mutable.iter is getting really verbose ( by the way that seems to be the caml team opinion as well since we have Hashtbl and not Hashtable module ) > I'd prefer to see the object type first, such as List, followed by a object > qualifier, in this case Mutable. So all Lists would begin with List*. This > would make module sorting and searching easier in COAN. Uh ? COAN is still far from being done. Trying to figure out - and to resolve - possible problems of the posesible intregration of ExtLib into COAN seem counterproductive. > I think this would be relevant and consistent with other module distributions, > such as different XML parsing modules that would all be named with an XML* > prefix. I think that MList is understandable enough for the average user. BTW future XML documentation will of course include a fully qualified name such as "Mutable List". Nicolas Cannasse |
From: Blair Z. <bl...@or...> - 2003-03-03 05:55:39
|
Nicolas Cannasse wrote: > > > > Hi list > > > > > > Here's most of the functions ( sorted by module ) that I been gathered > from > > > different mails here and there. There might me some mission functions > but I > > > tried to make the whole consisted and documented. You will see that I > have > > > included both Global and MList modules, since MList seems to be > approved, > > > and Global-like used by several people here. > > > > Looks great. > > > > Can we rename MList to something more descriptive, such as List_Mutable? > > I don't think so... > Because lots of people ( including me ) are not actually opening the List > module for example, and are using the fully qualified namespace "List.iter" > to call functions. And after several times List_Mutable.iter is getting > really verbose ( by the way that seems to be the caml team opinion as well > since we have Hashtbl and not Hashtable module ) Well, Hashtbl is at least understandable what it is, shortening Mutable to M is not. And I wouldn't necessarily read into the ocaml team's opinion as well that this amount of name shortening is good. I would ask one of the main team to back this claim. If you use a particular name enough, then you could always do let miter = List_Mutable.iter in your code. So this gets your short names and gets me my long names. I'm concerned that when COAN gets going, there's going to be name collisions and choosing very short names will lead to collisions later on. > > I think this would be relevant and consistent with other module > distributions, > > such as different XML parsing modules that would all be named with an XML* > > prefix. > > I think that MList is understandable enough for the average user. Not claiming to be an average user :) (Most Ocaml users probably aren't) It wasn't for me. In the week that MList was first discussed and when I got around to looking at ExtLib, I had already forgotten what MList meant. Best, Blair -- Blair Zajac <bl...@or...> Plots of your system's performance - http://www.orcaware.com/orca/ |
From: Nicolas C. <war...@fr...> - 2003-03-03 06:05:53
|
> If you use a particular name enough, then you could always do > > let miter = List_Mutable.iter > > in your code. So this gets your short names and gets me my long names. You could on your side do : module List_Mutable = ExtLib.MList > I'm concerned that when COAN gets going, there's going to be name collisions > and choosing very short names will lead to collisions later on. The "-pack" option is resolving most of the cases. By the way, the more you use some functions, so more they have to be short named. I personnally think that mutable lists are the kind of module with large potential usage ( the whole ExtLib is, actually ) > > > I think this would be relevant and consistent with other module > > distributions, > > > such as different XML parsing modules that would all be named with an XML* > > > prefix. > > > > I think that MList is understandable enough for the average user. > > Not claiming to be an average user :) (Most Ocaml users probably aren't) > It wasn't for me. In the week that MList was first discussed and when I > got around to looking at ExtLib, I had already forgotten what MList meant. Yes, perhaps it's not obvious, but the documentation is here for that ! for example the modules "Weak" , "Oo", "Complex" from the standard library are not so obvious names. But you only have to open the doc to get it. Nicolas Cannasse |
From: Blair Z. <bl...@or...> - 2003-03-03 06:26:59
|
Nicolas Cannasse wrote: > > > If you use a particular name enough, then you could always do > > > > let miter = List_Mutable.iter > > > > in your code. So this gets your short names and gets me my long names. > > You could on your side do : > > module List_Mutable = ExtLib.MList Granted. > > Yes, perhaps it's not obvious, but the documentation is here for that ! The code is the documentation! > for example the modules "Weak" , "Oo", "Complex" from the standard library > are not so obvious names. But you only have to open the doc to get it. I'm not debating these names. Anybody who's studied C++ has probably seen the Complex type, can figure out that Oo means ObjectOriented, and Weak means weak and would have to be looked up. I just have issue with shorting Mutable to M. If it were MutList, then my objections would be reduced. MutList is the same length as Hashtbl. Why don't we take this to a vote on the list. Right now we're tied :) While we're on voting, I propose we introduce a voting mechanism to see decide issues. I like the Apache voting mechanism and have used it before: Expressing Votes: +1, 0, -1, and Fractions The voting process in Apache may seem more than a little weird if you've never encountered it before. Votes are represented as numbers between -1 and +1, with '-1' meaning 'no' and '+1' meaning 'yes.' The in-between values are indicative of how strongly the voting individual feels. Here are some examples of fractional votes and ways in which they might be intended and interpreted: +0: 'I don't feel strongly about it, but I'm ok with this.' -0: 'I won't get in the way, but I'd rather we didn't do this.' -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' ++1: 'Wow! I like this! Let's do it!' -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' -1: 'I strongly disagree' More info: http://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=apache+voting Best, Blair -- Blair Zajac <bl...@or...> Plots of your system's performance - http://www.orcaware.com/orca/ |
From: William D. N. <wne...@cs...> - 2003-03-03 14:03:52
|
On Sun, 2 Mar 2003, Blair Zajac wrote: > > > Can we rename MList to something more descriptive, such as List_Mutable? > > > > And after several times List_Mutable.iter is getting > > really verbose ( by the way that seems to be the caml team opinion as well > > since we have Hashtbl and not Hashtable module ) > > Well, Hashtbl is at least understandable what it is, shortening Mutable to > M is not. I agree with this. Every time I see MList, it gets parsed as ML-ist (like duelist or trombonist) rather than M-List, and it takes me time to remember what the heck an ML-ist is... My vote would go for a longer more descriptive name such as Mutable_List (+0.9) or Mut_List (+0.6). Besides, aren't long, commonly used identifiers why jeebus invented keyboard macros? William D. Neumann --- "Well I could be a genius, if I just put my mind to it. And I...I could do anything, if only I could get 'round to it. Oh we were brought up on the space-race, now they expect you to clean toilets. When you've seen how big the world is, how can you make do with this? If you want me, I'll be sleeping in - sleeping in throughout these glory days." -- Jarvis Cocker |
From: Nicolas C. <war...@fr...> - 2003-03-04 01:50:15
|
> > > > Can we rename MList to something more descriptive, such as List_Mutable? > > > > > > And after several times List_Mutable.iter is getting > > > really verbose ( by the way that seems to be the caml team opinion as well > > > since we have Hashtbl and not Hashtable module ) > > > > Well, Hashtbl is at least understandable what it is, shortening Mutable to > > M is not. > > I agree with this. Every time I see MList, it gets parsed as ML-ist (like > duelist or trombonist) rather than M-List, and it takes me time to > remember what the heck an ML-ist is... > > My vote would go for a longer more descriptive name such as Mutable_List > (+0.9) or Mut_List (+0.6). Besides, aren't long, commonly used > identifiers why jeebus invented keyboard macros? For a langage-design problem, you're using an editor solution... I think you're totally wrong here, because as we can choose, they shouldn't be *any* long, commonly used identifier. Main arguments against MList are : 1) this is too short for COAN , can cause name clash answer : we're writing a "standard" library, we have priority on module names (just after the official ones) answer2 : there currently no COAN around answer3 : the -pack compiler option can resolve such problems 2) this is not understandable in the first sight answer : why should it be ? I mean, if you're reading a Java program without knowing at least a bit of the JDK, you're not going to understand it like you would read an english text. answer2 : Programming is matter of syntax and semantic rules, keeping shortly named modules is helpful when reading problems as it keeps the source code compact. answer3 : It's only a problem for beginners, and they can still look at the doc to see what is MList Naming conflicts should be resolved by arguments, not by a vote. Nicolas Cannasse |
From: Manos R. <er...@cs...> - 2003-03-04 02:11:33
|
On Tue, Mar 04, 2003 at 10:49:27AM +0900, Nicolas Cannasse wrote: > > > > > Can we rename MList to something more descriptive, such as > List_Mutable? > > > > > Main arguments against MList are : > > 1) this is too short for COAN , can cause name clash > answer : we're writing a "standard" library, we have priority on module > names (just after the official ones) > answer2 : there currently no COAN around > answer3 : the -pack compiler option can resolve such problems > > 2) this is not understandable in the first sight > answer : why should it be ? I mean, if you're reading a Java program > without knowing at least a bit of the JDK, you're not going to understand it > like you would read an english text. > answer2 : Programming is matter of syntax and semantic rules, keeping > shortly named modules is helpful when reading problems as it keeps the > source code compact. > answer3 : It's only a problem for beginners, and they can still look at > the doc to see what is MList > > Naming conflicts should be resolved by arguments, not by a vote. As far as I can tell, the Caml practice is that to use longer names, perhaps on the basis that there are ways to shorten them if necessary. MList is not a bad name but the fact that it loses the "Mutable" part is bothersome. If I'm reading somebody else's code and I come across MList, I have to go look at the manual. If I come across MutableList, the meaning is much clearer. The meaning is also clear if the first line of the program is module MList = MutableList Since we have this wonderful mechanism to shorten names, I think it's a pity to use short names from the beginning and lose all the (potential, or even questionable, if you like) advantages of long ones. -- Manos |
From: Remi V. <van...@la...> - 2003-03-04 03:38:57
|
"Nicolas Cannasse" <war...@fr...> writes: >> > > > Can we rename MList to something more descriptive, such as > List_Mutable? >> > > >> > > And after several times List_Mutable.iter is getting >> > > really verbose ( by the way that seems to be the caml team opinion= as > well >> > > since we have Hashtbl and not Hashtable module ) >> > >> > Well, Hashtbl is at least understandable what it is, shortening Muta= ble > to >> > M is not. >> >> I agree with this. Every time I see MList, it gets parsed as ML-ist (= like >> duelist or trombonist) rather than M-List, and it takes me time to >> remember what the heck an ML-ist is... >> >> My vote would go for a longer more descriptive name such as Mutable_Li= st >> (+0.9) or Mut_List (+0.6). Besides, aren't long, commonly used >> identifiers why jeebus invented keyboard macros? > > For a langage-design problem, you're using an editor solution... I thin= k > you're totally wrong here, because as we can choose, they shouldn't > be *any* long, commonly used identifier. I completely disagree here. Identifier should be easily understandable, then short. I mean that It is more important than one can understood its meaning than the fact it is short. Then Mut_List is understandable, and relatively short.=20 --=20 R=E9mi Vanicat va...@la... http://dept-info.labri.u-bordeaux.fr/~vanicat |
From: William D. N. <wne...@cs...> - 2003-03-04 03:41:36
|
On Tuesday, March 4, 2003 Nicolas Cannasse yammered thusly: > For a langage-design problem, you're using an editor solution... Not really. I believe the proper design is to use fully descriptive identifiers. I merely suggest an editor feature as a possible aid to those who don't want to type long names. > I think you're totally wrong here, because as we can choose, they > shouldn't be *any* long, commonly used identifier. You know, years ago I might have agreed with you -- back when I wrote code only for myself. But now that I write code in an environment where your code has a life that includes a number of other people, and code reviews are often performed (and often painful), I can't disagree more. For me (and I'd wager a great number of people), code is read by humans far more often than it is written by humans, and reading identifiers like MutableList or InitializeCryptoVariable makes reading that code much easier than MList or InitCV. > Main arguments against MList are : > > 1) this is too short for COAN , can cause name clash > answer : we're writing a "standard" library, we have priority on > module names (just after the official ones) The only "priority" we are given is by the people who would use our library. And if our names clash with other libraries that those users find more valuable, our priority vanishes. > answer2 : there currently no COAN around Does this mean that we shouldn't look forward to what is likely to happen with a COAN? Should we not try to use a design that will "play nice" with a wide array of future libraries? > answer3 : the -pack compiler option can resolve such problems True. > 2) this is not understandable in the first sight > answer : why should it be ? I mean, if you're reading a Java > program without knowing at least a bit of the JDK, you're not going > to understand it like you would read an english text. Well, I've never programmed in Java (well that's not entirely true, I wrote one silly little program about four years ago), but I have had to grade a few programs written in Java, and I was very pleased to find code like: parser.whitespaceChars() g.modInverse() doChineseRemainderThm() [although this last one isn't built into the language] Identifiers like that made these programs far easier to read than something like: parser.wsChars() g.mInv() doCRT() > answer2 : Programming is matter of syntax and semantic rules, Only in isolation (or in theory) is programming solely a "matter of syntax and semantic rules". Unfortunately, programming rarely occurs in isolation (or in theory). > keeping shortly named modules is helpful when reading problems as > it keeps the source code compact. I don't think I would ever agree that an overly shortened identifier makes reading code easier or more pleasant than a fully descriptive identifier (speaking generally, of course). > answer3 : It's only a problem for beginners, and they can still > look at the doc to see what is MList I'd change that to say, "It's only a problem for those who are not especially familiar with the module/function in question." I wouldn't call myself a beginner, but overly short names still make reading code more difficult for me... Now then, the only argument so far against MutableList (or similar fully descriptive name) is that it is too long. answer 1: Get an editor that supports keyboard macros or abbreviations. At the very least, get one that supports find/replace. answer 2: let mlBlah = MutableList.blah Now, before you point out that these arguments could both be used to support your position as well (well, half of answer 1 and all of answer 2), I would suggest that they lend more weight to the descriptive name argument. This is because I believe that while a user should be free to make the language less descriptive for the sake of typing fewer characters, it should *not* be the user's responsibility to bring the language up to a basic level of readibility. That responsibility should remain with the language/library developer. (Hmmm...that thought was a lot harder to put into words than I figured it would be...I hope I got the point across). > Naming conflicts should be resolved by arguments, not by a vote. Well, they should be resolved by arguments followed by a vote. I read your arguments, I read Blair's, and I considered my own (although I should have shared them earlier), and then I voted... what's wrong with that? William D. Neumann --- Now, a few words on looking for things. When you go looking for something specific, your chances of finding it are very bad. Because of all the things in the world, you're only looking for one of them. When you go looking for anything at all, your chances of finding it are very good. Because of all the things in the world, you're sure to find some of them. - Daryl Zero, Zero Effect |
From: Nicolas C. <war...@fr...> - 2003-03-04 04:34:56
|
> > keeping shortly named modules is helpful when reading problems as > > it keeps the source code compact. > > I don't think I would ever agree that an overly shortened identifier > makes reading code easier or more pleasant than a fully descriptive > identifier (speaking generally, of course). [...] > Now then, the only argument so far against MutableList (or similar > fully descriptive name) is that it is too long. > > answer 1: Get an editor that supports keyboard macros or > abbreviations. At the very least, get one that supports find/replace. > > answer 2: let mlBlah = MutableList.blah > > Now, before you point out that these arguments could both be used to > support your position as well (well, half of answer 1 and all of > answer 2), I would suggest that they lend more weight to the > descriptive name argument. This is because I believe that while a > user should be free to make the language less descriptive for the sake > of typing fewer characters, it should *not* be the user's > responsibility to bring the language up to a basic level of > readibility. That responsibility should remain with the > language/library developer. (Hmmm...that thought was a lot harder to > put into words than I figured it would be...I hope I got the point > across). Okay, I give up, MList was a bad name since the beginning :) But I don't think that Mutable_List is good either. Perhaps "MutList" ( without underscore ) match both needs : 1) descriptive enough 2) short enough Do people here agree ? I'm happy that we add theses talks, that will help a lot in future problems containing modules/functions naming. Let's put the two rules above somewhere. Nicolas Cannasse |
From: Blair Z. <bl...@or...> - 2003-03-04 08:35:06
|
Nicolas Cannasse wrote: > > Okay, I give up, MList was a bad name since the beginning :) > But I don't think that Mutable_List is good either. > > Perhaps "MutList" ( without underscore ) match both needs : > 1) descriptive enough > 2) short enough Given William's point of code reviews and more people reading a piece of code than writing it, I would prefer to use the entire word unless a commonly held shortcut is known to most people, such as Chars for Characters. Just so you know, my real preference would be for something like ListMutable, reversing the order of words. For example, CPAN has the following List modules up on CPAN: Module Lisp::List (G/GA/GAAS/perl-lisp-0.05.tar.gz) Module List::Compare (J/JK/JKEENAN/List-Compare-0.15.tar.gz) Module List::Intersperse (T/TA/TAYERS/List-Intersperse-1.00.tar.gz) Module List::Member (L/LG/LGODDARD/List-Member-0.02.tar.gz) Module List::Permutor (P/PH/PHOENIX/List-Permutor-0.022.tar.gz) Module List::Priority (U/UD/UDASSIN/List-Priority-0.02.tar.gz) Module List::Sliding::Changes (C/CO/CORION/List-Sliding-Changes-0.02.tar.gz) Module List::Util (G/GB/GBARR/Scalar-List-Utils-1.11.tar.gz) Module List::Utils (T/TB/TBONE/List-Utils-0.01.tar.gz) Here it's pretty easy to see the available list modules that people could use. This naming scheme allows easy classification of modules by there name. Using the proposed name order would not have as much order. So I propose this naming scheme. 1) A module name may consists of one or more words. The first letter of each word is capitalized. Words are concatenated together with no additional characters, such as _. 2) For module names consisting of two or more words, the more general word is listed first, followed by words that qualify the first word. So ListMutable instead of MutableList. 3) Words making up a name may be shortened if the short version is a commonly known shortcut. Make the name as short as possible but no shorter than needed to be easily readable for a code review. Determining a shortcut would be up to a vote to see how many people could use the shortcut without looking it up. Example shortcut: Character -> Char. So my preferred order of names is (because I don't know how many people would use Mut for Mutable): +1.0 ListMutable +0.8 List_Mutable +0.6 MutableList +0.4 Mutable_List +0.3 ListMut +0.2 MutList > I'm happy that we add theses talks, that will help a lot in future problems > containing modules/functions naming. Definitely good to get this flat now. Best, Blair -- Blair Zajac <bl...@or...> Plots of your system's performance - http://www.orcaware.com/orca/ |
From: fva <fv...@ts...> - 2003-03-04 09:44:14
|
Blair Zajac wrote: >So I propose this naming scheme. > >1) A module name may consists of one or more words. The first letter > of each word is capitalized. Words are concatenated together with > no additional characters, such as _. > Agree. >2) For module names consisting of two or more words, the more general > word is listed first, followed by words that qualify the first word. > > So ListMutable instead of MutableList. > Disagree... I'd rather have the English convention: modifiers first even if they are verbs (Hashtbl) or substantives (PriorityQueue, MutableList) or whatever (MyList, ThisList,,,) >3) Words making up a name may be shortened if the short version is a > commonly known shortcut. Make the name as short as possible but no > shorter than needed to be easily readable for a code review. > > Determining a shortcut would be up to a vote to see how many people > could use the shortcut without looking it up. > > Example shortcut: Character -> Char. > Agree, with nuances: remember some abbreviations simply don't read well (See J. Aitchison on organization of the mental lexicon and what gets read there). It is clear to me that built-in types *do*read well as modifiers, because most seasoned users of the language already have "char", "int" and "bool" as lexical items. Hence your "good-looking" CharList, CharArrayList, etc... Regards, Fran Valverde |
From: Florian H. <ha...@bi...> - 2003-03-04 17:28:58
|
Blair Zajac wrote: > Given William's point of code reviews and more people reading a piece > of code than writing it, [...] > Words are concatenated together with no additional characters, such as _. Words should never run into another, but be properly separated by characters like _. man perlstyle: While short identifiers like $gotit are probably ok, use underscores to separate words. It is generally easier to read $var_names_like_this than $VarNamesLikeThis, especially for non-native speakers of English. Would you want perl to be more readable than ocaml? Yours, Florian Hars. |