ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] ExtLib v0.2

[Amit D. <ad...@Co...>]

> 
> > > Hi list !
> > >
> > > Let's continue working together on ExtLib !
> > > Here's the new version, adding some changes.
> > > Please report any missing function and any comments you could have on
> it.
> >
> > Where did Option.val_of go? (maybe I'm missing something)
> >
> 
> The problem I can see with val_of is the following :
> val_of should raise an exception when you're using it with None, and if
> you're using a good programming style, this is the kind of excecption you
> have to catch quite immediatly, so I think it's better to write :
> 
> match x with
> | None -> do_something
> | Some v -> use_it
> 
> than
> 
> try
>     use_it (val_of x)
> with
>     NoneException -> do_something

    I disagree: val_of has two reasonable uses.  First, it can be
used with throwaway prototype programs, where simplicity and speed
matter more than correctness.  Second, it can be used where the semantics
of the program dictate that the option has "Some" value.  If you don't
have a "Some" value in these cases, there often is nothing to do
except bail out in the "with" clause, so you might as well catch
the exception somewhere else higher up.

    I might add: if it's good enough for SML, it's good enough for me :)

    -Amit

    

Re: [Ocaml-lib-devel] ExtLib v0.2

[Nicolas C. <war...@fr...>]

> > Hi list !
> >
> > Let's continue working together on ExtLib !
> > Here's the new version, adding some changes.
> > Please report any missing function and any comments you could have on
it.
>
> Where did Option.val_of go? (maybe I'm missing something)
>

The problem I can see with val_of is the following :
val_of should raise an exception when you're using it with None, and if
you're using a good programming style, this is the kind of excecption you
have to catch quite immediatly, so I think it's better to write :

match x with
| None -> do_something
| Some v -> use_it

than

try
    use_it (val_of x)
with
    NoneException -> do_something

Other operations such as default or map have a fully defined behavior

Nicolas Cannasse

Re: [Ocaml-lib-devel] ExtLib v0.2

[Michal M. <mal...@pl...>]

On Mon, Mar 10, 2003 at 02:03:10PM +0900, Nicolas Cannasse wrote:
> Hi list !
> 
> Let's continue working together on ExtLib !
> Here's the new version, adding some changes.
> Please report any missing function and any comments you could have on it.

Where did Option.val_of go? (maybe I'm missing something)

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

[Ocaml-lib-devel] ExtLib v0.2

[Nicolas C. <war...@fr...>]

Hi list !

Let's continue working together on ExtLib !
Here's the new version, adding some changes.
Please report any missing function and any comments you could have on it.

Nicolas Cannasse

Re: [Ocaml-lib-devel] MList name

[fva <fv...@ts...>]

Nicolas Cannasse wrote:

>Hi,
>
>I can up with another idea this morning ( yes, morning : it's currently 10am
>in Japan ). What about the name of "Vector". That's short, understandable,
>and people coming from the Java world will be more that happy to find a data
>structure with which they can do add/remove.
>
I don't know whether "vector" is too overloaded (maths, computing) to be 
any indicator of what is really contained there, but I prefer it to 
RefList... This really smacks of the implementation (which is OK if you 
want to make it patent, though). Also, I was happy with any of the 
M(.)+List suggestiongs, but the most criptic MList (sorry Nicolas!), but 
Ialso your right to name your datatype as you think fit.

On the other hand, the question raised by your putting forht "MList" 
still remains: how to go about naming new modules, etc. Have we reached 
and agreement about this with the "small list of rules" discussed this week?

Regards,

       Fran Valverde

Re: [Ocaml-lib-devel] MList name (was: ExtLib v0.1o)

[Michal M. <mal...@pl...>]

On Thu, Mar 06, 2003 at 07:56:04AM +0100, Michal Moskal wrote:
> On Wed, Mar 05, 2003 at 08:46:28PM -0500, Eric C. Cooper wrote:
> > > If you don't like Vector, Jacques Garrigue came up with another idea when I
> > > was talking about it : "RefList" ( that has a lot of meaning for OCaml
> > > people, since everybody knows ' a ref )
> > 
> > I like this much better than M(.*)List, even though one might object that
> > it describes the implementation rather than the abstract interface.
> 
> RefList sounds like reference list (list of references). List ref could
                                                           ^^^^^^^^
Ergh.. ListRef or Listref.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

Re: [Ocaml-lib-devel] MList name (was: ExtLib v0.1o)

[Michal M. <mal...@pl...>]

On Wed, Mar 05, 2003 at 08:46:28PM -0500, Eric C. Cooper wrote:
> > If you don't like Vector, Jacques Garrigue came up with another idea when I
> > was talking about it : "RefList" ( that has a lot of meaning for OCaml
> > people, since everybody knows ' a ref )
> 
> I like this much better than M(.*)List, even though one might object that
> it describes the implementation rather than the abstract interface.

RefList sounds like reference list (list of references). List ref could
be better. But I'm still not sure how it relates to Stack module in
OCaml stdlib.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

Re: [Ocaml-lib-devel] MList name (was: ExtLib v0.1o)

[Eric C. C. <ec...@cm...>]

On Thu, Mar 06, 2003 at 10:12:17AM +0900, Nicolas Cannasse wrote:
> What about the name of "Vector". That's short, understandable, and
> people coming from the Java world will be more that happy to find a
> data structure with which they can do add/remove.

Vector has a strong connotation of constant-time indexing, like
arrays (esp. given the vectors in SML).

> If you don't like Vector, Jacques Garrigue came up with another idea when I
> was talking about it : "RefList" ( that has a lot of meaning for OCaml
> people, since everybody knows ' a ref )

I like this much better than M(.*)List, even though one might object that
it describes the implementation rather than the abstract interface.

-- 
Eric C. Cooper          e c c @ c m u . e d u

Re: [Ocaml-lib-devel] MList name (was: ExtLib v0.1o)

[Nicolas C. <war...@fr...>]

Hi,

I can up with another idea this morning ( yes, morning : it's currently 10am
in Japan ). What about the name of "Vector". That's short, understandable,
and people coming from the Java world will be more that happy to find a data
structure with which they can do add/remove.

If you don't like Vector, Jacques Garrigue came up with another idea when I
was talking about it : "RefList" ( that has a lot of meaning for OCaml
people, since everybody knows ' a ref )

Nicolas Cannasse

Re: [Ocaml-lib-devel] ExtLib v0.1o

[fva <fv...@ts...>]

Florian Hars wrote:

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

I don't think that is really the question... As W.Neumann has pointed 
out the Ocaml team chose to include underscore in variable names but not 
in module names... I think we should stick to that... (Besides I've been 
using the CapitaliseTheInitialCharacter ever since Modula and I feel 
comfortable with it ;) )

Regards,

        Fran Valverde

Re: [Ocaml-lib-devel] ExtLib v0.1o

[Nicolas C. <war...@fr...>]

> > I would strongly object to ListMutable... The order doesn't look right
> > for an English-lexicalized language (even if it is designed and managed
> > in French ;) )
>
> However, ListMutable is a better name if you want to have an alphabetical
> listing of contributed modules and want conceptually close modules to be
> listed close to each other.
>
> That parses as (Category: List; Subcategory: Mutable)

Could I object that perhaps if I'm looking for a mutable structure with some
specific complexities on add/find/remove operations, then sorting them with
Mutable first is better ?

More seriously, I don't see why categories should be == to the module name,
they still can be defined separatly in the supposed COAN module header :

<module name="MutableList" cat="List" subcat="Mutable"/>

Nicolas Cannasse

Re: [Ocaml-lib-devel] MList name (was: ExtLib v0.1o)

[William D. N. <wne...@cs...>]

On Tue, 4 Mar 2003, Amit Dubey wrote:

>     I agree that Mutable_List isn't good: the underscore
> is unnecessary.

Yeah.  I'm guessing the reason the underscore keeps creeping in is because
of the OCaml team's use of underscores in their function names.  Of course
they don't use underscores in the one module they could have, StdLabels.
(Well, they could also have used them in Genlex, Nativeint, and Printexec,
but they didn't use any "word separation" techniques there...)  So I agree
that underscores should be right out.  In the Apache voting style, I give:

-1.0 : Use of underscores in module names
-0.0 : Use of underscores in function names (it's a personal preference
to not use them, but I don't really care that much)

>     "MutList" fits the descriptive test, espcially if we have
> a lot of datastructures that come in mutable/non-mutable pairs.
> It does not, however, pass the intuitivity test.
                     <snip...>
>     Also, another problem with "Mut" is that it is just
> a strange contraction to make.  Using "Std" for "Standard" is
> common and easily understood.  "Ext" for "Extended" is OK.  But
> "Mut" for "Mutable" is a bit awkward, and not very common.
> (Mutbl might be OK, though).

Agreed.  Although I wouldn't get my panties in a bunch if MutList were
adopted.  And so, my vote on names (and the underlying naming rules) are
as follows:

+1.0 MutableList (fully descriptive, Modifier* Subject)
+0.5 MutblList (slightly abbreviated, Modifier* Subject)
+0.2 MutList (moderately abbreviated, Modifier* Subject)
-0.7 MList (fullly abbreviated, Modifier* Subject)
-0.2 ListMutable (fully descriptive, SubjectModifier*)
-0.7 ListMutbl (slightly abbreviated, Subject Modifier*)
-0.8 ListMut (moderately abbreviated, Subject Modifier*)
-1.0 ListM (fullly abbreviated, Subject Modifier*)

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

Re: [Ocaml-lib-devel] ExtLib v0.1o

[Florian H. <ha...@bi...>]

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.

[Ocaml-lib-devel] MList name (was: ExtLib v0.1o)

[Amit D. <ad...@Co...>]

...<snip>...

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


    answer 3:  module MList = MutableList

...<snip>...


> 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 agree that Mutable_List isn't good: the underscore
is unnecessary.  However, I do have some issues with
MutList.  First, I think the rules should be:

1) Intuitive 
2) Concise

    "MutList" fits the descriptive test, espcially if we have
a lot of datastructures that come in mutable/non-mutable pairs.
It does not, however, pass the intuitivity test.  If I knew
nothing about the library, I don't have to think at all
to figure out what "MutableList" does.  I *do* have to think
to figure out what "MutList" does.  Any thing we do to make
the learning curve gentler is useful, I think.  Moreover,
we could also "alias" MutableList to MList (or whatever) in ExtStd
for more "advanced" users.

    Also, another problem with "Mut" is that it is just
a strange contraction to make.  Using "Std" for "Standard" is
common and easily understood.  "Ext" for "Extended" is OK.  But
"Mut" for "Mutable" is a bit awkward, and not very common.
(Mutbl might be OK, though).

    All in all, this gives us three basic rules:

1) Intuitive
2) Concise
3) Conforms to English grammar (see previous email)

    As for MutList, I guess that leaves two options:

MutableList (with a possible alias)
MutblList

    -Amit




> 
> 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
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> ocaml-lib-devel mailing list
> oca...@li...
> https://lists.sourceforge.net/lists/listinfo/ocaml-lib-devel
> 

Re: [Ocaml-lib-devel] MList name (was: ExtList v0.1o)

[Amit D. <ad...@Co...>]

> 
> On Tue, Mar 04, 2003 at 10:43:51AM +0100, fva wrote:
> 
> > I would strongly object to ListMutable... The order doesn't look right 
> > for an English-lexicalized language (even if it is designed and managed 
> > in French ;) )
> 
> However, ListMutable is a better name if you want to have an alphabetical
> listing of contributed modules and want conceptually close modules to be
> listed close to each other.
> 
> That parses as (Category: List; Subcategory: Mutable)

    Hi Everyone,

    I think it is important to make a disctinction here.  When I see
