ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] doc

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

> Documentation is not correctly produced for many modules,
> including for example extHashtbl.
>
> I suspect this is a bug in ocamldoc. I think so, because
> the same problem exists for the standard ocaml distribution.
> [Funny no one has comment on this?]
>
> Here's the whole page I see:
> -------------------------------------------------
> Previous  Up  Next
>                            Module ExtHashtbl
>
> module ExtHashtbl: sig  end
> Extra functions over hashtables.

This is not a bug.
This means that the extHashtbl module is only containing a module
ExtHashtbl.
This way you can simply do :

open ExtHashtbl;

to override the Hashtbl ocaml std one.
Simply follow the link on module ExtHashtbl to get the documentation.

Nicolas Cannasse

[Ocaml-lib-devel] doc

[skaller <sk...@oz...>]

Documentation is not correctly produced for many modules,
including for example extHashtbl.

I suspect this is a bug in ocamldoc. I think so, because
the same problem exists for the standard ocaml distribution.
[Funny no one has comment on this?]

Here's the whole page I see:
-------------------------------------------------
Previous  Up  Next
                           Module ExtHashtbl

module ExtHashtbl: sig  end
Extra functions over hashtables.


________________________________________________________________________
module Hashtbl: sig  end

Re: [Ocaml-lib-devel] Tabs in sources

[skaller <sk...@oz...>]

On Mon, 2003-10-06 at 04:22, Nicolas Cannasse wrote:
> > > > since the INRIA-team has decided to avoid tabulators in sources, and

> Another unexpected side effect of tabs is to keep the file size small :-)

This is a side effect of badly designed file systems that can't
compress data.

Re: [Ocaml-lib-devel] 80-chars limit

[skaller <sk...@oz...>]

On Sun, 2003-10-05 at 21:34, Nicolas Cannasse wrote:

> programming, this limit can vary a lot. Fixing it to 80 chars is nonsense.

80 chars is in fact way too much. 65 is more reasonable.
That is the amount of reasonbly sized monospaced font text
that can be fitted on a book page.

Code should be readable in a fairly constrained viewport.
This has nothing to do with style, but with the limitations
of media.

I learned the hard way typesetting code for publication.
Actual code often goes way over the limit. However it
can be grossly inconvenient. For example I use Vim, and Vim
is super brain dead with horizontal scrolling. I don't fill
up the whole width of my screen with one editor window either.

Don't get me wrong, I often write code that exceeds sensible
line widths. But it is pain, because ALL my code is
literate programmed, and when I typeset it for LaTeX,
it complains bitterly every single time the right margin
is breached.

TeX is GOD when it comes to typesetting quality.
If TeX says badness 30000 for breaching a right
margin, you'd better believe it :-)

Re: [Ocaml-lib-devel] Unicode, Camomile et al

[skaller <sk...@oz...>]

On Sun, 2003-10-05 at 20:09, Sylvain LE GALL wrote:
> Hello,
> 
> I have one question :
> Is the unicode support of extlib, compatible with camomile ?

It IS the camomile code :-)

Re: [Ocaml-lib-devel] Next Step

[skaller <sk...@oz...>]

On Sun, 2003-10-05 at 19:59, Nicolas Cannasse wrote:
> Hi people !
> 
> Right now, SF downloads are showing that there is (only) around 60 peoples
> that downloaded the ExtLib (no counts on how many are actually using it :-).

Well, I'm concerned still with the semantics of Enum,
and since Enum-extending other data structures is a key
feature ..

Re: [Ocaml-lib-devel] Next Step

[skaller <sk...@oz...>]

On Sun, 2003-10-05 at 19:59, Nicolas Cannasse wrote:
> Hi people !

> Any proposals for new features are welcome.
> IMHO, it would be useful to add support for Xml ( XmlLight :
> http://tech.motion-twin.com ) into the ExtLib.

I don't. XML is a specialist facility, not a general 
purpose one. By all means a separate library, or twenty.

Re: [Ocaml-lib-devel] Tabs in sources

[skaller <sk...@oz...>]

On Sun, 2003-10-05 at 19:49, Nicolas Cannasse wrote:

> Tabs are entirely my fault since there is no auto-tab on my windows editor
> (no flames here please). 

I regularly just use the space bar...

> We concluded that the "working" sources can
> contains tabs but that once finalized we will switch from tabs to spaces ( 2
> ou 4 , matter of taste ).

i prefer 2 

Re: [Ocaml-lib-devel] 80-chars limit

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

Nicolas Cannasse wrote:
> 
> > On Sun, 05 Oct 2003, Nicolas Cannasse wrote:
> > > I agree that short lines are better but I dislike to break some code
> into
> > > several expressions (or shorten identifier name or other tricks) only to
> > > stick to that outdated 80 chars limit.
> >
> > It's outdated in the sense that our displays and printers can handle
> > better than this. The question is whether humans can. Enforcing this
> > (or another) limit keeps people from writing unreadable spaghetti code.
> > Unless you use extremely long identifiers, which should be discouraged
> > in any case, 80 chars should be more than enough.
> 
> Not a flame, but just some comments about that :
> I just don't like such arbitrary rules made in the name of "protecting the
> programmer from writing bad code". I mean, if a programmer is actually that
> bad then he will write unreadable code no matter the chars limit :-)
> Depending on the programming language, on the ident size and naming
> conventions, and many others factors such as the programmer own style of
> programming, this limit can vary a lot. Fixing it to 80 chars is nonsense.

