[Caml-list] Large projects in OCaml

[Caml-list] Large projects in OCaml

[ramu ramamurthy]

We are a small group starting a project 
developing language tools. 
It appears to us that Ocaml is ideally suited
for this purpose although none of us have 
good experience with functional languages 
(but we think we can learn fast and in the longer run
choice of Ocaml will payoff -- as opposed to
using C,C++).

We would really appreciate feedback from folks who 
have worked on large projects with OCaml. If this
has been answered earlier, we appreciate pointers
to the thread(s).

Specifically:

a) Are there examples of
commercial s/w developed in OCaml?
b) Is the native compiler/runtime/tools mature for
large commercial projects?
c) Is OCaml support (for bugs etc) good?

Thanks,
Ramu



	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/

-------------------
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] Large projects in OCaml

[Jon Harrop]

I have been using ocaml to write a vector graphics library over the past four 
months. I intend to commercialise it. However, I am not yet sure exactly how 
I can do that...

From my experiences, I would say that you are likely to find programming in 
ocaml to be vastly more productive than programming in C++. In the case of my 
project, for example, I would say that development in ocaml is about 10 times 
faster than in C++ and code density is about 4 times greater. I would also 
say that your programming style (if you are used to imperative style) is 
likely to change significantly over the first month of using ocaml. It may be 
worth noting that I had already dabbled in functional programming as an 
undergrad.

I think it is important to emphasise that the efficiency of developing in 
ocaml goes a long way to offsetting the (relatively minor) drop in 
performance. This is because a given project has a finite lifetime and, in 
that lifetime, you can try a much wider variety of approaches and algorithms 
using ocaml than you could in C++.

If you want to see examples of good ocaml code to learn from then I'd 
recommend looking at the core library (in the ocaml distribution) and a 
select few third party libraries. However, you are unlikely to appreciate the 
way in which the code is written without some more intricate knowledge of the 
language itself.

> a) Are there examples of
> commercial s/w developed in OCaml?

I am not aware of any existing commercial software written in ocaml.

> b) Is the native compiler/runtime/tools mature for
> large commercial projects?

Primarily due to the clean design of the language itself (I believe) the tools 
are already of extremely high quality. I have found several bugs in gcc but 
none in the ocaml compilers, for example. Having said that, I pushed gcc to 
its limits (e.g. gratuitous template partial specialisation) but I have never 
used the more risque features in ocaml.

However, if you are planning on using external libraries in other languages 
then, I think, it is highly likely that you will need to develop your own 
interfaces to them (which you could then productively distribute for free!). 
This is mildly tricky as (I would say) there is relatively little 
documentation and it involves the use of several magic C macros. You could 
also try some of the automated tools (SOAP, camlidl).

> We would really appreciate feedback from folks who
> have worked on large projects with OCaml. If this
> has been answered earlier, we appreciate pointers
> to the thread(s).

There are some other, important aspects which you haven't covered:

The type-safe linking offered by ocaml makes for a very brittle interface 
between objects (see Xavier Leroy's post to this list on 17 May 2004 entitled 
"Ocaml shared libraries"). Therefore, I don't believe it is feasible to 
distribute commercial code in object form. If you intend to sell your code to 
programmers and you don't want them to have your source (like me!) then 
you're a bit stuck. I suspect that selling executables for the end-user would 
be comparatively trouble-free.

There are some issues with libraries too. The compiler comes with a "core" 
library which the compiler itself uses. Although these are extremely well 
written, they can be a little quirky and their functionality is quite limited 
(e.g. data structures). Although there are other libraries, such as Extlib 
and "the library formerly known as Extlib":

http://sourceforge.net/projects/ocaml-lib
http://raevnos.pennmush.org/code/annexlib/index.html

for example, there is no "Standard library". Part of this problem stems from 
the fact that, the INRIA team is intended for research and not for the 
development of such (mundane) code and although they may recieve great code 
snippets for contribution to the "core" library, they cannot accept them due 
to copyright issues:

http://caml.inria.fr/archives/200403/msg00171.html

Additionally, people who know about external libraries often aren't very good 
at designing/writing ocaml code and vice-versa.

Finally, I am not sure how well ocaml runs under Windows.

HTH.

Cheers,
Jon.

-------------------
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] Large projects in OCaml

[Richard Jones]

On Wed, May 19, 2004 at 10:24:42AM -0700, ramu ramamurthy wrote:
> a) Are there examples of
> commercial s/w developed in OCaml?

I'll leave that to others to answer fully.  Last summer we developed
some large commercial software in OCaml, but it was a private
contract.

> b) Is the native compiler/runtime/tools mature for
> large commercial projects?

Yes, very much so.

> c) Is OCaml support (for bugs etc) good?

There are very few bugs in the core compiler, so I can't comment on
support!  We encountered a few bugs in the Gtk bindings, which were
fixed rapidly, either by ourselves or with help from people on the
lablgtk list.

