[Caml-list] mixin modules paper and future?

[Caml-list] mixin modules paper and future?

[Chris Hecker]

While looking around Xavier's site, I came across this new paper (at least, 
new since last time I looked):

Mixin modules in a call-by-value setting, with Tom Hirschowitz.
Proceedings of ESOP 2002, LNCS 2305.
http://pauillac.inria.fr/~xleroy/publi/mixins-cbv-esop2002.pdf

The results in the paper look really exciting to my untrained eye, and I 
had a few questions...

1.  First, the annoying obvious question:  Any wild guesses when this work 
will find its way into caml?  I read the whole paper, but had to skim the 
lambda calc sections since my lambda-fu is not strong.  It's clear there 
are a number of open problems, so it's obviously not imminent in the next 
release, but it sure is cool (the way it unifies functors and recursion is 
great).

2.  The paper has a few places where it mentions work that has to be done 
at init time, which sounded like runtime at the point where the minix sum 
was computed.  Is this true?  For the very simple case of "I want to 
recurse between two compilation units like C++", is there still overhead 
that must happen at runtime and that can't be done at compile time?

3.  The following is from the paper:

>A drawback of dependency graphs is that programmers must (in principle)
>provide them explicitly when declaring a mixin signature, e.g. for a deferred
>sub-mixin component. This could make programs quite verbose.

I may have missed it, but I didn't see where this explicit graph thing came 
in, since none of the examples had it.  I assume you don't mean the type 
declaration of the deferred values, right?  Is there some other 
specification that's necessary?

Thanks,
Chris

-------------------
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] mixin modules paper and future?

[Tom Hirschowitz]

Hi Chris, 

 > While looking around Xavier's site, I came across this new paper (at least, 
 > new since last time I looked):
Last January yes.

 > 1.  First, the annoying obvious question:  Any wild guesses when this work 
 > will find its way into caml?  
 > I read the whole paper, but had to skim the 
 > lambda calc sections since my lambda-fu is not strong.  It's clear there 
 > are a number of open problems, so it's obviously not imminent in the next 
 > release, but it sure is cool (the way it unifies functors and recursion is 
 > great).

You're right, it is not at all planned for any future release. There
are too many open questions yet even to make any guess whether it will ever
find its way.  But thanks for your interest!

 > 2.  The paper has a few places where it mentions work that has to be done 
 > at init time, which sounded like runtime at the point where the mixin sum 
 > was computed.  Is this true?  

Almost, it would rather be at the time when the mixin is instanciated
(ie "closed").

 > For the very simple case of "I want to 
 > recurse between two compilation units like C++", is there still overhead 
 > that must happen at runtime and that can't be done at compile time?

In the present system yes, and it is a matter of design I believe.
For instance, even for your simple case, you have to first write unit
A, then unit B, and then create C = close(A + B), and that's in the
source language, so closing the recursion loop is really an operation
of the language.

But maybe you are asking for optimizations performing such tasks at
compile-time?  We haven't thought too much about such optimizations
yet, and that's probably a good question.  It is not a priority
though, since some design problems remain open, and the efficiency of
taking a mixin module instance is not supposed to be critical, in the
context of an extension of ML modules.

Please, tell me if I missed your point.

 > 3.  The following is from the paper:
 > 
 > >A drawback of dependency graphs is that programmers must (in principle)
 > >provide them explicitly when declaring a mixin signature, e.g. for a deferred
 > >sub-mixin component. This could make programs quite verbose.
 > 
 > I may have missed it, but I didn't see where this explicit graph thing came 
 > in, since none of the examples had it.  I assume you don't mean the type 
 > declaration of the deferred values, right?  Is there some other 
 > specification that's necessary?

Yes, we meant the type declaration of the deferred values. If a
deferred mixin is expected, its type must be provided by the
programmer. In the paper, we don't have considered type inference
issues, but it seems to be far from trivial, as described by papers
about objects and classes, which appear to have similar problems.

Bye,

Tom
-------------------
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] mixin modules paper and future?

[Chris Hecker]

>You're right, it is not at all planned for any future release. There
>are too many open questions yet even to make any guess whether it will ever
>find its way.  But thanks for your interest!

Hopefully you guys are actively working on solving the open 
problems.  :)  I think that this is an incredibly important feature for 
caml to make headway into large systems development.

>But maybe you are asking for optimizations performing such tasks at
>compile-time?