SomethingLikeThis, I assume it is a noun phrase.  If I see
Something.Like.This, I assume each identifier is a level on a
hierarchy.

    As a native English speaker, I will tell you that ListMutable
is an *ungrammatical* noun phrase.  I beleive the order of
adjuncts is the opposite in romance languages, but this is the
way it is done in English.  On the other hand, I can see the
argument for calling it ExtList.Mutable (this would
be like ExtList::Mutable the way Perl/CPAN does things).

    As another poster alluded, if you think ListMutable is
a good idea, to be consistant you must also use names like
TableHash, QueuePriority, etc.  You can argue this is
different from the category/subcategory schema argued for
"MutableList", but it isn't clear to me (and wouldn't be
clear for any new users) why we use the category/subcategory
schema in some places, and why we use grammatical English
noun phrases in other places.

    I beleive rather, that we should stay consistant and
use the English noun phrase grammar Adjective* Noun, rather
than Noun Adjective*.  I agree that category/subcategory disctinction
is useful one to make, but we need to find another way of doing
this.

    -Amit



> 
> Fernando
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> ocaml-lib-devel mailing list
> oca...@li...
> https://lists.sourceforge.net/lists/listinfo/ocaml-lib-devel
> 

Re: [Ocaml-lib-devel] ExtLib v0.1o