The main bugs we found were with the lamentable Microsoft development
tools that we had to use, eg. we found a massive (and quite scary) bug
in the MS assembler/linker.  I would avoid Windows as much as possible
if I were you.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MONOLITH is an advanced framework for writing web applications in C, easier
than using Perl & Java, much faster and smaller, reusable widget-based arch,
database-backed, discussion, chat, calendaring:
http://www.annexia.org/freeware/monolith/

-------------------
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] Large projects in OCaml

[David J. Trombley]

Check http://caml.inria.fr/users_programs-eng.html for
"significant" projects reported to the OCaml website.

-dj

----- Original Message ----- 
From: "Jon Harrop" <jdh30@cam.ac.uk>
To: <caml-list@inria.fr>
Sent: Wednesday, May 19, 2004 5:33 PM
Subject: Re: [Caml-list] Large projects in OCaml




> a) Are there examples of
> commercial s/w developed in OCaml?

I am not aware of any existing commercial software written
in ocaml.

-------------------
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] Large projects in OCaml

[David Monniaux]

On Wed, 2004-05-19 at 19:24, ramu ramamurthy wrote:
> We would really appreciate feedback from folks who 
> have worked on large projects with OCaml.

It depends on what you call "large project". OCaml code tends to be
quite terse compared to C (the difference may be significantly smaller
compared to highly templated C++ using the STL). For instance, typically
a C programmer would write a loop over linked lists manually, while a
Caml programmer would simply use a List.map combinator.

Our group currently develop and maintains a 40000-line Caml program,
half-commercial (i.e. the industry funds the development but it's not
really a full-fledged commercial product): http://www.astree.ens.fr

> b) Is the native compiler/runtime/tools mature for
> large commercial projects?

My experience is that the native compiler and runtime system are
remarkably reliable. I don't think we ever had a serious compiler bug,
and for the runtime system we only had some obscure garbage collection
issue when serializing large data structures.

The quality of generated code seems quite good, it seems, and I have the
impression that it is excellent on the AMD64 architecture. Of course,
you'd often lose by a constant factor compared to optimized C code, but
you have to factor in the development hassles of C, and also the fact
that the difficulties of using advanced data structures in C often
results in C programmers using poor, but simpler ones. Where a Caml
programmer or a good C programmer would use balanced trees with log(n)
access, an average C programmer would use a linked list with n access.

> c) Is OCaml support (for bugs etc) good?

OCaml is free software developed by a half-academic institution with
limited resources. As such, you cannot expect the same kind of support
as you would expect of software packages costing several thousand
dollars. Nevertheless, my perception is that support is quite good.
There is a bug reporting system, and if you file in a precise
description of the bug, INRIA responds in a timely manner and fixes the
problems.

The exception is support for rare systems and configurations:
understandably, given its limited resources, INRIA cannot support all
architectures/C compilers/target submodels. This is not an issue if
you're working with a major kind of system (x86 / AMD64 / PowerPC under
Linux / Windows / MacOS X); my only problem in that respect was with
64-bit support on the UltraSparc (a dying architecture).

Regards,
D. Monniaux

-------------------
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] Large projects in OCaml

[Dustin Sallings]

On May 19, 2004, at 23:35, David Monniaux wrote:

> The exception is support for rare systems and configurations:
> understandably, given its limited resources, INRIA cannot support all
> architectures/C compilers/target submodels. This is not an issue if
> you're working with a major kind of system (x86 / AMD64 / PowerPC under
> Linux / Windows / MacOS X); my only problem in that respect was with
> 64-bit support on the UltraSparc (a dying architecture).

	That said, I use OCaml on both Solaris 8/sun4u and SunOS 4.1.4/sun4c 
(as well as OS X and Linux).  I've had trouble building on NetBSD, 
though.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

-------------------
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] Large projects in OCaml

[skaller]

On Thu, 2004-05-20 at 07:38, Richard Jones wrote:

> > c) Is OCaml support (for bugs etc) good?
> 
> There are very few bugs in the core compiler, so I can't comment on
> support! 

I have found several bugs in the core compiler.
One took several versions to fix, because it took me
several versions to convince people there was really
a bug. The others were fixed in a few *hours* of me
supplying enough information to start the process
of isolating the problem.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] A problem with nan.

[sejourne kevin]

Hi!

I have a problem with float. I don't understand this:
let tab = [| ~-.9.403;  ~-.5.736;   4.095;  ~-.6.029; 
~-.4.400;  ~-.0.668;  ~-.5.295;   0.912;  ~-.2.959; 
~-.4.752;  ~-.3.017;  ~-.4.847;  60.606 |]
;;

let non = (Array.make (Array.length tab ) nan)
;;

# tab=non;;(*A*)
- : bool = true
# tab<>non;;(*B*)
- : bool = false

Can someone explain it?

Kevin.


Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout !
 Créez votre adresse sur http://mail.yahoo.fr

-------------------
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] Large projects in OCaml

[Jon Harrop]

On Thursday 20 May 2004 09:46, skaller wrote:
> ...
> I have found several bugs in the core compiler.
> One took several versions to fix, because it took me
> several versions to convince people there was really
> a bug. The others were fixed in a few *hours* of me
> supplying enough information to start the process
> of isolating the problem.

Just out of curiosity, what were these bugs?

Cheers,
Jon.

-------------------
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] Large projects in OCaml

[skaller]

On Thu, 2004-05-20 at 23:10, Jon Harrop wrote:
> On Thursday 20 May 2004 09:46, skaller wrote:
> > ...
> > I have found several bugs in the core compiler.

> Just out of curiosity, what were these bugs?

Typing of polymorphic variants. The big one
caused a core dump, rending 3.05 and 3.06 unusable.

I also pointed at a detail of pattern matching
polymorphic variants leading in part to recent
changes where the more relaxed rules can occasionally
lead to some indeterminism (there's an article
by Jacques Garrique on this somewhere). I wouldn't
call that a bug, but the new pattern matches are
less fragile: basically, the old ones refused
to allow redundant or useless cases (involving guards)
because it confused the typing. The problem was if you
commented out a tag somewhere else it gratuitously
broke the match typing, and you'd have to comment
out the case in the match too (even when all you'd
done is restrict the input expression tag set).
Now, there's a risk that guarded patterns aren't
tested sequentially, so you might end up in an
unexpected match handler if you weren't aware
of this (you can always nest matches to restore
the determinism). At least I think that's it :)

Polymorphic variants involve some interesting
language design compromises!

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Large projects in OCaml

[Eric Stokes]

A small clarification (see embedded).

On May 19, 2004, at 2:33 PM, Jon Harrop wrote:

>
> I have been using ocaml to write a vector graphics library over the 
> past four
> months. I intend to commercialise it. However, I am not yet sure 
> exactly how
> I can do that...
>
> From my experiences, I would say that you are likely to find 
> programming in
> ocaml to be vastly more productive than programming in C++. In the 
> case of my
> project, for example, I would say that development in ocaml is about 
> 10 times
> faster than in C++ and code density is about 4 times greater. I would 
> also
> say that your programming style (if you are used to imperative style) 
> is
> likely to change significantly over the first month of using ocaml. It 
> may be
> worth noting that I had already dabbled in functional programming as an
> undergrad.
>
> I think it is important to emphasise that the efficiency of developing 
> in
> ocaml goes a long way to offsetting the (relatively minor) drop in
> performance. This is because a given project has a finite lifetime 
> and, in
> that lifetime, you can try a much wider variety of approaches and 
> algorithms
> using ocaml than you could in C++.
>
> If you want to see examples of good ocaml code to learn from then I'd
> recommend looking at the core library (in the ocaml distribution) and a
> select few third party libraries. However, you are unlikely to 
> appreciate the
> way in which the code is written without some more intricate knowledge 
> of the
> language itself.
>
>> a) Are there examples of
>> commercial s/w developed in OCaml?
>
> I am not aware of any existing commercial software written in ocaml.
>
>> b) Is the native compiler/runtime/tools mature for
>> large commercial projects?
>
> Primarily due to the clean design of the language itself (I believe) 
> the tools
> are already of extremely high quality. I have found several bugs in 
> gcc but
> none in the ocaml compilers, for example. Having said that, I pushed 
> gcc to
> its limits (e.g. gratuitous template partial specialisation) but I 
> have never
> used the more risque features in ocaml.
>
> However, if you are planning on using external libraries in other 
> languages
> then, I think, it is highly likely that you will need to develop your 
> own
> interfaces to them (which you could then productively distribute for 
> free!).
> This is mildly tricky as (I would say) there is relatively little
> documentation and it involves the use of several magic C macros. You 
> could
> also try some of the automated tools (SOAP, camlidl).
>
>> We would really appreciate feedback from folks who
>> have worked on large projects with OCaml. If this
>> has been answered earlier, we appreciate pointers
>> to the thread(s).
>
> There are some other, important aspects which you haven't covered:
>
> The type-safe linking offered by ocaml makes for a very brittle 
> interface
> between objects (see Xavier Leroy's post to this list on 17 May 2004 
> entitled
> "Ocaml shared libraries"). Therefore, I don't believe it is feasible to
> distribute commercial code in object form. If you intend to sell your 
> code to
> programmers and you don't want them to have your source (like me!) then
> you're a bit stuck. I suspect that selling executables for the 
> end-user would
> be comparatively trouble-free.
>

There is no issue at all distributing object code. You do not have to 
distribute source.
The issue is, that the language does not support creating shared 
libraries written in Ocaml
(though it can link to C shared libs), so all the object code you 
distribute will be statically
linked. If you are planning to sell a library written in Ocaml, it will 
necessarily be a static
library. For application code, static linking is probably preferred in 
some cases, and
acceptable in most.

> There are some issues with libraries too. The compiler comes with a 
> "core"
> library which the compiler itself uses. Although these are extremely 
> well
> written, they can be a little quirky and their functionality is quite 
> limited
> (e.g. data structures). Although there are other libraries, such as 
> Extlib
> and "the library formerly known as Extlib":
>
> http://sourceforge.net/projects/ocaml-lib
> http://raevnos.pennmush.org/code/annexlib/index.html
>
> for example, there is no "Standard library". Part of this problem 
> stems from
> the fact that, the INRIA team is intended for research and not for the
> development of such (mundane) code and although they may recieve great 
> code
> snippets for contribution to the "core" library, they cannot accept 
> them due
> to copyright issues:
>
> http://caml.inria.fr/archives/200403/msg00171.html
>
> Additionally, people who know about external libraries often aren't 
> very good
> at designing/writing ocaml code and vice-versa.
>
> Finally, I am not sure how well ocaml runs under Windows.
>
> HTH.
>
> Cheers,
> Jon.
>
> -------------------
> 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] Large projects in OCaml

[Jon Harrop]

On Thursday 20 May 2004 17:31, Eric Stokes wrote:
> ...
> There is no issue at all distributing object code. You do not have to
> distribute source.
> The issue is, that the language does not support creating shared
> libraries written in Ocaml
> (though it can link to C shared libs), so all the object code you
> distribute will be statically
> linked. If you are planning to sell a library written in Ocaml, it will
> necessarily be a static
> library. For application code, static linking is probably preferred in
> some cases, and
> acceptable in most.

But if any other objects which my objects depend upon get changed then my 
object code will stop working.

Cheers,
Jon.

-------------------
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] Large projects in OCaml

[Eric Stokes]

On May 20, 2004, at 10:37 AM, Jon Harrop wrote:

> On Thursday 20 May 2004 17:31, Eric Stokes wrote:
>> ...
>> There is no issue at all distributing object code. You do not have to
>> distribute source.
>> The issue is, that the language does not support creating shared
>> libraries written in Ocaml
>> (though it can link to C shared libs), so all the object code you
>> distribute will be statically
>> linked. If you are planning to sell a library written in Ocaml, it 
>> will
>> necessarily be a static
>> library. For application code, static linking is probably preferred in
>> some cases, and
>> acceptable in most.
>
> But if any other objects which my objects depend upon get changed then 
> my
> object code will stop working.
>

No, that is the case with dynamic linking, not static linking. The only 
issue with
static linking and commercial stuff is that your patches are likely to 
be much bigger.
However the good thing about it is that your code is fairly immune to 
dynamic library
changes on the client machine.

> Cheers,
> Jon.
>
> -------------------
> 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] A problem with nan.

[Jon Harrop]

On Thursday 20 May 2004 12:56, sejourne kevin wrote:
> ...
> Can someone explain it?

Are you asking, equivalently, why this happens:

# 2.=nan;;
- : bool = false
# [2.]=[nan];;
- : bool = true

when "=" compares structures recursively so you'd expect it to give the same 
answer in both cases?

Cheers,
Jon.

-------------------
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] Large projects in OCaml

[Jon Harrop]

On Thursday 20 May 2004 21:30, Eric Stokes wrote:
> ...
> No, that is the case with dynamic linking, not static linking. The only
> issue with
> static linking and commercial stuff is that your patches are likely to
> be much bigger.
> However the good thing about it is that your code is fairly immune to
> dynamic library
> changes on the client machine.

Would my users not keep getting unavoidable "The files blah.cmi and mylib.cmi 
make inconsistent assumptions over interface Blah"?

Cheers,
Jon.

-------------------
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] Large projects in OCaml

[Eric Stokes]

On May 20, 2004, at 2:04 PM, Jon Harrop wrote:

> On Thursday 20 May 2004 21:30, Eric Stokes wrote:
>> ...
>> No, that is the case with dynamic linking, not static linking. The 
>> only
>> issue with
>> static linking and commercial stuff is that your patches are likely to
>> be much bigger.
>> However the good thing about it is that your code is fairly immune to
>> dynamic library
>> changes on the client machine.
>
> Would my users not keep getting unavoidable "The files blah.cmi and 
> mylib.cmi
> make inconsistent assumptions over interface Blah"?
>

If it is a library that you maintain you would need to send a new .cmi 
file with each
new version of the library. But an application linked to your library 
would not be effected
by this change in any way unless the application writer recompiled the 
application against
the new version of the library. There is no link phase (except linking 
to external c libraries)
at the start of an Ocaml program. The application binary contains a 
copy of all the Ocaml code
ever used by the program, including library code.

> Cheers,
> Jon.
>
> -------------------
> 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] A problem with nan.

[David J. Trombley]

I also noticed
ref 1.0 = ref nan
evaluates true.

-dj

----- Original Message ----- 
From: "Jon Harrop" <jdh30@cam.ac.uk>
To: <caml-list@inria.fr>
Sent: Thursday, May 20, 2004 4:42 PM
Subject: Re: [Caml-list] A problem with nan.


> On Thursday 20 May 2004 12:56, sejourne kevin wrote:
> > ...
> > Can someone explain it?
>
> Are you asking, equivalently, why this happens:
>
> # 2.=nan;;
> - : bool = false
> # [2.]=[nan];;
> - : bool = true
>
> when "=" compares structures recursively so you'd expect
it to give the same
> answer in both cases?
>
> Cheers,
> Jon.
>
> -------------------
> 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] A problem with nan.

[Damien Doligez]

On May 20, 2004, at 22:42, Jon Harrop wrote:

> # 2.=nan;;
> - : bool = false
> # [2.]=[nan];;
> - : bool = true
>
> when "=" compares structures recursively so you'd expect it to give 
> the same answer in both cases?

We have contradictory requirements here:
1. We want "=" on floats to be IEEE754 equality.
2. We want "=" on structures to be compatible with "=" on their 
elements.
3. We want "=" on structures to be based on "compare".
4. We want "compare" to be a total ordering.

Since IEEE754 equality is not a reflexive relation, there is no way
to get all four properties.

In the current version of O'Caml, we have 1, 3, and 4.  In the next
version we will have 1, 2, and 4: "compare" and "=" will have slightly
different behaviour, but "=" will be compatible with itself.  This
will make "compare" a valid comparison function for List.sort, for
all types of data (currently it doesn't work for floats).

But "compare nan nan" will return 0, while "nan = nan" will
return false (as mandated by IEEE754).

-- Damien

-------------------
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] Large projects in OCaml

[Jon Harrop]

On Thursday 20 May 2004 22:41, you wrote:
> ...There is no link phase (except linking
> to external c libraries) at the start of an Ocaml program.

Sure, so if someone buys my lib (in the form of .cmo and .mli files), writes 
their own code and compiles it into an executable then it should work 
forever.

But I want them to be able to constantly write new code and recompile it 
(statically linking their .cmo files with mine), forever. If their code and 
my lib depend upon the same object file and it changes, then this will break 
and the only fix will be for them to get a new lib from me for the new 
version of their object file. If I am right, then I am afraid that this will 
put people off...

Cheers,
Jon.

-------------------
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] Large projects in OCaml

[Ville-Pertti Keinonen]

On May 21, 2004, at 2:28 PM, Jon Harrop wrote:

> But I want them to be able to constantly write new code and recompile 
> it
> (statically linking their .cmo files with mine), forever. If their 
> code and
> my lib depend upon the same object file and it changes, then this will 
> break

Your library version obviously needs to depend on a specific version of 
OCaml as well as specific versions of libraries used by your 
library...but for a commercial library, this should be the case, 
anyhow.  You shouldn't be supporting any versions of OCaml and 
libraries you depend on except the ones you have built and tested 
against.

This isn't specific to OCaml, either.  C is rare in that it has had 
stable and standardized enough ABIs that you can usually get away with 
using different versions of compilers and system libraries.  With other 
libraries, YMMV, but things that break due to version incompatibilities 
aren't rare.

But even with C++, things often aren't that easy.  The commercial 
binary C++ libraries I've used, whether shared or not, are supported 
for only a particular compiler version and particular versions of third 
party libraries.  Usually any third party libraries that are required 
are distributed along with the purchased binary library.

> and the only fix will be for them to get a new lib from me for the new
> version of their object file. If I am right, then I am afraid that 
> this will
> put people off...

But why would your library depend on *their* changing object file, 
unless its a third party library, in which case they should be using 
the same version you built against?

In any case, you really should consider distributing your library in 
source form to licensees.  Given a choice, I'd never purchase a 
binary-only library for any purpose (sadly, I often don't have a 
choice).

Almost all of the problems I've run into with purchased binary 
libraries could've been avoided if I had the source, and I've spent 
unreasonable amounts of time tracking down totally stupid problems 
(mostly due to undocumented assumptions).  I can't think of any binary 
(non-system) libraries that I haven't run into unnecessary problems 
with during the last decade...prior to that, I wasn't used to having 
source code, so I didn't associate problems with binary distributions.

-------------------
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] Large projects in OCaml

[Jon Harrop]

On Friday 21 May 2004 13:49, Ville-Pertti Keinonen wrote:
> Your library version obviously needs to depend on a specific version of
> OCaml as well as specific versions of libraries used by your
> library...but for a commercial library, this should be the case,
> anyhow.  You shouldn't be supporting any versions of OCaml and
> libraries you depend on except the ones you have built and tested
> against.

Do you think I should build, test and distribute for a variety of compiler and 
third party library versions then? That would be a set of object files for 
each permutation?

> This isn't specific to OCaml, either.  C is rare in that it has had
> stable and standardized enough ABIs that you can usually get away with
> using different versions of compilers and system libraries.  With other
> libraries, YMMV, but things that break due to version incompatibilities
> aren't rare.

Ok, I just want to make sure that I'm providing the best possible service. :-)

> But why would your library depend on *their* changing object file,
> unless its a third party library, in which case they should be using
> the same version you built against?

I meant third party, sorry. I'm using my own version of lablgl as well as 
camlimages. I'll probably open-source an alternative to lablgl (based upon 
Isaac Trott's idlgl) but I'd like to use the standard camlimages.

> In any case, you really should consider distributing your library in
> source form to licensees.  Given a choice, I'd never purchase a
> binary-only library for any purpose (sadly, I often don't have a
> choice).

I don't mind distributing the bulk of my code in source form (particularly the 
demos and paraphenalia) but I would like to keep the core closed source, 
unless someone is willing to pay an obscene amount of money for it. :-)

> Almost all of the problems I've run into with purchased binary
> libraries could've been avoided if I had the source, and I've spent
> unreasonable amounts of time tracking down totally stupid problems
> (mostly due to undocumented assumptions).  I can't think of any binary
> (non-system) libraries that I haven't run into unnecessary problems
> with during the last decade...prior to that, I wasn't used to having
> source code, so I didn't associate problems with binary distributions.

Ok, I'll keep considering distributing a source version. Maybe a cut-down 
version...

Cheers,
Jon.

-------------------
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] Large projects in OCaml

[Jacques GARRIGUE]

From: Jon Harrop <jdh30@cam.ac.uk>

> On Thursday 20 May 2004 22:41, you wrote:
> > ...There is no link phase (except linking
> > to external c libraries) at the start of an Ocaml program.
> 
> Sure, so if someone buys my lib (in the form of .cmo and .mli files), writes 
> their own code and compiles it into an executable then it should work 
> forever.
> 
> But I want them to be able to constantly write new code and recompile it 
> (statically linking their .cmo files with mine), forever. If their code and 
> my lib depend upon the same object file and it changes, then this will break 
> and the only fix will be for them to get a new lib from me for the new 
> version of their object file. If I am right, then I am afraid that this will 
> put people off...

There has been some discussion about how bad it is, but my view is
that this .cmi/.cmx compatibility problem is so bad that it makes
binary only distribution of libraries a nightmare for both the
provider and the user. Basically, any bug fix in the compiler (not
even a new feature) may break the compatibility.
If you are going to make binary only distribution, then you should
guarantee to your user that you are ready to provide them new versions
when needed. A terrible pain for both of you.
(At some time Ensemble was binary-only for licensing reasons. It was a
huge discomfort.)

Honestly, what is so bad about providing the source under a NDA?
This has been the standard way to proceed on Unix for a long time,
just because people may need to patch and fix the system, and you
don't wan't to have to go to your provider every time something
changes.
I suggest you rather think in that direction, since it would save you
lots of trouble.

Jacques Garrigue

-------------------
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] Large projects in OCaml

[skaller]

On Mon, 2004-05-24 at 13:07, Jacques GARRIGUE wrote:

> Honestly, what is so bad about providing the source under a NDA?

The main problem is that it means the client needs 
a full scale development environment.

On Windows .. this is out of the question.
On my Linux box it is too for many applications --
I simply don't have disk space left for sources.
One of my clients is running Linux .. on an XBox.
Other people are using hand-helds devices and
other small systems ..

You really want me to upgrade my telephone
by building from source??

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Large projects in OCaml

[Jacques GARRIGUE]

From: skaller <skaller@users.sourceforge.net>
> > Honestly, what is so bad about providing the source under a NDA?
> 
> The main problem is that it means the client needs 
> a full scale development environment.
> 
> On Windows .. this is out of the question.
> On my Linux box it is too for many applications --
> I simply don't have disk space left for sources.
> One of my clients is running Linux .. on an XBox.
> Other people are using hand-helds devices and
> other small systems ..

This was about selling libraries to developpers.
If you're buying an ocaml library, then I hope you've got an ocaml
development environment, otherwise I do not see what you could do with
it.

I think that everybody agrees that a great strength of ocaml is its
ability to easily build standalone executables. This is what matters
to end users. But to build the executable you are going to distribute,
you need the sources.

Jacques Garrigue

-------------------
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] Large projects in OCaml

[skaller]

On Mon, 2004-05-24 at 22:14, Jacques GARRIGUE wrote:
> From: skaller <skaller@users.sourceforge.net>
> > > Honestly, what is so bad about providing the source under a NDA?
> > 
> > The main problem is that it means the client needs 
> > a full scale development environment.

> This was about selling libraries to developpers.
> If you're buying an ocaml library, then I hope you've got an ocaml
> development environment, otherwise I do not see what you could do with
> it.

Sure, but most developers have end users ..

> I think that everybody agrees that a great strength of ocaml is its
> ability to easily build standalone executables. 

It can do that, yes ..

> This is what matters to end users.

What matters to end-users is shared libraries
which Ocaml can't build at all. The real world out
there demands *components* they can plug together.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Large projects in OCaml

[Xavier Leroy]

> What matters to end-users is shared libraries
> which Ocaml can't build at all. The real world out
> there demands *components* they can plug together.

The next time I read a sentence starting with "the real world", I
think I'm going to scream.  

At any rate, your jump from shared libraries to components is a
non-sequitur.  Shared libraries are a spectacularly poor component
model (no multiple interfaces, almost no dynamic discovery of
interfaces, no distribution transparency of any kind, etc).

It is true that some component models use shared libraries as one of
their low-level implementation mechanisms, e.g. COM components are
often presented as Windows DLLs.  But these are shared libraries of a
very constrained form, and (for instance) OCaml has no problems
generating a DLL that encapsulates OCaml code as a COM component.

A good component model for OCaml (and other languages): that would be
interesting.  Shared libraries for the sake of shared libraries: that
isn't interesting in the least.

- Xavier Leroy

-------------------
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] Large projects in OCaml

[Daniel Bünzli]

Le 24 mai 04, à 15:54, skaller a écrit :

> What matters to end-users is shared libraries
> which Ocaml can't build at all. The real world out
> there demands *components* they can plug together.

Highly dependent on your actual definition of "end-users". There are 
many of them with different needs.

Daniel
-------------------
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] Large projects in OCaml

[Alex Baretta]

Xavier Leroy wrote:

> A good component model for OCaml (and other languages): that would be
> interesting.  Shared libraries for the sake of shared libraries: that
> isn't interesting in the least.
> 
> - Xavier Leroy


This is a very interesting remark. Indeed, static type safety seems 
rather incompatbile with a component model, yet, I'm sure someone is 
doing research on the subject. Can anyone point me to the relevant material?

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] Large projects in OCaml

[james woodyatt]

On 24 May 2004, at 06:54, skaller wrote:
> The real world out there demands *components* they can plug together.

The real world uses application protocols to do this.


-- 
j h woodyatt <jhw@wetware.com>
don't take any wooden root certs...

-------------------
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] Large projects in OCaml

[brogoff]

On Mon, 24 May 2004, Alex Baretta wrote:
> Xavier Leroy wrote:
> > A good component model for OCaml (and other languages): that would be
> > interesting.  Shared libraries for the sake of shared libraries: that
> > isn't interesting in the least.
> >
> > - Xavier Leroy
>
>
> This is a very interesting remark. Indeed, static type safety seems
> rather incompatbile with a component model, yet, I'm sure someone is
> doing research on the subject. Can anyone point me to the relevant material?

I think you're right that it seems difficult to reconcile static type safety and
a component model (and many other things!) but what may make sense is to
intergrate some bit of dynamic typing into Caml. That is one of the many reasons
that some of us are hoping that GCaml or something like it finds its way into
OCaml.

Both Clean and Mercury have some dynamic typing, and from the other side you
could view Dylan as having some explicit static typing on a dynamic language,
though I'm pretty sure that Dylan (and Lisp) people think about static types
as a means to get better performance only. You may be interested in browsing the
Clean pages for material on dynamics.

-- Brian

-------------------
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] Large projects in OCaml

[skaller]

On Tue, 2004-05-25 at 00:20, Xavier Leroy wrote:
> > What matters to end-users is shared libraries
> > which Ocaml can't build at all. The real world out
> > there demands *components* they can plug together.
> 
> The next time I read a sentence starting with "the real world", I
> think I'm going to scream.  

Sorry .. I deserve it (scream away :)

> At any rate, your jump from shared libraries to components is a
> non-sequitur.  Shared libraries are a spectacularly poor component
> model (no multiple interfaces, almost no dynamic discovery of
> interfaces, no distribution transparency of any kind, etc).

No dispute. 

> A good component model for OCaml (and other languages): that would be
> interesting.  Shared libraries for the sake of shared libraries: that
> isn't interesting in the least.

In Python, you can simply install PyOracle and go.
Do you really think there is any comparison between
that and recompiling Python????

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Large projects in OCaml

[skaller]

On Tue, 2004-05-25 at 00:20, Daniel Bünzli wrote:
> Le 24 mai 04, à 15:54, skaller a écrit :
> 
> > What matters to end-users is shared libraries
> > which Ocaml can't build at all. The real world out
> > there demands *components* they can plug together.
> 
> Highly dependent on your actual definition of "end-users". There are 
> many of them with different needs.

End user is someone who is not going to redistribute your
code or some product derived from it. Developers by definition
do redistribute code (or stuff derived from it).

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Large projects in OCaml

[Brandon J. Van Every]

skaller wrote:
> Xavier Leroy wrote:
>
> > A good component model for OCaml (and other languages):
> > that would be
> > interesting.  Shared libraries for the sake of shared
> > libraries: that
> > isn't interesting in the least.
>
> In Python, you can simply install PyOracle and go.
> Do you really think there is any comparison between
> that and recompiling Python????

I don't see any relevance to what Xavier wrote.  Do you have a
suggestion for an OCaml component model?  "Python is cool!" isn't an
operative suggestion.  It has a rather different type model and there's
a price to pay for its flexibility.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.686 / Virus Database: 447 - Release Date: 5/14/2004

-------------------
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] Large projects in OCaml

[Alan Schmitt]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

* Alex Baretta (alex@baretta.com) wrote:
> Xavier Leroy wrote:
> 
> >A good component model for OCaml (and other languages): that would be
> >interesting.  Shared libraries for the sake of shared libraries: that
> >isn't interesting in the least.
> >
> >- Xavier Leroy
> 
> 
> This is a very interesting remark. Indeed, static type safety seems 
> rather incompatbile with a component model, yet, I'm sure someone is 
> doing research on the subject. Can anyone point me to the relevant material?

Hi,

I am currently working on a process calculus that aims at modelling the 
Fractal component model (see http://fractal.objectweb.org for more info 
about this component model). We want to use this to build type systems 
and other verification tools, as well as doing an implementation in our  
favorite language (tm) (it has two implementations for the moment: one 
in Java, and one in C).

We don't have much to read yet, we are currently finishing up a tech 
report about the calculus itself. I can announce it here when we're 
done.

Alan Schmitt

-- 
The hacker: someone who figured things out and made something cool happen.
.O.
..O
OOO

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Large projects in OCaml

[Richard Jones]

On Wed, May 26, 2004 at 04:57:11PM +1000, skaller wrote:
> Sylvain Le Gall recently released a nice file utils library.
> He forgot to mention it's GPL.

Have you asked him if he would make it LGPL?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
If I have not seen as far as others, it is because I have been
standing in the footprints of giants.  -- from Usenet

-------------------
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] Large projects in OCaml

[skaller]

On Wed, 2004-05-26 at 05:07, Richard Jones wrote:
> On Tue, May 25, 2004 at 09:26:56AM +0200, Mattias Waldau wrote:
> > One big problem is that many of the good ocaml libraries are GPL, and 
> > cannot be used by ISV. For example, we had to implement our own XML-library.
> 
> Which other libraries did you have a problem with?  Most of the
> libraries I've seen are LGPL-with-linking-exception, which is fine for
> commercial development.

Sylvain Le Gall recently released a nice file utils library.
He forgot to mention it's GPL.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Large projects in OCaml

[Evan Martin]

On Tue, May 25, 2004 at 08:07:16PM +0100, Richard Jones wrote:
> On Tue, May 25, 2004 at 09:26:56AM +0200, Mattias Waldau wrote:
> > One big problem is that many of the good ocaml libraries are GPL, and 
> > cannot be used by ISV. For example, we had to implement our own XML-library.
> 
> Which other libraries did you have a problem with?  Most of the
> libraries I've seen are LGPL-with-linking-exception, which is fine for
> commercial development.

(ocaml-xmlr is BSD with the underlying libxml also BSD.)

-- 
Evan Martin
martine@danga.com
http://neugierig.org

-------------------
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] Large projects in OCaml

[Richard Jones]

On Tue, May 25, 2004 at 09:26:56AM +0200, Mattias Waldau wrote:
> One big problem is that many of the good ocaml libraries are GPL, and 
> cannot be used by ISV. For example, we had to implement our own XML-library.

Which other libraries did you have a problem with?  Most of the
libraries I've seen are LGPL-with-linking-exception, which is fine for
commercial development.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
NET::FTPSERVER is a full-featured, secure, configurable, database-backed
FTP server written in Perl: http://www.annexia.org/freeware/netftpserver/

-------------------
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] Large projects in OCaml

[Mattias Waldau]

ExcelEverywhere, which converts Excel spreadsheets into web pages where 
JavaScript does all the calculation is written in Ocaml.

The program consists of 40,000 lines of Ocaml, a 10,000 lines of 
JavaScript and Excel VBA.

We do no GUI in Ocaml, everything is done in VBA. The ocaml-part is just 
a native code compiled win32-executable.

We had very few problems with bugs with the ocaml-implementation, and 
always found simple workarounds.

Development is done on cygwin and linux, since we really like 
ocamldebug, the debugger that can execute backwards.

One big problem is that many of the good ocaml libraries are GPL, and 
cannot be used by ISV. For example, we had to implement our own XML-library.

If your datastructures are large, I would not recommend delivering 
byte-compiled code. It is noticable slower and easily runs out of memory.

If you use resonable datastructure, speed will not be a problem.

Good luck,

Mattias





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