Yeah, at least for the easy cases.  My thought is that people will start 
using it to decouple large modules into different files, and it would be 
nice if that simple case (basically, mirroring using a header to split a 
big interdependent system across multiple C files) incurred no runtime 
overhead.  However, it's much more important to solve the open research 
problems than it is to optimize it, so ignore this for now.  :)

 > Yes, we meant the type declaration of the deferred values. If a
>deferred mixin is expected, its type must be provided by the
>programmer.

Ah, okay.  I guess it doesn't seem unreasonable to me to force the 
programmer to specify types for the deferred values, but maybe I haven't 
gotten used to type inference enough to be annoyed by this yet.  One thing 
is for certain:  it would be MUCH better to implement this feature 
requiring type declarations than to sit on it until you figure out how to 
do inference on deferred values.  Caml programmers are used to specifying 
types in mli files anyway, so it's just not a big deal.  Unless I'm missing 
something important.

Keep up the good work!
Chris


-------------------
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] mixin modules paper and future?

[M E Leypold @ labnet]

Chris Hecker writes:
 > 
 > >You're right, it is not at all planned for any future release. There
 > >are too many open questions yet even to make any guess whether it will ever
 > >find its way.  But thanks for your interest!
 > 
 > Hopefully you guys are actively working on solving the open 
 > problems.  :)  I think that this is an incredibly important feature for 
 > caml to make headway into large systems development.


Do you think so? I think 1 thing we can learn from Java, C, C++,
FORTRAN and COBOL is, that the only thing a language doesn't need to
"make headway into large systems development" is any smart mechanisms
for composing systems. That is to say: Success doesn't depend on
merit.

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

[Caml-list] objective caml and industry

[james woodyatt]

On Thursday, Aug 29, 2002, at 03:11 US/Pacific, M E Leypold @ labnet 
wrote:
>
> Do you think so? I think 1 thing we can learn from Java, C, C++,
> FORTRAN and COBOL is, that the only thing a language doesn't need to
> "make headway into large systems development" is any smart mechanisms
> for composing systems. That is to say: Success doesn't depend on
> merit.

I promise not to be broken record about this, but there are some things 
holding Objective Caml back from being an optimal language choice for 
large industrial applications development.  I don't think any of the 
open problems in the research of mixin modules are on the list.

Here are the main issues holding back industrial developers from 
adopting Objective Caml, I think:

+ Hysteresis.  An awful lot of dollars have gone into the engineering 
of cubicle farms full of programmers who know Java, C++ and other iron 
age relics.  These are dollars invested in training, development tools, 
documentation, the works.  Using Objective Caml in university computer 
science courses can be inductive, but it's a long-term problem going 
forward.

+ Type inference is scary.  All the languages popular in industry today 
that have syntactical support for polymorphism are either not strongly 
typed or they require types to be explicitly defined prior to their 
use.  Industrial programmers will want to see the case made that type 
inference is a language feature worth the pain associated with learning 
how to work with it.  I think a good case can be made; I just haven't 
seen it.  And I'm in industry, so if it's kicking around in academia 
somewhere, it needs a wider audience.

+ Deployment issues.  Industry likes to be able to treat every line of 
source code it writes as if it were a trade secret, even when there's 
no good reason to do so.  It's like we're all queer for secrecy, or 
something.  The languages most popular with industry today permit 
relatively easy distribution of dynamically loadable modules either in 
native machine code or in an already widely adopted virtual machine 
code.  Objective Caml doesn't meet this criteria.

+ Stupidity.  Objective Caml's popularity in academia is a curse as 
well as a blessing.  For every coder like me who wonders if he should 
rather have gone into academia, industry has a hundred coders who think 
career academics are a fat lot of pencil-necked geeks who can't get 
"real" programming jobs.  This is why industry continues to be 
populated with idiots who think the reason Java programs so often 
perform badly is the garbage collector.  These are also the same people 
who will tell you that the syntax of Objective Caml is intolerably 
bizarre, while simultaneously raving about the elegance of C#.  (I'm 
not bitter.  I'm not bitter.)

I started writing these in descending order of importance, but by the 
time I got to the last one I began to think maybe I got it exactly 
backward.  All of these views are my own alone.

Maybe the two in the middle are the ones I would recommend the Caml 
team think about in their copious spare time.


-- 
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] objective caml and industry

[Michael Vanier]

