RE: [Caml-list] Namespace proposal

RE: [Caml-list] Namespace proposal

[Gurr, David (MED, self)]

My two cents worth: Please dont copy package ideas from 
languages that lack functors.  And Java's package ==
directory idea is far from beloved by all.  -D

> -----Original Message-----
> From: Vitaly Lugovsky [mailto:vsl@ontil.ihep.su]
> Sent: Thursday, August 15, 2002 8:53 AM
> To: Yurii A. Rashkovskii
> Cc: caml-list@inria.fr
> Subject: Re: [Caml-list] Namespace proposal
> 
> 
> On Thu, 15 Aug 2002, Yurii A. Rashkovskii wrote:
> 
> > Hi Vitaly!
> > 
> > >  I think that the best and the most natural solution is something
> > > like Java or Python packages...
> > 
> > Well, as it was proposed in original mail :)
> 
>  I mean slightly different approach: no need in any syntax sugar, but
> only using the directory structure. It's much better then cifering 
> package contents and names inside Makefiles, and it does not need any
> significiant modifications to the existing OCaml code.
> 
> 
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Namespace proposal

[Vitaly Lugovsky]

On Thu, 15 Aug 2002, Gurr, David (MED, self) wrote:

> My two cents worth: Please dont copy package ideas from 
> languages that lack functors.  And Java's package ==
> directory idea is far from beloved by all.  -D

 For me package is not a modules collection, but just
a way of multi-word module naming. It's not so easy to
give short and still adequate names to the modules, but
something like Db.Core.Storage looks much better then
Dbstorage, and Storage can still be accessed just as
"Storage" from modules of the same "package". Just a naming
way, nothing more.




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: Namespace proposal

[Michaël Grünewald]

Vitaly Lugovsky <vsl@ontil.ihep.su> writes:

> On Thu, 15 Aug 2002, Gurr, David (MED, self) wrote:
> 
> > My two cents worth: Please dont copy package ideas from 
> > languages that lack functors.  And Java's package ==
> > directory idea is far from beloved by all.  -D
> 
>  For me package is not a modules collection, but just
> a way of multi-word module naming. It's not so easy to
> give short and still adequate names to the modules, but
> something like Db.Core.Storage looks much better then
> Dbstorage, and Storage can still be accessed just as
> "Storage" from modules of the same "package". Just a naming
> way, nothing more.

[...]

You can have modules with a name

Veryvery.LOng.But.self.ExPl4n4t0ry.N4m3

that can be hard to type and read, but by saying

module Forshort = Veryvery.LOng.But.self.ExPl4n4t0ry.N4m3
module Storage = Db.Core.Storage

you will have shorter names that can be hidden, by removing them in the
signature file.
-- 
Michaël Grünewald <michael-grunewald@wanadoo.fr>  - RSA PGP Key ID: 0x20D90C12
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal

[John Max Skaller]

Gurr, David (MED, self) wrote:

> My two cents worth: Please dont copy package ideas from 
> languages that lack functors.  And Java's package ==
> directory idea is far from beloved by all.  -D

While I agree that 'package == directory' has problems,
languages that do not properly allow installation
of third party packages in such a way as to avoid
name clashes in supporting components, have even
more problems.

Ocaml is in this position. It can't be easily
use in large projects which incorporate many third
party libraries.

Separable installation
is possible but clumbsy (use OCAMLPATH),
but there is no associated mechanism for nameclash avoidance.

In theory, one could use nested modules to avoid nameclashes.
In practice that is out of the question because
it requires all the modules be in one file.

C had exactly the same problem, which is why
C++ added namespaces (independently of
file locations). Python had this problem,
which is why it added packages (dependent on
directory structure).

I personally favour the Eiffel approach because
it is the most flexible -- the dependence of
top level component names on files/directories
is defined by a secondary configuration language.
However, it is a somewhat heavy approach.

One thing is for sure though. The ability to install
third party packages in directories, and the ability
to avoid name clashes in supporting components,
are both required for programming in the large.

Ocaml is so close to a solution: both separable
installation and name clash avoidance are possible,
but the mechanisms cannot be easily integrated.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal: XML variant

[Alessandro Baretta]

I thoroughly dislike any "package ~= directory" solution, 
yet I think a namespace construct should be present in the 
language in order to allow interoperability between 
different projects with different naming conventions. I 
propose a scheme à la XML, where namespaces are URIs 
belonging to the person or organization which releases the 
associated code.