[Fernando A. <fer...@cc...>]

On Tue, Mar 04, 2003 at 10:43:51AM +0100, fva wrote:

> I would strongly object to ListMutable... The order doesn't look right 
> for an English-lexicalized language (even if it is designed and managed 
> in French ;) )

However, ListMutable is a better name if you want to have an alphabetical
listing of contributed modules and want conceptually close modules to be
listed close to each other.

That parses as (Category: List; Subcategory: Mutable)

Fernando

Re: [Ocaml-lib-devel] ExtLib v0.1o

[fva <fv...@ts...>]

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

Re: [Ocaml-lib-devel] ExtLib v0.1o

[fva <fv...@ts...>]

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
>
>Do people here agree ?
>
I do like MutList and also MutableList...

I would strongly object to ListMutable... The order doesn't look right 
for an English-lexicalized language (even if it is designed and managed 
in French ;) )

>
>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.
>
Yes, this was the best result of the thread in my understanding...

    Fran Valverde

PD: Just my two cents... Back in the days when I learnt Lisp I used to 
browse the grammar and got really p....d when I read things like <sexp> 
to stand for "symbolic expression"... To me the thing parsed from the 
other end! (I was at University... You may be forgiving here!)... This 
gave me some funny ideas about the people who had designed the language 
and what they intended with it! X) F.V.
PDD: This is not to imply that MList parses *in any way similar* to 
"sexp" X) X) X) F.

Re: [Ocaml-lib-devel] ExtLib v0.1o

[Blair Z. <bl...@or...>]

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/

Re: [Ocaml-lib-devel] ExtLib v0.1o

[Nicolas C. <war...@fr...>]

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

Re: [Ocaml-lib-devel] ExtLib v0.1o

[William D. N. <wne...@cs...>]

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

Re: [Ocaml-lib-devel] ExtLib v0.1o

[Remi V. <van...@la...>]

"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

Re: [Ocaml-lib-devel] ExtLib v0.1o

[Manos R. <er...@cs...>]

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

Re: [Ocaml-lib-devel] ExtLib v0.1o

[Nicolas C. <war...@fr...>]

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

Re: [Ocaml-lib-devel] [Fwd: Re: [Caml-list] Strings as arrays or lists...]

[Nicolas C. <war...@fr...>]

>   OOps! I guess X. Leroy is giving a strong hint *against* inefficient
> code in the ExtLib... Anybody else reads it likewise?

As I agree with Xavier point of view of not to provide functions in the
StdLib (and that goes as well for the ExtLib) that will give bad ideas of
programming to ocaml people, I have temporaly removed implode/explode for my
local ExtString module ( next version posted soon on this list ).

Nicolas Cannasse