I agree that nothing can protect the bad programmer from writing bad
code.

However, I don't feel that 80 characters is outdated.  I use the high end
laptop work bought me with a 1600x1200 screen (thank you very much :) ) to
open 6 ssh windows at 80 characters and have each one open to a different
file or task in xemacs or in the shell.  So I would like to make a point of
keeping at 80 characters.

Best,
Blair

-- 
Blair Zajac <bl...@or...>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Ocaml-lib-devel] 80-chars limit

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

Markus Mottl wrote:
> 
> Hi,
> 
> since we are at it (syntax flamewars): I'd also propose keeping the
> horizontal limit of source lines to 80 characters...

Agreed.

Blair

-- 
Blair Zajac <bl...@or...>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Ocaml-lib-devel] Tabs in sources

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

Markus Mottl wrote:
> 
> Hi,
> 
> since the INRIA-team has decided to avoid tabulators in sources, and
> since I also think that this is good style, I'd propose that each tab
> be replaced by (two) ordinary spaces. Any comments?

I don't mind the number of spaces a tab is replaced with, but I
do want tabs to disappear entirely.

Best,
Blair

-- 
Blair Zajac <bl...@or...>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Ocaml-lib-devel] Tabs in sources

[Brian H. <bh...@sp...>]

On Sun, 5 Oct 2003, Nicolas Cannasse wrote:

> I agree choosing the tabstop is convenient. I personnaly also prefer "large"
> 4-spaces indents agains "short" 2-spaces ones. IMHO they make the code more
> readable. But as you might notice, the 80 chars limit will not be the same
> if the tabstops is 2 or 4 :-) The only point is that the "community" is
> somehow agreeing not to use tabs. If it would be only my choice, I would
> keep tabs.

I agree: given a choice, I'd take tabs and resizing my window.

> 
> Another unexpected side effect of tabs is to keep the file size small :-)
> 

This is such a small difference I'd declare it irrelevent.

Brian

Re: [Ocaml-lib-devel] 80-chars limit

[Brian H. <bh...@sp...>]

On Sun, 5 Oct 2003, Markus Mottl wrote:

> Hi,
> 
> since we are at it (syntax flamewars): I'd also propose keeping the
> horizontal limit of source lines to 80 characters...
> 

80 characters at what tab stop?  My code rarely breaks the 80 column rule 
with tabstop <= 4, but with tabstop > 4 breaks it quite regularly.

By the way, the paren in column 81 is very annoying to me.  It breaks the
indentation flow of the code, as my editor just wraps the line.  I'd
prefer things broken up into multiple lines.  But this is only important
for code I'm heavily working on at the moment.  I don't consider these so
much hard and fast rules that the code nazis will haul you away for
violating, as strong recommendations that you should only break for a good
reason.

One thing I will be code-nazi about: major reformatting should be seperate
checkins from actual code changes.  Checkins of the form "changed the
indentation (touching almost every line in file) and fixed a bug" make 
finding what was changed to fix the bug basically impossible.

Brian

Re: [Ocaml-lib-devel] Next Step

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

> Was I dreaming when I noticed that ExtLib was now part of the CDK?
> 
> Brian

Looks like a nightmare then : the CDK is dead and no longer maintained. 
Was it a ghost ? :-)

Nicolas Cannasse

Re: [Ocaml-lib-devel] Tabs in sources

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

> > > since the INRIA-team has decided to avoid tabulators in sources, and
> > > since I also think that this is good style, I'd propose that each tab
> > > be replaced by (two) ordinary spaces. Any comments?
[...]
> The advantage of tabs over spaces is that it allows us to avoid a flamewar
> over *how many* spaces to indent.  This way, just set your tabstops to
> whatever you want.  You can set your tabstops to 2, I can set them to 4,
> we're both happy, all the code looks correct, and we're not constantly
> reindenting each other's code.

I agree choosing the tabstop is convenient. I personnaly also prefer "large"
4-spaces indents agains "short" 2-spaces ones. IMHO they make the code more
readable. But as you might notice, the 80 chars limit will not be the same
if the tabstops is 2 or 4 :-) The only point is that the "community" is
somehow agreeing not to use tabs. If it would be only my choice, I would
keep tabs.