I propose to add an optional namespace construct to 
explicitly associate namespace URIs with namespace names.

namespace MyBigProject = "http://alexbaretta.com/big_project/"


module Foobar in MyBigProject = ...

When I want to use somebody else's code I code just define a 
namespace name. Consider, for example, that I need to use 
Pxp in my project. Nowadays, I'd have to write

open Pxp_document
open Pxp_yacc

With my scheme I'd write

namespace Pxp = 
"http://www.ocaml-programming.de/programming/pxp.html"
(* or whatever URI Gerd might choose. *)

open Document in Pxp;
open Yacc in Pxp;
(* Assuming Gerd would adopt this namespace scheme *)

This is very very similar to the approach taken by XML. I 
think this is the model we should refer to when discussing a 
namespace scheme for OCaml. This technique only serves the 
purpose of avoiding name clashes between modules: every 
module name lives within the namespace belonging to and 
defined by the author. No assumptions are made w/respect to 
directory structure. Yet, the build evironment, with some 
help from such a program as ocamldep, could extract 
information from the namespace URIs and use it as a hint for 
source file search. Yet, harnessing URI for the sake of 
filename resolution would be entirely optional and delegated 
to the build environment.

I hope to get some feedback on this proposal. What do you 
guys think about it?

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal: XML variant

[Jeffrey Palmer]

On Friday 30 August 2002 01:02 pm, Alessandro Baretta wrote:
> I thoroughly dislike any "package ~= directory" solution,
> yet I think a namespace construct should be present in the
> language in order to allow interoperability between
> different projects with different naming conventions. I
> propose a scheme à la XML, where namespaces are URIs
> belonging to the person or organization which releases the
> associated code.
>
> I propose to add an optional namespace construct to
> explicitly associate namespace URIs with namespace names.
>
> namespace MyBigProject = "http://alexbaretta.com/big_project/"
>
>

Eeek!

Please, let's not entertain any of the rampant stupidity that the W3C seems so 
mired in. I've always thought that the concept of using URIs for namespaces, 
parameter settings, etc., was the most ridiculous thing I've ever seen. I 
mean, let's be honest here - HTTP is a network _protocol_, and it has nothing 
to do with anything namespace or parameter related. The thing that really 
irks me about the whole scheme is that most of the time these aren't even 
_valid_ URIs (i.e., inaccessible).

I'm all for a hierarchical namespace that's not related to the filesystem (In 
Java it always ended up causing headaches for large projects - compilers that 
"intelligently" put your compiled code in the correct package directory, 
etc.). It seems that the question of segmenting libraries according to 
directory should be a decision that's left up to the implementor, as it is 
currently.

All of this is, of course, my own opinion, so take it with the corresponding 
pinch of salt.

Cheers,

	- j


-- 
The river is moving.
The blackbird must be flying.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal: XML variant

[james woodyatt]

On Friday, Aug 30, 2002, at 13:25 US/Pacific, Jeffrey Palmer wrote:
> On Friday 30 August 2002 01:02 pm, Alessandro Baretta wrote:
>>
>> I propose to add an optional namespace construct to
>> explicitly associate namespace URIs with namespace names.
>
> Please, let's not entertain any of the rampant stupidity that the W3C 
> seems so
> mired in. I've always thought that the concept of using URIs for 
> namespaces,
> parameter settings, etc., was the most ridiculous thing I've ever 
> seen. [...]

A more constructive way to say this might be to observe that any syntax 
for a global namespace of Objective Caml types and values could be 
transformed into a URN by simply publishing an Internet RFC that 
defined the syntax for the namespace specific string, according to the 
requirements of RFC 2141.

It would seem desirable to choose a namespace syntax that lends itself 
easily to encoding in a URN.

Here's another strawman for discussion.

-----

The obvious choice for a namespace identifier is "ocaml" and this would 
produce URN's of the following form:

	<urn:ocaml:some:hierarchy:YourModuleHere.your_type_or_value>

I chose a ':' character to separate levels in the namespace hierarchy 
arbitrarily.  Other characters like '/' or '.' could easily be 
considered as well.

In this example, you could imagine that the compiler could be invoked 
with a namespace flag, like so:

	ocamlc -N :some:hierarchy -c yourModuleHere.ml -o yourModuleHere.cmo

