Hi Benedikt,
You're right, we should make this kind of decision. For the moment, we
are focusing on different issues (e.g. standardising I/O, enumerations,
module names, etc), in an effort to obtain a base relatively fast,
something which could be tested both with existing code and new
Somehow I forgot reply back when you posted this reply. And I was just
reminded when I read this:
Batteries is meant to serve the following purposes:
[snip]
provide consistent abstractions and APIs for otherwise independent libraries.
on
On Wed, Nov 19, 2008 at 05:37:51PM +, Richard Jones wrote:
Regarding the advantages see my previous post, where I put some
motivations. Regarding the difficulties of moving modules around, how
harder is than moving a module around when you have no hierarchy?
Well I guess what I _meant_
On Fri, 2008-11-21 at 00:18 +0100, Daniel Bünzli wrote:
Le 20 nov. 08 à 22:12, David Teller a écrit :
If anyone is willing to work on a solution for linking documentation
from third-party libraries into one transparent source, as suggested
by Richard Jones, please contact me.
I'm
Erkki Seppala a écrit :
Richard Jones [EMAIL PROTECTED] writes:
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of underscore ('_').
However, this would take away some of
Excerpts from Maxence Guesdon's message of Wed Nov 19 21:11:24 +0100 2008:
On Wed, 19 Nov 2008 10:46:24 +0100
Paolo Donadeo [EMAIL PROTECTED] wrote:
Couldn't we take inspiration from the Python standard library [1]?
Python hasn't namespace but is provided with a module system similar
to
On Thu, Nov 20, 2008 at 10:28:07AM +0100, Nicolas Pouillard wrote:
No one (I guess) would recommend you to use fully qualified paths as in
Data.Containers.List.length of course. Data.Containers.List.length is the
external name, made to be well organized not to be quick to type, the way
to use
Excerpts from Richard Jones's message of Thu Nov 20 11:33:03 +0100 2008:
On Thu, Nov 20, 2008 at 10:28:07AM +0100, Nicolas Pouillard wrote:
No one (I guess) would recommend you to use fully qualified paths as in
Data.Containers.List.length of course. Data.Containers.List.length is the
Dear list,
Feedback from active members of the list (and a few other shy people
who seem to prefer answering off-list:)) seems to indicate that
Batteries shouldn't have a general hierarchies of modules but rather a
flat list of modules with a few submodules here and there, along with a
Le 20 nov. 08 à 22:12, David Teller a écrit :
If anyone is willing to work on a solution for linking documentation
from third-party libraries into one transparent source, as suggested
by Richard Jones, please contact me.
I'm not sure I understand what you want to acheive. If it is only a
On Tue, Nov 18, 2008 at 12:32:31PM +, Richard Jones wrote:
On Tue, Nov 18, 2008 at 01:15:39PM +0100, David Teller wrote:
Do you see any better way of managing the complexity of all this?
I'm still not getting where the benefit of having this hierarchy is,
except that it adds a Java-like
On Tue, Nov 18, 2008 at 09:50:14PM +, Richard Jones wrote:
If there is nothing in the Net module (and ignoring the linking issue)
you can actually achieve that by using -pack. Just redo the pack on
the client whenever it installs a new package in the namespace. No ?
No because Net
Yes, but that's not a good reason to give up hierarchies completely.
The advantage of hierarchies is to have less top-level roots, which
reduce the likelihood of clashes with external libraries.
I think that the name clash problem is overblown. Really.
Would it arise concretly I prefer
Someone mentionned python's library, if it corresponds to this [1], then I
see no hierarchy there (OTOH nobody tells me that python users are actually
screaming for a hierarchy on their list).
The Python library hierarchy is very flat, for example all markup
tools are presented into a tree of
On Wed, Nov 19, 2008 at 02:38:05PM +0100, Stefano Zacchiroli wrote:
On Tue, Nov 18, 2008 at 12:32:31PM +, Richard Jones wrote:
On Tue, Nov 18, 2008 at 01:15:39PM +0100, David Teller wrote:
Do you see any better way of managing the complexity of all this?
I'm still not getting where
Stefano Zacchiroli wrote:
Still, the idea of doing the pack on the client-side is an interesting
one. [...]
BUT
that would horribly break down with checksum assumptions, I believe.
It would also mean someone's executables (contents and size) will depend
on the libraries installed during
Dear list,
As you know, we've been working for several months of OCaml Batteries
Included. Early in the development, it appeared to us that, with the
large number of modules involved, we would need a hierarchy of modules.
For instance, for the moment, we have a module [System] containing
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of underscore ('_').
Using a dot means that the System namespace cannot be extended by
external packages. If you use an underscore then an
This raises two questions:
1) how important is it to allow third-party modules to extend the
namespace?
2) how important is it to offer a uniform package structure (where
levels are always separated by '.' rather than some level by '.' and
some by '_')?
For the moment, we have considered point 1
Le 18 nov. 08 à 11:29, Erkki Seppala a écrit :
For example I prefer using the least amount of opening of modules,
to make it easier to see where the values come from
Same here. This is why I'm a little bit sceptical about this hierarchy.
With the current standard library if I suddenly want
On Tue, 2008-11-18 at 12:34 +0100, Daniel Bünzli wrote:
Besides Hierarchies are anyway limited in their descriptive power and
one day you'll find something that will fit in two places, Rope is
already an example being both Data.Persistent and Data.Text.
That's correct, there are plenty of
On Tue, Nov 18, 2008 at 01:15:39PM +0100, David Teller wrote:
Do you see any better way of managing the complexity of all this?
I'm still not getting where the benefit of having this hierarchy is,
except that it adds a Java-like complexity and will create
hard-to-manage churn if a module ever
On Tue, 2008-11-18 at 12:34 +0100, Daniel Bünzli wrote:
Le 18 nov. 08 à 11:29, Erkki Seppala a écrit :
For example I prefer using the least amount of opening of modules,
to make it easier to see where the values come from
Same here. This is why I'm a little bit sceptical about this
Ok, that's an interesting point. Now, we just need to all agree on one
standard :)
On Tue, 2008-11-18 at 12:28 +, Benedikt Grundmann wrote:
Do you see any better way of managing the complexity of all this?
Yes don't introduce it at all, make a decision to use or not use labels
and stick
On Tue, 2008-11-18 at 12:32 +, Richard Jones wrote:
API changes are handled really badly in OCaml, ironically because of
the lack of a textual preprocessor. You can't just write this every
time lablgtk / calendar / latest culprit decides to change their API:
#ifdef LABLGTK 210
let
Le 18 nov. 08 à 13:15, David Teller a écrit :
But, to keep things ordered, we will still need modules
[Threads.Threads], [Threads.Mutex], [Threads.RMutex]...
[CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a
hierarchy
already.
If you include in batteries an external package
Hi,
I personally prefer the hierarchy but, once again, the majority
may disagree. So if you believe this is better, the next logical
step would be to design a full and consistent list of modules
including all the modules which already appear in the current
version of Batteries, and with some
On Tue, 2008-11-18 at 05:31 -0800, Dario Teixeira wrote:
Paraphrasing Einstein, I think the hierarchy should be as flat
as possible, but no flatter. For example, I see no reason to
materialise in the hierarchy the separation between persistent
and mutable data structures. The should be a
On Tue, Nov 18, 2008 at 03:23:33PM +0100, David Teller wrote:
On Tue, 2008-11-18 at 05:31 -0800, Dario Teixeira wrote:
Paraphrasing Einstein, I think the hierarchy should be as flat
as possible, but no flatter. For example, I see no reason to
materialise in the hierarchy the separation
On Tue, 2008-11-18 at 14:24 +0100, Daniel Bünzli wrote:
Le 18 nov. 08 à 13:15, David Teller a écrit :
But, to keep things ordered, we will still need modules
[Threads.Threads], [Threads.Mutex], [Threads.RMutex]...
[CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a
hierarchy
On Tue, Nov 18, 2008 at 01:49:09PM +0100, David Teller wrote:
P.S.: I've pointedly ignored your perch on POD :) In my mind, that's a
very different topic. For the moment, we'll stick with ocamldoc.
I've used POD selectively even in OCaml projects, mainly because it is
by far the easiest way to
On Tuesday 18 November 2008 10:06:25 Richard Jones wrote:
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of underscore ('_').
Using a dot means that the System namespace cannot be extended
Excerpts from Jon Harrop's message of Tue Nov 18 19:17:23 +0100 2008:
On Tuesday 18 November 2008 10:06:25 Richard Jones wrote:
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of
On Tue, Nov 18, 2008 at 06:17:23PM +, Jon Harrop wrote:
I don't follow. Can you not use include to extend an existing module:
# module Array = struct
include Array
You're missing the point which is scalability - how to deal with
distributed parties who are loosely coordinated. The
On Tuesday 18 November 2008 18:59:14 Richard Jones wrote:
On Tue, Nov 18, 2008 at 06:17:23PM +, Jon Harrop wrote:
I don't follow. Can you not use include to extend an existing module:
# module Array = struct
include Array
You're missing the point which is scalability - how to
On Tue, Nov 18, 2008 at 08:17:36PM +, Jon Harrop wrote:
If the library creator did not use functors or classes to make their design
reusable then the only solution for the user is to include all of the
implementations they require:
You're talking about something completely different.
In
Le 18 nov. 08 à 20:22, Richard Jones a écrit :
The proposal is to have a hierarchy of OCaml modules, of this sort:
Net
Net.Amazon
Net.BitTorrent
Net.FTPServer
(and a million more)
which doesn't scale.
If there is nothing in the Net module (and ignoring the linking issue)
you can
On 11/18/2008 7:17 PM, Jon Harrop wrote:
I don't follow. Can you not use include to extend an existing module:
# module Array = struct
include Array
let empty = [||]
end;;
module Array :
sig
external length : 'a array - int = %array_length
...
val empty : 'a
On Tuesday 18 November 2008 09:56:18 David Teller wrote:
Now, we've decided that our current hierarchy is perhaps somewhat clumsy
and that it may benefit from some reworking. Before we proceed, we'd
like some feedback from the community...
I only have one major concern: you say with the large
On 11/19/2008 12:49 AM, Jon Harrop wrote:
Perhaps that could be solved with extensive Camlp4 hacking to rename the
previous modules (even coming from an include) to avoid the clash?
I don't think so. It seems you need type information.
That brings its own problems, of course. You no longer
On Tuesday 18 November 2008 22:07:33 Alain Frisch wrote:
and you want to extend M11, you need to write:
module M' = struct
module M1 = struct
module M11 = struct include M.M1.M11 (* extension here *) end
module M12 = M.M1.M12
module M13 = M.M1.M13
...
end
On Tue, 2008-11-18 at 23:30 +, Jon Harrop wrote:
On Tuesday 18 November 2008 09:56:18 David Teller wrote:
I only have one major concern: you say with the large number of modules
involved, we would need a hierarchy of modules but the number of modules
involved is tiny (a few dozen in
On Wednesday 19 November 2008 06:29:52 David Teller wrote:
On Tue, 2008-11-18 at 23:30 +, Jon Harrop wrote:
I only have one major concern: you say with the large number of modules
involved, we would need a hierarchy of modules but the number of modules
involved is tiny (a few dozen in
43 matches
Mail list logo