Another unexpected side effect of tabs is to keep the file size small :-)

Nicolas Cannasse

Re: [Ocaml-lib-devel] Next Step

[Brian H. <bh...@sp...>]

Was I dreaming when I noticed that ExtLib was now part of the CDK?

Brian

Re: [Ocaml-lib-devel] Tabs in sources

[Brian H. <bh...@sp...>]

On Sun, 5 Oct 2003, Nicolas Cannasse wrote:

> > since the INRIA-team has decided to avoid tabulators in sources, and
> > since I also think that this is good style, I'd propose that each tab
> > be replaced by (two) ordinary spaces. Any comments?
> 
> We already have been discussed about that :
> Tabs are entirely my fault since there is no auto-tab on my windows editor
> (no flames here please). We concluded that the "working" sources can
> contains tabs but that once finalized we will switch from tabs to spaces ( 2
> ou 4 , matter of taste ). Looks like this second point have been forgot
> before the release :-)

I vote for 4. :-)

Seriously, having worked with it for a while, I've found I don't mind 
tabulated source.  So long as it's tabs first, then spaces.  Yeah, I know 
that if you search the past emails, I was opposed to this before.

One important point I will make: windows and unix seem to have a different 
idea of what a tab means.  On windows, a line " \tx" causes the x to be in 
column 9 (assuming a tabstop of 8), while on unix the x is in column 8.  
In windows, a tab moves you tabstop columns to the right, while in unix a 
tab moves you to the next column which is an integer multiple of the 
tabstop.

Note that tabs followed by spaces is always correct, so "\t x" always puts 
the x in column 9 (assuming a tabstop of 8) on both windows and unix.  
It's spaces followed by tabs which create a mess.

I don't know if people noticed this or not, but I used this in my code 
when I'm lining code up with specific parts of the line above.  For 
instance, if I have a multi-line let statement, it'll be entered like:
\t\tlet x = some stuff
\t\t        some more stuff
\t\tin
...

This way, no matter what you set your tabstop to, the some more stuff on 
the second line is lined up correctly with the some stuff on the first 
line.  On unix and on windows.

The advantage of tabs over spaces is that it allows us to avoid a flamewar 
over *how many* spaces to indent.  This way, just set your tabstops to 
whatever you want.  You can set your tabstops to 2, I can set them to 4, 
we're both happy, all the code looks correct, and we're not constantly 
reindenting each other's code.

Brian

[Ocaml-lib-devel] pMap.ml

[Markus M. <ma...@oe...>]

Hi,

I have rewritten Nicolas' pMap.ml implementation (polymorphic maps). It's
purely functional and more regular now. Could somebody please review
the code whether it's ok for the CVS-repository?

Thanks!

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          ma...@oe...

Re: [Ocaml-lib-devel] Unicode, Camomile et al

[Yamagata Y. <yor...@mb...>]

From: "Sylvain LE GALL" <syl...@po...>
Subject: Re: [Ocaml-lib-devel] Unicode, Camomile et al
Date: Sun, 5 Oct 2003 14:08:45 +0200

> So, the question is : could i have the two libraries ( camomile and
> extlib ) at the same time for one app and if i can have it, could i
> use the same data structure in the two library ( the second question is
> problematic to my mind, because even if they had the same name, the two
> data structure could not cooperate... ).

Both codes are exactly same, so have exactly same interfaces. Since
uchar is an abstract type, you cannot mix both types, that is, you
cannot pass extlib's uchar to camomile's functions and vice verse.  On
the other hand, UTF-8 string is a normal string.  So you can pass them
around.

In future, when extlib is widespread, I may deprecate uchar and utf8
of camomile, and make camomile an extension of unicode facilities of
extlib.

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] Function "read_file"?

[Markus M. <ma...@oe...>]

On Sun, 05 Oct 2003, Nicolas Cannasse wrote:
> I agree, but if I follow the specification of really_input :
> 
> "Read len characters from the given channel, storing them in string buf,
> starting at character number pos. Raise End_of_file if the end of file is
> reached before len characters have been read. Raise Invalid_argument
> "really_input" if pos and len do not designate a valid substring of buf."
> 
> Then it shouldn't raise any exception.

The only possibility for the exception "End_of_file" to occur is when the
file somehow gets truncated (= changed) after opening but before/during
reading. The function should raise some kind of exception in this case,
I think, because the user might be completely surprised about the suddenly
shrinking file and should be notified. Of course, this behaviour should
be mentioned in the documentation!

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          ma...@oe...

Re: [Ocaml-lib-devel] Unicode, Camomile et al

[Sylvain LE G. <syl...@po...>]