You could then define a language construct that looks kinda like the 
following:

	namespace N = :some:hierarchy
	module M = N:YourModuleHere

The 'namespace' keyword would define an alias for a prefix to the 
modules in some part of the global namespace, and it would be used in a 
straightforward way as shown above to construct the names of externally 
defined module types.

The namespace would be encoded in the .cmi and .cmo files, and the tool 
chain would need to respect them as it searched for signatures and 
modules to reference.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal: XML variant

[Blair Zajac]

Jeffrey Palmer wrote:
> 
> On Friday 30 August 2002 01:02 pm, Alessandro Baretta wrote:
> > I thoroughly dislike any "package ~= directory" solution,
> > yet I think a namespace construct should be present in the
> > language in order to allow interoperability between
> > different projects with different naming conventions. I
> > propose a scheme à la XML, where namespaces are URIs
> > belonging to the person or organization which releases the
> > associated code.
> >
> > I propose to add an optional namespace construct to
> > explicitly associate namespace URIs with namespace names.
> >
> > namespace MyBigProject = "http://alexbaretta.com/big_project/"
> >
> >
> 
> Eeek!
> 
> Please, let's not entertain any of the rampant stupidity that the W3C seems so
> mired in. I've always thought that the concept of using URIs for namespaces,
> parameter settings, etc., was the most ridiculous thing I've ever seen. I
> mean, let's be honest here - HTTP is a network _protocol_, and it has nothing
> to do with anything namespace or parameter related. The thing that really
> irks me about the whole scheme is that most of the time these aren't even
> _valid_ URIs (i.e., inaccessible).
> 
> I'm all for a hierarchical namespace that's not related to the filesystem (In
> Java it always ended up causing headaches for large projects - compilers that
> "intelligently" put your compiled code in the correct package directory,
> etc.). It seems that the question of segmenting libraries according to
> directory should be a decision that's left up to the implementor, as it is
> currently.
> 
> All of this is, of course, my own opinion, so take it with the corresponding
> pinch of salt.
> 
> Cheers,

Tag URI may be a good choice.

http://www.taguri.org/

    The tag algorithm lets people create character strings which no
    one else using the same algorithm could ever create. It is simple
    enough to do in your head, and the resulting strings can be easy
    to read, write, and remember. You can use the strings wherever
    you need a unique identifier conforming to the URI (URL) Syntax 

They look like this:

    tag:sandro@world.std.org,2001-06-05:Taiko

Best,
Blair

-- 
Blair Zajac <blair@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal

[Yurii A. Rashkovskii]

Hi Vitaly!

On Fri, 16 Aug 2002, Vitaly Lugovsky wrote:

>  Modules are reffered from the *.ml files - so, they may (not "must") have
> some hints about the search order. And if we'll have some syntax for this
> hints, that will be enough to avoid all the current problems with module 
> naming.

Can you provide us with an example of such syntax (approx.)?

-- 
Regards,
Yurii.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Namespace proposal

[Vitaly Lugovsky]

On Fri, 16 Aug 2002, M E Leypold @ labnet wrote:

>  >  No subpackages. Dots in the name does not mean any hierarchy - but just
>  > a "name search path" hints. Just the same modules as we have now, but with
>  > a slightly more intelligent way of name resolving.
> 
> 
> 'name resolving' and 'path search' should be part of the surrounding
> build system, not the language. I do not want to see any (build time)
> paths in my *.ml source files.

 Modules are reffered from the *.ml files - so, they may (not "must") have
some hints about the search order. And if we'll have some syntax for this
hints, that will be enough to avoid all the current problems with module 
naming.



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Namespace proposal

[Vitaly Lugovsky]

On Thu, 15 Aug 2002, Gurr, David (MED, self) wrote:

> >  No subpackages. Dots in the name does not mean any hierarchy 
> > - but just
> > a "name search path" hints. Just the same modules as we have 
> > now, but with
> > a slightly more intelligent way of name resolving.
> 
> Isnt that the equiv of the universally acclaimed all singing 
> acme of perfection Java package == directory system?

 No. Please note - I said "hints", not "constraints".



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Namespace proposal

[M E Leypold @ labnet]