> Date: Thu, 29 Aug 2002 11:47:55 -0700
> From: james woodyatt <jhw@wetware.com>
> 
> I promise not to be broken record about this, but there are some things 
> holding Objective Caml back from being an optimal language choice for 
> large industrial applications development.  I don't think any of the 
> open problems in the research of mixin modules are on the list.
> 

[good reasons omitted]

> + Stupidity.  Objective Caml's popularity in academia is a curse as 
> well as a blessing.  For every coder like me who wonders if he should 
> rather have gone into academia, industry has a hundred coders who think 
> career academics are a fat lot of pencil-necked geeks who can't get 
> "real" programming jobs.  This is why industry continues to be 
> populated with idiots who think the reason Java programs so often 
> perform badly is the garbage collector.  These are also the same people 
> who will tell you that the syntax of Objective Caml is intolerably 
> bizarre, while simultaneously raving about the elegance of C#.  (I'm 
> not bitter.  I'm not bitter.)
> 

Now you're getting close to the real reason.  You could cast this in a less
negative light by noting that ocaml has a long learning curve, even for
programmers who know lots of other languages.  There are simply a lot of
unfamiliar features in ocaml for the vast majority of programmers.

However, I don't think you're being negative enough ;-)  In my experience,
most programmers react to anything resembling functional programming as if
it were made out of kryptonite.  The reason for this is that it forces them
to think in a different way than they're used to, and the resistance this
generates, even among otherwise very proficient coders, is nothing short of
astounding.  Consider that object-oriented programming has been around
since around 1967 (simula) and yet it took more than twenty years to become
mainstream.  And OO is a *much* less radical departure from ordinary
imperative programming than functional programming is.  FP has been around
since 1960 (lisp) and is *still* considered to be radical!  You can't
overestimate how conservative the community of programmers is.  We teach
scheme as an introductory programming language at Caltech, and we get a
*lot* of resistance even from supposedly open-minded freshmen (most of whom
know C and thus think they know the "right" way to program).  Also, the
average programmer, if he's even heard of functional programming (>99% of
them haven't) is convinced that it's incredibly inefficient and therefore
not worth learning.

Change takes time.  I think chasing after industry acceptance of ocaml is
the wrong strategy.  The right strategy is a grass-roots effort (building
up the language libraries, trying to attract the best hackers and using
ocaml in university courses).  This approach has worked well for python,
and I think it will work well for ocaml as well.

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

Re: [Caml-list] objective caml and industry

[james woodyatt]

On Thursday, Aug 29, 2002, at 15:57 US/Pacific, Michael Vanier wrote:
>
> [...] We teach scheme as an introductory programming language at 
> Caltech, and we get a *lot* of resistance even from supposedly 
> open-minded freshmen [...]

Tell them that computer *scientists* need to learn functional 
programming, and that if they really want to take courses in the 
software equivalent of automotive repair, then perhaps they should have 
considered studying at DeVry.

How's *that* for negative?


-- 
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] mixin modules paper and future?

[Chris Hecker]

> > I think that this is an incredibly important feature for
> > caml to make headway into large systems development.
>Do you think so?

You misunderstood what I thought was important, or I was unclear, or 
both.  ;)  I think shipping the mixin system (or any system that allows 
module recursion) is important, not the open problems themselves.  All of 
the examples you mentioned (well, I don't know about Cobol, but all the 
others) allow you to have recursive systems spread across multiple files to 
reduce compile times, limit file length, and break things out conceptually.

The concept of a "forward declaration" is critical to writing large scale 
software effectively, I think.

Chris


-------------------
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] objective caml and industry

[Chris Hecker]

>+ Hysteresis.
>+ Type inference is scary.
>+ Deployment issues.
>+ Stupidity.

None of these are things the dev team needs to be working on...not that 
they're not important, but the community, if it got its act together, could 
solve all of these problems, or rather they could make as much headway on 
them as the dev team.  By contrast, the community cannot add massively 
subtle and complicated features to the compiler; only the dev team can do that.

Chris


-------------------
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] objective caml and industry

[Vitaly Lugovsky]

On Thu, 29 Aug 2002, Michael Vanier wrote:

> Change takes time.  I think chasing after industry acceptance of ocaml is
> the wrong strategy.

 It already accepted functional programming. Look at what Microsoft 
Research have done - isn't them represent the industry?

> This approach has worked well for python,
> and I think it will work well for ocaml as well.

 Python is treated by industry as a "new, better Smalltalk".