On Sun, Oct 05, 2003 at 12:28:24PM +0200, Nicolas Cannasse wrote:
> > Hello,
> >
> > I have one question :
> > Is the unicode support of extlib, compatible with camomile ?
> >
> > Thank you for extlib !
> >
> > Kind regard
> > Sylvain LE GALL
> 
> Bonjour Sylvain,
> 
> Since that author of Unicode for extlib is the same as camomile ( Yamagata
> Yoriyuki ) you should expect that they are compatible, but I'm not sure what
> you exactly mean by "compatible" :-) Please have a look at the ocamldoc on
> http://ocaml-lib.sf.net
> 
> Nicolas Cannasse
> 

Hello,

Well i maybe mistyped my question ;->

So, the question is : could i have the two libraries ( camomile and
extlib ) at the same time for one app and if i can have it, could i
use the same data structure in the two library ( the second question is
problematic to my mind, because even if they had the same name, the two
data structure could not cooperate... ).

Regard
Sylvain LE GALL

Re: [Ocaml-lib-devel] Function "read_file"?

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

> one function that people may want to have in the standard library is
> "read_file", which opens a file with a given name and returns its complete
> contents as a string:
[...]
> This functions is optimal for files, because it uses the length of the
> file to determine the required buffer size.

Nice

> Note the following behaviour: if reading causes an exception, the program
> will attempt to close the opened file. If this also causes an exception,
> the FIRST exception will be reraised. I think this is the most reasonable
> way to handle this.

I agree, but if I follow the specification of really_input :

"Read len characters from the given channel, storing them in string buf,
starting at character number pos. Raise End_of_file if the end of file is
reached before len characters have been read. Raise Invalid_argument
"really_input" if pos and len do not designate a valid substring of buf."

Then it shouldn't raise any exception.

Nicolas Cannasse

Re: [Ocaml-lib-devel] 80-chars limit

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

> On Sun, 05 Oct 2003, Nicolas Cannasse wrote:
> > I agree that short lines are better but I dislike to break some code
into
> > several expressions (or shorten identifier name or other tricks) only to
> > stick to that outdated 80 chars limit.
>
> It's outdated in the sense that our displays and printers can handle
> better than this. The question is whether humans can. Enforcing this
> (or another) limit keeps people from writing unreadable spaghetti code.
> Unless you use extremely long identifiers, which should be discouraged
> in any case, 80 chars should be more than enough.

Not a flame, but just some comments about that :
I just don't like such arbitrary rules made in the name of "protecting the
programmer from writing bad code". I mean, if a programmer is actually that
bad then he will write unreadable code no matter the chars limit :-)
Depending on the programming language, on the ident size and naming
conventions, and many others factors such as the programmer own style of
programming, this limit can vary a lot. Fixing it to 80 chars is nonsense.
Just let the programmer have his own judgement on the code readability he's
been writing.

Nicolas Cannasse

Re: [Ocaml-lib-devel] 80-chars limit

[Markus M. <ma...@oe...>]

On Sun, 05 Oct 2003, Nicolas Cannasse wrote:
> I agree that short lines are better but I dislike to break some code into
> several expressions (or shorten identifier name or other tricks) only to
> stick to that outdated 80 chars limit.

It's outdated in the sense that our displays and printers can handle
better than this. The question is whether humans can. Enforcing this
(or another) limit keeps people from writing unreadable spaghetti code.
Unless you use extremely long identifiers, which should be discouraged
in any case, 80 chars should be more than enough.

> I agree everyone is free to use its
> own text editor - in 80 rows text mode or in 1600x1200 pixels graphics
> mode - but when it turns into adding lines jumps into a nice expression only
> because there is a damn paranthesis on the 81th row that's troublesome.

And if there is just one damn parenthesis on the 82nd row, or 83rd, or...

Get the drift? ;-)

> Now, after having a quick look at some ExtLib sources, it appears
> that the 80chars limit is rarely overriden, so modifying some lines
> here and there should not be so big thing if it keeps further people
> flames away :-)

You are absolutely right :-)

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          ma...@oe...

Re: [Ocaml-lib-devel] 80-chars limit

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

> Hi,
>
> since we are at it (syntax flamewars): I'd also propose keeping the
> horizontal limit of source lines to 80 characters...
>

Uh , this one is more problematic.
I agree that short lines are better but I dislike to break some code into
several expressions (or shorten identifier name or other tricks) only to
stick to that outdated 80 chars limit. I agree everyone is free to use its
own text editor - in 80 rows text mode or in 1600x1200 pixels graphics
mode - but when it turns into adding lines jumps into a nice expression only
because there is a damn paranthesis on the 81th row that's troublesome.
That's for my personal opinion.
Now, after having a quick look at some ExtLib sources, it appears that the
80chars limit is rarely overriden, so modifying some lines here and there
should not be so big thing if it keeps further people flames away :-)

Nicolas Cannasse