Vitaly Lugovsky writes:


 > 
 >  No subpackages. Dots in the name does not mean any hierarchy - but just
 > a "name search path" hints. Just the same modules as we have now, but with
 > a slightly more intelligent way of name resolving.


'name resolving' and 'path search' should be part of the surrounding
build system, not the language. I do not want to see any (build time)
paths in my *.ml source files.

Regards -- Markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Namespace proposal

[Gurr, David (MED, self)]

>  No subpackages. Dots in the name does not mean any hierarchy 
> - but just
> a "name search path" hints. Just the same modules as we have 
> now, but with
> a slightly more intelligent way of name resolving.

Isnt that the equiv of the universally acclaimed all singing 
acme of perfection Java package == directory system?
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Namespace proposal

[Gurr, David (MED, self)]

> -----Original Message-----
> From: Fernando Alegre [mailto:fernando@cc.gatech.edu]
> Sent: Thursday, August 15, 2002 10:46 AM
> To: caml-list@inria.fr
> Subject: Re: [Caml-list] Namespace proposal
> 
> 
> On Thu, Aug 15, 2002 at 12:13:47PM -0500, Gurr, David (MED, 
> self) wrote:
> > 
> > >  For me package is not a modules collection, but just
> > > a way of multi-word module naming. It's not so easy to
> > > give short and still adequate names to the modules, but
> > > something like Db.Core.Storage looks much better then
> > > Dbstorage, and Storage can still be accessed just as
> > > "Storage" from modules of the same "package". Just a naming
> > > way, nothing more.
> > 
> > And what happens when you need to abstract over a 
> module/sub-package? -D
> 
> I think a naming convention like this is definitely needed, 
> but in order
> not to be confused with sub-modules, a different character 
> should be used.
> For example:
> 
> Db/Core/Storage could be a legal module name (in 
> Db/Core/storage.ml), and
> Db.Core.Storage could be a module hierarchy defined in Db.ml, and
> Db/Core/Storage.Medium could be a submodule defined in 
> Db/Core/storage.ml,...
> 
> An added advantage of this syntax is that it is consistent 
> with the overall
> esthetics of the OCaml language (i.e., ugly). :-)
> 
> Fernando
> 

I agree with the ugly part.  But it is consistent with
C not OCaml, IMHO. The difference between structures 
(ie first order modules) and packages as far as I can 
see is that you can abstract over modules and you can 
individually type check modules. If you have a language
where abstraction and type checking are non-existent
then packages might be a fine thing.  Separate compilation
for nested modules and a name mangling scheme for their
file names might be useful for OCaml.  -D
 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal

[Yurii A. Rashkovskii]

Hi Vitaly!

On Thu, 15 Aug 2002, Vitaly Lugovsky wrote:

>  No subpackages. Dots in the name does not mean any hierarchy - but just
> a "name search path" hints. Just the same modules as we have now, but with
> a slightly more intelligent way of name resolving.

I agree with directory packaging

-- 
Regards,
Yurii.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal

[Fernando Alegre]

On Thu, Aug 15, 2002 at 12:13:47PM -0500, Gurr, David (MED, self) wrote:
> 
> >  For me package is not a modules collection, but just
> > a way of multi-word module naming. It's not so easy to
> > give short and still adequate names to the modules, but
> > something like Db.Core.Storage looks much better then
> > Dbstorage, and Storage can still be accessed just as
> > "Storage" from modules of the same "package". Just a naming
> > way, nothing more.
> 
> And what happens when you need to abstract over a module/sub-package? -D

I think a naming convention like this is definitely needed, but in order
not to be confused with sub-modules, a different character should be used.
For example:

Db/Core/Storage could be a legal module name (in Db/Core/storage.ml), and
Db.Core.Storage could be a module hierarchy defined in Db.ml, and
Db/Core/Storage.Medium could be a submodule defined in Db/Core/storage.ml,...

An added advantage of this syntax is that it is consistent with the overall
esthetics of the OCaml language (i.e., ugly). :-)

Fernando


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Namespace proposal

[Vitaly Lugovsky]

On Thu, 15 Aug 2002, Gurr, David (MED, self) wrote:

> > > My two cents worth: Please dont copy package ideas from 
> > > languages that lack functors.  And Java's package ==
> > > directory idea is far from beloved by all.  -D
> > 
> >  For me package is not a modules collection, but just
> > a way of multi-word module naming. It's not so easy to
> > give short and still adequate names to the modules, but
> > something like Db.Core.Storage looks much better then
> > Dbstorage, and Storage can still be accessed just as
> > "Storage" from modules of the same "package". Just a naming
> > way, nothing more.
> 
> And what happens when you need to abstract over a module/sub-package? -D

 No subpackages. Dots in the name does not mean any hierarchy - but just
a "name search path" hints. Just the same modules as we have now, but with
a slightly more intelligent way of name resolving.




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Namespace proposal

[Gurr, David (MED, self)]

> -----Original Message-----
> From: Vitaly Lugovsky [mailto:vsl@ontil.ihep.su]
> Sent: Thursday, August 15, 2002 10:00 AM
> To: Gurr, David (MED, self)
> Cc: Yurii A. Rashkovskii; caml-list@inria.fr
> Subject: RE: [Caml-list] Namespace proposal
> 
> 
> On Thu, 15 Aug 2002, Gurr, David (MED, self) wrote:
> 
> > My two cents worth: Please dont copy package ideas from 
> > languages that lack functors.  And Java's package ==
> > directory idea is far from beloved by all.  -D
> 
>  For me package is not a modules collection, but just
> a way of multi-word module naming. It's not so easy to
> give short and still adequate names to the modules, but
> something like Db.Core.Storage looks much better then
> Dbstorage, and Storage can still be accessed just as
> "Storage" from modules of the same "package". Just a naming
> way, nothing more.

And what happens when you need to abstract over a module/sub-package? -D
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal

[Vitaly Lugovsky]

On Thu, 15 Aug 2002, Yurii A. Rashkovskii wrote:

> Hi Vitaly!
> 
> >  I think that the best and the most natural solution is something
> > like Java or Python packages...
> 
> Well, as it was proposed in original mail :)

 I mean slightly different approach: no need in any syntax sugar, but
only using the directory structure. It's much better then cifering 
package contents and names inside Makefiles, and it does not need any
significiant modifications to the existing OCaml code.



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal

[Yurii A. Rashkovskii]

Hi Vitaly!

On Thu, 15 Aug 2002, Vitaly Lugovsky wrote:

>  I think that the best and the most natural solution is something
> like Java or Python packages...

Well, as it was proposed in original mail :)


--
Regards,
Yurii.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal

[Vitaly Lugovsky]

On Thu, 15 Aug 2002, Ohad Rodeh wrote:

> Also, the Caml team was convinced enough that namespaces were
> an issue to add the "-pack" option to v3.05.

 I knew it!!! I'm already using this feature to manage modules
in one not so big project (about 50 modules). Before -pack was introduced
I had a very bad headache with modules naming... But even this is not
a complete solution: some namespace info is defined completely in the
Makefiles, not in the source code. And, Makefiles becomes more and more
complex.

 I think that the best and the most natural solution is something
like Java or Python packages...



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal

[Ohad Rodeh]

I liked the "ocaml forever" bit :-).

My personal experience has been that all the <reasonable> modifications
I've requested from the Caml folk were carried out. On the other hand, I
can
easily think of some <non-reasonable> language modifications. As long
as the core developers are willing to listen to the community, I don't
think
there is a big problem.

By the way, I do think we need some kind of package/namespace approach.
My personal contribution was the "emrg" mini-tool, adapted from the
Ensemble
distribution. Also, the Caml team was convinced enough that namespaces were
an issue to add the "-pack" option to v3.05.

Just my two cents,
      Ohad.

-----------------------------------------------------------------------------------

Ohad Rodeh
tel: +972-3-6401641
IBM Haifa, storage research


                                                                                                                                            
                      Michael Vanier                                                                                                        
                      <mvanier@cs.caltech.ed        To:       yrashk@openeas.org                                                            
                      u>                            cc:       caml-list@inria.fr                                                            
                      Sent by:                      Subject:  Re: [Caml-list] Namespace proposal                                            
                      owner-caml-list@pauill                                                                                                
                      ac.inria.fr                                                                                                           
                                                                                                                                            
                                                                                                                                            
                      12/08/2002 20:31                                                                                                      
                                                                                                                                            
                                                                                                                                            