There is no such a way for functional programming - Lisp always was
a marginal approach.



-------------------
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] objective caml and industry

[Jonathan Coupe]

www.jetcafe.org/~npc/doc/euc00-sendmail.html

Interested parties might want to look at this article, written by a
(non-Ericson) team that decided to use Erlang for an industrial project.
Reading a software marketing book like "Inside The Tornado" might be
interesting too.

- Jonathan Coupe


-------------------
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] objective caml and industry

[Jonathan Coupe]

www.jetcafe.org/~npc/doc/euc00-sendmail.html

Interested parties might want to look at this article, written by a
(non-Ericson) team that decided to use Erlang for an industrial project.
Reading a software marketing book like "Inside The Tornado" might be
interesting too.

- Jonathan Coupe


-------------------
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] objective caml and industry

[Michael Vanier]

> Date: Fri, 30 Aug 2002 17:13:43 +0400 (MSD)
> From: Vitaly Lugovsky <vsl@ontil.ihep.su>
> 
> On Thu, 29 Aug 2002, Michael Vanier wrote:
> 
> > Change takes time.  I think chasing after industry acceptance of ocaml is
> > the wrong strategy.
> 
>  It already accepted functional programming. Look at what Microsoft 
> Research have done - isn't them represent the industry?

Microsoft has a research interest in functional programming.  Though that's
perhaps encouraging, it's a far cry from trying to promote FP as something
programmers should learn.  C# (which they do promote as something
programmers should learn) is a long, long way from FP.  Still, every little
bit helps.

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

Re: [Caml-list] objective caml and industry

[John Max Skaller]

james woodyatt wrote:

> I promise not to be broken record about this, but there are some things 
> holding Objective Caml back from being an optimal language choice for 
> large industrial applications development. 



> + Hysteresis. 


Heh. Also known as 'inertia'. In my opinion, this is
THE MAJOR problem. It isn't a technical problem.
The coming English translation of the new O'Reilly Ocaml
book is the most significant step forward here since
Bagley's Shootout showed Ocaml is the top performing
language after C.

> + Type inference is scary.


Yes it is. Felix deliberately refuses to do it.
But it does do type deduction (bottom up).

> Industrial programmers will want to see the case made that type 
> inference is a language feature worth the pain associated with learning 
> how to work with it.  I think a good case can be made; I just haven't 
> seen it. 


Yes you have, you just haven't recognized that INDUSTRY
itself has already made the case!

Most scripting languages, such as Python, support
polymorphism, and do not have type declarations.
QED. Case proven. People hate writing useless
type declarations.

Ocaml is even better, because it ALSO supports static
type checking.

No, it is NOT inference that is scary. It is the horrid
error messages.

That is a deep technical problem, which the Ocaml
team is successfully addressing. The most obviously
unhelpful messages have been improved
just going from 3.04 to 3.05/6. Much more work
is needed here, for example, to locate the places
where the engine gets its data, so that it can say

"here, x is infered to be type T, but here, it is
used as type T'"

whereas at present, the first location isn't known
to the engine, and so it often reports an
error in the "wrong" location.

But don't be too depressed: if you've seen a few

C++ template error messages, we'll, they aren't
so easy to figure out either :-)

> + Deployment issues.  Industry likes to be able to treat every line of 
> source code it writes as if it were a trade secret, even when there's no 
> good reason to do so.  It's like we're all queer for secrecy, or 
> something.  The languages most popular with industry today permit 
> relatively easy distribution of dynamically loadable modules either in 
> native machine code or in an already widely adopted virtual machine 
> code.  Objective Caml doesn't meet this criteria.


There are many other reasons for shared libraries.
Even now, I really NEED them in my Felix compiler.
My prior Ocaml project, Vyper, required them too.

In both cases these are technical demands, not a matter

of commercial requirements.

The context is different (Vyper had to emulate
Python's dynamic loading, Felix needs to be able
to compile and then execute code within the
compiler). Many other systems are continuously
running and require the ability to be upgraded
in pieces without stopping the process.

Dynamic loading simply isn't negotiable these days.
A translator that can't do it is useless in a very
large class of commercial applications.


> + Stupidity.  Objective Caml's popularity in academia is a curse as well 
> as a blessing.  For every coder like me who wonders if he should rather 
> have gone into academia, industry has a hundred coders who think career 
> academics are a fat lot of pencil-necked geeks who can't get "real" 
> programming jobs.  


Of course they are (ducks for cover :-)

> This is why industry continues to be populated with 
> idiots 


now who is being prejudiced?

>who think the reason Java programs so often perform badly is the 
> garbage collector.  These are also the same people who will tell you 
> that the syntax of Objective Caml is intolerably bizarre, 


It is, believe me, it is. So is C++ syntax :-)
---
My data: I used Ocaml in a heavy commerical environment,
(the job was to produce a programming language).

The major concern was #1: lack of programmers.
The other concern was the licence.
The job was killed, not because of Ocaml,
but because in an engineering shop few had any idea
of the requirements for a research project,
or the issues involved in designing a programming language.

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

What kind of industry do you mean? (Was: [Caml-list] objective caml and industry)

[Mattias Waldau]

Do you mean by industry that you are going to 
make commercial software using O'Caml?

As I see it there are several typical categories 
of commercial programs:

1. programs for internal use within an 
   organization (price = production cost)
2. server software (typical price > $15000)
3. client software (typical price $10 to $1000)

and there are essentially two OS out there:
a. Windows (hopefully we can soon ignore Windows 9x)
b. *nix

And unless you have a lot of VC-capital, the only 
combination where you can make money within a year 
or so is "client software" on "windows".

Reason:
1. Organizations buy server-software from established vendors
2. there are too few *nix out there

However, most of people on this list use *nix and create 
extra libraries for O'Caml on *nix. Most of these are 
useless for making commercial sellable software, since 
if you produce commercial software, you have to focus on 
what makes the software good and sellable, not learning 
how to compile PCRE on windows (Sorry Markus, just an example :-).

So if you want O'Caml to be used by commercial developers
creating commercial software, make sure that your libraries
work on windows. (And use the LGPL or even better the BSD-license,
if I improve a BSD-license library, I will of course try to
merge it with the general available version, so that I don't
have to maintain it.)

Due to the above reasons I only use core Ocaml and pure
Ocaml-libraries. I develop under Linux, in order to be able
to debug, and create release on Windows.

/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

Re: What kind of industry do you mean? (Was: [Caml-list] objective caml and industry)

[Markus Mottl]

On Sun, 01 Sep 2002, Mattias Waldau wrote:
> However, most of people on this list use *nix and create extra libraries
> for O'Caml on *nix. Most of these are useless for making commercial
> sellable software, since if you produce commercial software, you have
> to focus on what makes the software good and sellable, not learning
> how to compile PCRE on windows (Sorry Markus, just an example :-).

No need to feel sorry! I work in a place privileged enough that I can
let Windows rot in benign neglect... ;-)

In any case, the main issue of making PCRE work on Windows is the
C-library, for which you need a C-compiler and linker. The OCaml-part
should work out-of-the-box. It's therefore not so much a problem caused
by INRIA but by Microsoft not shipping standard development tools with
their operating systems.

> So if you want O'Caml to be used by commercial developers creating
> commercial software, make sure that your libraries work on windows.

Well, even with those difficulties put in our way by Microsoft, people
obviously manage to get around them.

> Due to the above reasons I only use core Ocaml and pure
> Ocaml-libraries. I develop under Linux, in order to be able to debug,
> and create release on Windows.

Unfortunately, not everbody has as much choice as we have...

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~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

[Caml-list] wxOCaml?

[Dave Mason]

There are a few messages in the mailing list talking about wxWindows
integration with OCaml, but I see no announcement of its availability.
I presume that means that nobody got to the point of making it work.

I'd really like to have a portable native-style windowing API, and
wxWindows looks like the best bet, so I'm planning on working on this.
Anybody with interest in helping?

Thanks  ../Dave
-------------------
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: What kind of industry do you mean? (Was: objective caml and industry)

[Michaël Grünewald]

Markus Mottl <markus@oefai.at> writes:

> On Sun, 01 Sep 2002, Mattias Waldau wrote:
> > However, most of people on this list use *nix and create extra libraries
> > for O'Caml on *nix. Most of these are useless for making commercial
> > sellable software, since if you produce commercial software, you have
> > to focus on what makes the software good and sellable, not learning
> > how to compile PCRE on windows (Sorry Markus, just an example :-).
> 
> No need to feel sorry! I work in a place privileged enough that I can
> let Windows rot in benign neglect... ;-)
> 
> In any case, the main issue of making PCRE work on Windows is the
> C-library, for which you need a C-compiler and linker. The OCaml-part
> should work out-of-the-box. It's therefore not so much a problem caused
> by INRIA but by Microsoft not shipping standard development tools with
> their operating systems.

Maybe is it good advice to look after Cygwin ?

> > So if you want O'Caml to be used by commercial developers creating
> > commercial software, make sure that your libraries work on windows.
> 
> Well, even with those difficulties put in our way by Microsoft, people
> obviously manage to get around them.
> 
> > Due to the above reasons I only use core Ocaml and pure
> > Ocaml-libraries. I develop under Linux, in order to be able to debug,
> > and create release on Windows.
> 
> Unfortunately, not everbody has as much choice as we have...
-- 
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: What kind of industry do you mean? (Was: [Caml-list] objective caml and industry)

[Alessandro Baretta]

Mattias Waldau wrote:
 > Do you mean by industry that you are going to
 > make commercial software using O'Caml?
 >
 > As I see it there are several typical categories
 > of commercial programs:
 >
 > 1. programs for internal use within an
 >    organization (price = production cost)
 > 2. server software (typical price > $15000)
 > 3. client software (typical price $10 to $1000)
 >
 > and there are essentially two OS out there:
 > a. Windows (hopefully we can soon ignore Windows 9x)
 > b. *nix
 >
 > And unless you have a lot of VC-capital, the only
 > combination where you can make money within a year
 > or so is "client software" on "windows".

I don't agree. My customers pay me to develop server
software on *nix, where the clients just happen to be Linux
boxes but might just as well be windows boxes, for all I
care. And I'm paid pretty well actually.

I am not using only O'Caml. As I am developing a data
centric application, I use SQL and XML tools extensively.
Presently, PXP is a very strong XML parser, but it lacks
support for XSLT (XSchema would be nice, too), so I am
forced to go with Xalan of the Apache foundation.

The bottom line is: 1) you don't need to develop Windows
software to make money, and 2) you'd better focus on writing
high quality code with high quality software development tools.

BTW, I'd gladly give up XSLT and SQL if, respectively, we
had a pseudo-official XML transformation API for Ocaml, and
there were Caml server-side bindings with PostgreSQL. In the
first place, I'd be able to statically typecheck my XML
transformation code. In the second place, I'd be able to
write type safe queries in such complex contexts where
baseline SQL is insufficent and the generality of pl/pgSQL
is needed.

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: What kind of industry do you mean? (Was: [Caml-list] objective caml and industry)

[Oleg]

On Sunday 01 September 2002 05:18 am, Mattias Waldau wrote:
> Due to the above reasons I only use core Ocaml and pure
> Ocaml-libraries. I develop under Linux, in order to be able
> to debug, and create release on Windows.

Client software in O'Caml? What type? Are you planning to or selling it 
already?

Cheers
Oleg
-------------------
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] objective caml and industry

[Oleg]

On Friday 30 August 2002 10:26 pm, John Max Skaller wrote:
> The coming English translation of the new O'Reilly Ocaml
> book is the most significant step forward here since
> Bagley's Shootout showed Ocaml is the top performing
> language after C.

While Bagley's Shootout was good PR because of its Slashdot exposure, as I 
mentioned recently [1], Bagley confuses doubly-linked lists and deques, and 
then goes on to benchmark C++ doubly-linked list against O'Caml pre-allocated 
array. I don't want to say anything about scientific integrity, since I think 
INRIA simply overlooked the poor quality and extreme lopsidedness of the 
Shootout (They reference it on O'Caml's front page)

Regards,
Oleg

[1] http://caml.inria.fr/archives/200208/msg00332.html
The Shootout page I referenced changed a bit since Aug 19, 2002, but, still, 
it was the misleading results that were publicized.
-------------------
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: What kind of industry do you mean? (Was: [Caml-list] objective caml and industry)

[Gerd Stolpmann]

Am 2002.09.02 14:43 schrieb(en) Alessandro Baretta:

> BTW, I'd gladly give up XSLT and SQL if, respectively, we
> had a pseudo-official XML transformation API for Ocaml, and

What do you mean with "pseudo-official"?

A remark as developer of free software: One of the advantages
is that I can do what I want, nobody forces me to develop in a
certain way, or direction. Free software is basically software 
without standards. Industry needs standards to make their
products interchangeable, but this is not a key point for free
software, because you have the sources, and you have some
control over them. PostgreSQL is the best example for this;
originally it did not support SQL, but had some unique features
other DBMS did not have. As a user you get the benefits of the
freedom of the developers, but at the price of lacking secondary
virtues such as standard-conformance.

Why don't we have a generally accepted XML transformation API?
It would not be very much work to develop such an API, and to
do a prototype for an implementation. I suppose that auch an
API is not really needed, at least now.

> there were Caml server-side bindings with PostgreSQL. In the
> first place, I'd be able to statically typecheck my XML
> transformation code. In the second place, I'd be able to
> write type safe queries in such complex contexts where
> baseline SQL is insufficent and the generality of pl/pgSQL
> is needed.

Gerd
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------
-------------------
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: An XML standard API? (was:What kind of industry do you mean?)

[Alessandro Baretta]

Gerd Stolpmann wrote:
> Am 2002.09.02 14:43 schrieb(en) Alessandro Baretta:
> 
>>BTW, I'd gladly give up XSLT and SQL if, respectively, we
>>had a pseudo-official XML transformation API for Ocaml, and
> 
> 
> What do you mean with "pseudo-official"?

PXP is at least "pseudo-official", IMHO. It does not take an 
international consortium such as the W3C or the ISO to make 
a free software API "standard, for all practical purposes". 
Just consider SAX. It is basically just as "standard" as the 
DOM, which is not a standard anyway.

> A remark as developer of free software: One of the advantages
> is that I can do what I want, nobody forces me to develop in a
> certain way, or direction. Free software is basically software 
> without standards.

This I disagree with. Standards are useful in the free 
software community, possibly even more than in the 
commercial software industry. The whole idea behind free 
software is the ability to develop complex applications in a 
distributed, decentralized, and ultimately *free* fashion. 
But standards, whether official or _de_facto_ are needed to 
allow the mutual benefits of code sharing. Such standards by 
no means infringe on your freedom to code whatever you want, 
however you like.

> Industry needs standards to make their
> products interchangeable, but this is not a key point for free
> software, because you have the sources, and you have some
> control over them. PostgreSQL is the best example for this;
> originally it did not support SQL, but had some unique features
> other DBMS did not have. As a user you get the benefits of the
> freedom of the developers, but at the price of lacking secondary
> virtues such as standard-conformance.
> 
> Why don't we have a generally accepted XML transformation API?
> It would not be very much work to develop such an API, and to
> do a prototype for an implementation. I suppose that auch an
> API is not really needed, at least now.

It is not that easy. It takes interest and consensus. I'm 
not sure how widespread is the need for XML processing 
capabilities in the O'Caml community, but I have a definite 
feeling that consensus would be most difficult to achieve on 
an _a_priori_ basis. Probably, the most efficient way to 
achieve such consensus would be to develop the 
"Super-Duper-XML-lib" and distribute it. Consensus would 
simply condense around it.

Ideally, such a library would be built on PXP (a _de_facto_ 
standard, as I already noted), and implement an XML type 
checking à la XSchema, but somehow linked with the O'Caml 
type system. The transformation API would then have to 
implement the same expressiveness of XSLT while retaining 
the static type safety of O'Caml.

This is a wish list I do not address to anyone in 
particular. If I were competent enough in markup languages 
and related tools I might take up the effort myself. At 
present, I do not consider myself apt for such a task, so I 
have little choice but to use what tools are available: 
XSLT, mainly, and possibly XSchema. Not entirely 
satisfactory from my standpoint, but still better (probably) 
than having to code XML validation and transformation 
functions from scratch in O'Caml.

Regards,
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] objective caml and industry

[Chris Hecker]

> www.jetcafe.org/~npc/doc/euc00-sendmail.html

I was interested to read this, but was sad to see that they didn't
actually ship the app, or even beta test it, according to this quote:

"After performing code cleanup based on Lennart's suggestions, we
prepared for an initial test release of the system during the summer
of 2000. That release has been put on hold while we perform
integration work with another complex legacy application and improve
our monitoring system."

Chris


-------------------
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] objective caml and industry

[Jonathan Coupe]

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

www.jetcafe.org/~npc/doc/euc00-sendmail.html

Interested parties might want to look at this article, written by a
(non-Ericson) team that decided to use Erlang for an industrial project.
Reading a software marketing book like "Inside The Tornado" might be
interesting too.

- Jonathan Coupe


[-- Attachment #2: Type: text/html, Size: 704 bytes --]