The namespace proposal brings up a related issue.  Is there any interest in
having a more formal process for making requests for enhancements to the
ocaml language analogous to (e.g.) the Python Enhancement Proposals (PEPs)
for python (http://www.python.org/peps) or similar processes for perl,
ruby, and java?  I can see advantages and disadvantages to this approach.
The advantage is that there is an organized record of proposals, commentary
on proposals, etc.  The disadvantage is that I suspect that a lot of
feature requests might be unimplementable or require a huge amount of
research to see if they're implementable (e.g. generically overloaded
operators), as opposed to PEPs, which are generally fairly trivial.  What
do people think?

Ocaml forever,

Mike
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal

[Yurii A. Rashkovskii]

Michael,

Generally I'd like to have organized proposal system for OCaml (I was Python 
fan and l remember advantages of the proposal system :-)

I think that if the proposal system will have argued voting system (so any 
OCaml users could submit their  *argued* votes for or against proposal) it 
will add serious advantage to OCaml. Most of work on judging on proposals 
will be done by volunteers and OCaml maintainers will have enough argues to 
decide whether to accept proposal or not. I think that this will help OCaml 
in spreading it among developers. More, theoretically, volunteers that are 
familiar with OCaml source code could propose ways to implement particular 
feature in order to help OCaml team.

And,  of course, it will be very interesting to hear OCaml maintainers' 
opinion.

-- 
Regards,
Yurii
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Namespace proposal

[Michael Vanier]

The namespace proposal brings up a related issue.  Is there any interest in
having a more formal process for making requests for enhancements to the
ocaml language analogous to (e.g.) the Python Enhancement Proposals (PEPs)
for python (http://www.python.org/peps) or similar processes for perl,
ruby, and java?  I can see advantages and disadvantages to this approach.
The advantage is that there is an organized record of proposals, commentary
on proposals, etc.  The disadvantage is that I suspect that a lot of
feature requests might be unimplementable or require a huge amount of
research to see if they're implementable (e.g. generically overloaded
operators), as opposed to PEPs, which are generally fairly trivial.  What
do people think?

Ocaml forever,

Mike
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Namespace proposal

[Yurii A. Rashkovskii]

Hi,

I'd like to submit a proposal for OCaml namespaces. Any questions, reports 
about my mistakes and so on are welcome :)



OCaml Namespace Proposal
========================

Version: 0.1 (DRAFT)

1. What Is a Namespace?
=======================

Namespace is an approach to assemble all components used for development
in way that will prevent name coincidence.

2. Syntax
=========

Namespace support will add new reserved keyword 'namespace' that will be
used in way indentical to 'module', except that namespaces could not be
parametrized (no polymorphism allowed). Namespace will not be module
replacement.

Example:

namespace Org = struct

   namespace Openeas = struct

      namespace Core = struct
 
        ...

      end

   end

end


The above example creates Org, Org.Openeas and Org.Openeas.Core namespaces.


4. How It Works?
================

To solve the positing problem (preventing name coincidence) namespaces
are subject to be "glued". This means that in case of coincidence of names
namespaces' signatures and structures are glued in two new single one 
signature and structure.

Example:

namespace Org = struct

   namespace Openeas = struct

      namespace Core = struct

         let f x = x

      end

   end

end


namespace Org = struct

   namespace Openeas = struct

      namespace Misc = struct

         let j x = x

      end

   end

end


The above example will define namespaces Org.Openeas.Core and Org.Openeas.Misc
with some functions inside. There we'll get the first benefit - we could 
define
namespaces absolutely independing with coincident names and this will make no
harm for the development.

The next benefit is that we could add functions and objects to existing 
namespace 
wherever.

Since OCaml is a language that pretends to be fully adopted for the "real 
world"
programming, namespaces will add the possibility to construct applications in 
a
more clean way.


5. Some Considerations
======================

In order to make namespaces' implementation easier it is proposed to "glue" 
namespace
structures and signatures only on opening modules that contain namespace(s).

So, for instance, we have module HTTP_Library that contains Org.W3.HTTP 
namespace defined and module FTP_Library that contains 
Net.Sourceforge.CamlFtp namespace defined.

(* Here is no Org.W3.HTTP namespace *)

open HTTP_Library;;

(* Here Org.W3.HTTP namespace is available *)
(* but no Net.Sourceforge.CamlFtp *)

open FTP_Library;;

(* And here Net.Sourceforge.CamlFtp is available *)

-- 
Regards,
Yurii
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners