[Caml-list] productivity improvement

[Caml-list] productivity improvement

[Oleg]

Hi

As part of learning O'Caml I was rewriting small personal utility programs 
from C++ to O'Caml and I have not seen any productivity improvement so far. 
Possibly, this is because I essentially use the same imperative style or 
because my knowledge of O'Caml is rudimental or because there is no 
productivity enhancement, at least for the programs I was translating or for 
small programs in general.

What are the _simplest_ examples that demonstrate considerable (> 2:1) O'Caml 
vs C++ productivity improvement (in terms of program size) and where can I 
find them?

Thanks
Oleg

P.S. Just trying to stay motivated.
-------------------
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] productivity improvement

[Michael Vanier]

Imperative code in ocaml is not going to be massively different than
imperative code in any other (garbage-collected) language.  You need to
learn the functional style.  Why not post some of the personal utility
programs to the list and see if we can make them more idiomatic?

Personally, I think one of the big issues wrt C++ vs. ocaml is simply the
presence of a garbage collector and real strong static type checking.  The
productivity increases are as much in the form of reduced debugging time as
they are in the form of fewer lines of code.  However, higher-order
functions can give you a substantial savings in code size.

Mike


> From: Oleg <oleg_inconnu@myrealbox.com>
> Date: Mon, 8 Jul 2002 15:53:26 -0400
> 
> Hi
> 
> As part of learning O'Caml I was rewriting small personal utility programs 
> from C++ to O'Caml and I have not seen any productivity improvement so far. 
> Possibly, this is because I essentially use the same imperative style or 
> because my knowledge of O'Caml is rudimental or because there is no 
> productivity enhancement, at least for the programs I was translating or for 
> small programs in general.
> 
> What are the _simplest_ examples that demonstrate considerable (> 2:1) O'Caml 
> vs C++ productivity improvement (in terms of program size) and where can I 
> find them?
> 
> Thanks
> Oleg
> 
> P.S. Just trying to stay motivated.
-------------------
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] productivity improvement

[John Max Skaller]

Michael Vanier wrote:

>Imperative code in ocaml is not going to be massively different than
>imperative code in any other (garbage-collected) language.  
>
I don't agree.

All imperative languages -- including ocaml -- contain functional parts,
usually known as 'expressions'. The ability to write clear and simple
imperative code is greatly enhanced by a powerful functional system
precisely because it allows the imperative part of the language to
be used just for imperative things. In a language like C the
functional system is so weak, that one must use the imperative
features just to implement purely functional constructions.

For example, you cannot initialise a structure in C except
with an imperative statement:

    X x = {1,2,3,4};

For example, you cannot encode a switch (other than
over a bool) in an expression: you have a to use a statement,
although you can wrap it in a function and call that ..
although of course you lose your environment and so you need
to pass them ... argggrgrgrg. Perhaps you can do better with:

    int x = expr;
    result =
        x==1 ? blah1() :
        x==2 ? blah2():
        x==3 ? blah3():
        ...

As someone said recently "ocaml forever" :-))

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




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

Re: [Caml-list] productivity improvement

[Alessandro Baretta]

John Max Skaller wrote:
> 
> As someone said recently "ocaml forever" :-))
> 

Just today I have found a counterexample where C does a 
better job than O'Caml--at least within the context of my 
understanding of and ability with the two languages.

This is the problem: I have a text file containing a fairly 
long table extracted from a database (approximately 73000 
lines). I had to write a program to parse each line, extract 
only the relevant fields and reformat dates and times 
according to some sensible format (such as dd/mm/yyyy 
hh:mm:ss as opposed to yyyymmdd hhmmss00). This is how I 
solved the problem in C:


#include <stdio.h>

int main ( int argc , char *argv[]) {

#define ALF " %*s"
#define ISIN " %*s"
#define DATE " %4s%2s%2s"
#define TIME " %2s%2s%2s%*2s"
#define PRICE "%s"
#define QN     "%s"
#define CNTVL  "%*s"


   char scanner[] = ALF ISIN DATE TIME PRICE QN CNTVL;
   char printer[] = "%s/%s/%s\t%s:%s:%s\t%s\t%s\n";

   char year[8], month[8], day[8];
   char hh[4], mm[4], ss[4];
   char price[64], qn[64];

   int n;

   while (1) {
     n=scanf(scanner, year, month, day,
	hh, mm, ss, price, qn);
     if (n==EOF) break;
     printf(printer, day, month, year,
	hh, mm, ss, price, qn);
   }
}


I was not able to figure out an easy way to do this in 
O'Caml. Of course, I could have used ocamllex and ocamlyacc 
to define a lexer and a parser, but what I really needed was 
a scanf function.

My intuition is that we badly need a *functional* scanf. Of 
course, I despise the idea of a format string. I had to use 
7 #defines in order to make some sense of the scanf format, 
and I might have done the same for printf, where the format 
not a little simpler.

Of course, my understanding of O'Caml is incomplete, and I'm 
sure someone will be good enough to teach how I could have 
done the same in O'Caml with only a fraction of the lines of 
code.

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] productivity improvement

[Jun P.FURUSE]

Hello,

> Just today I have found a counterexample where C does a 
> better job than O'Caml--at least within the context of my 
> understanding of and ability with the two languages.
[..]
> I was not able to figure out an easy way to do this in 
> O'Caml. Of course, I could have used ocamllex and ocamlyacc 
> to define a lexer and a parser, but what I really needed was 
> a scanf function.

Ah, you should have waited for few days.
The module Scanf is available in the next O'Caml version 3.05, 
which will be distributed soon...

-
Jun

-------------------
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] productivity improvement

[Pierre Weis]

> Hello,
> 
> > Just today I have found a counterexample where C does a 
> > better job than O'Caml--at least within the context of my 
> > understanding of and ability with the two languages.
> [..]
> > I was not able to figure out an easy way to do this in 
> > O'Caml. Of course, I could have used ocamllex and ocamlyacc 
> > to define a lexer and a parser, but what I really needed was 
> > a scanf function.
> 
> Ah, you should have waited for few days.
> The module Scanf is available in the next O'Caml version 3.05, 
> which will be distributed soon...
> 
> -
> Jun
> 
> -------------------
> 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

As Jun said, a scanf facility will be introduce in the next version of
Objective Caml. Consider this feature as experimental, and fill free
to send us comments, if you can test it, have remarks or additions to
suggest, or more importantly, if you find bugs before the release!

With this new (functional) scanf facility, your program sounds like
this in Caml:

try
  while true do
    Scanf.scanf " %s %s %4s%2s%2s %2s%2s%2s%2s %s %s %s"
      (fun _ _ year month day hh mm ss _ price qn _ ->
         Printf.printf "%s/%s/%s\t%s:%s:%s\t%s\t%s\n" 
           day month year hh mm ss price qn)
  done
with End_of_file -> ();;

We can now compare with your C version of the program:

Conciseness and elegance: well, I'm not too unhappy of the Caml code,
but yes, it can be considered as a bit cryptic ...

Readability: in this example, we certainly lack the ability to skip an
argument as in the %*s of the C version; also, and once again, we lack
a format concatenation primitive to cleanly express the decomposition
of the scanf format at hand (which means that we still lack the fourth
type variable argument in the type of format strings that would permit
the sound implementation of this feature).

Performance: compared to the ggc-O2 compiled C version, this program
is about twice slowlier, which is a performance of the Objective Caml
compiler, given the highly readable and simple-minded source code of
the Scanf module.

Anyway, thanks a lot for your interesting example that forced me to
review the code of the Scanf module, and to slightly modify its
functionalities in order to accomodate your program more elegantly!

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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] Universal Serializer (was: productivity improvement)

[Oleg]

On Monday 08 July 2002 04:05 pm, John Malecki wrote in personal email:

> This is no an ocaml specific productivity improvement but the ability
> to marshal a data structure without having to write any data structure
> specific code is very productive.  

Speaking of complex data  structures with no code: Oftentimes, I need to 
create data structures, then write code that saves the structure to a file 
and code that reincarnates it. 

AFAICT if a data structure is created using combinations of unions, lists, 
arrays, etc. of built-in types or objects that, e.g. already have "write" and 
"read" methods defined,  then in theory, a hypothetical compiler ought to be 
able to generate such serialization functions automatically (IIRC Lisp and 
Scheme do this because of the simplicity of their type systems, but I may be 
wrong here).

Does O'Caml allow any type of short-cuts to avoid coding serialization 
manually?

Thanks
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] Universal Serializer (was: productivity improvement)

[Nicolas Cannasse]

> AFAICT if a data structure is created using combinations of unions, lists,
> arrays, etc. of built-in types or objects that, e.g. already have "write"
and
> "read" methods defined,  then in theory, a hypothetical compiler ought to
be
> able to generate such serialization functions automatically (IIRC Lisp and
> Scheme do this because of the simplicity of their type systems, but I may
be
> wrong here).
>
> Does O'Caml allow any type of short-cuts to avoid coding serialization
> manually?

Of course !
You can use either the Marshal module or the input_value / output_value to
read / write any data structures composed of basic ocaml types ( including
complexes & recursives structures - list arrays etc.).
Note that actually the marshaling process is unsafe ( your program can crash
if you're not reading the same type that you've written ). If you're using
native C data embedded into OCaml type, you can write your own (de)serialize
functions in C by using custom blocks.

PS : Object serialization is not available.

Nicolas Cannasse

-------------------
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] Universal Serializer (was: productivity improvement)

[Nicolas Cannasse]

> > This is no an ocaml specific productivity improvement but the ability
> > to marshal a data structure without having to write any data structure
> > specific code is very productive.

BTW OCaml functional programming and memory management are two ways of
increasing productivity. Pattern matching on structures is also wonderful.
For most of the programs, I will say that the productivity rate against C is
around 1:3.

Nicolas Cannasse

-------------------
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] Universal Serializer (was: productivity improvement)

[John Max Skaller]

>
>
>
>BTW OCaml functional programming and memory management are two ways of
>increasing productivity. Pattern matching on structures is also wonderful.
>For most of the programs, I will say that the productivity rate against C is
>around 1:3.
>
>Nicolas Cannasse
>
You must be an academic.:-) Try between 10:1 and 100:1,
*assuming* that any libraries you need are available,
and a reasonably complex piece of software.

You just can't underestimate how difficult it is to find
bugs in C codes of reasonable size. Such bugs almost never
happen in Ocaml. The biggest problem in Ocaml is type inference,
and the resulting loss of localisation of error diagnostics, but
such compile time errors can be resolved *definitely*;
that is, you know for sure when you've fixed them
(because the compiler stops hassling you).

Ohhhh.. just imagine if GTK/Gnome/Gui stuff on RH linux
were written in Ocaml .. it might actually work!

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




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

Re: [Caml-list] Universal Serializer (was: productivity improvement)

[Michael Vanier]

> Date: Thu, 11 Jul 2002 02:06:15 +1000
> From: John Max Skaller <skaller@ozemail.com.au>
> 
> >
> >BTW OCaml functional programming and memory management are two ways of
> >increasing productivity. Pattern matching on structures is also wonderful.
> >For most of the programs, I will say that the productivity rate against C is
> >around 1:3.
> >
> >Nicolas Cannasse
> >
> You must be an academic.:-) Try between 10:1 and 100:1,
> *assuming* that any libraries you need are available,
> and a reasonably complex piece of software.
> 

I agree, but the productivity increase is going to depend a lot on the
experience and skill of the ocaml programmer.  As a newbie, I find myself
using a lot of lame imperative idioms before discovering more elegant (and
concise) functional ones.

> You just can't underestimate how difficult it is to find
> bugs in C codes of reasonable size. Such bugs almost never
> happen in Ocaml. 

Definitely, although the same could be said for java or C#, if by "such
bugs" you mean memory leaks and memory corruption.  For a more
ocaml-specific example, I find that algebraic data types with
pattern-matching (and the compiler warnings that occur if you fail to match
all patterns) is something that ocaml has that java/C# don't and which
can massively improve the quality of code (as well as making it much more
comprehensible).

> The biggest problem in Ocaml is type inference,
> and the resulting loss of localisation of error diagnostics, but
> such compile time errors can be resolved *definitely*;
> that is, you know for sure when you've fixed them
> (because the compiler stops hassling you).

What do you mean by "loss of localisation of error diagnostics"?  Do you
mean that a type error in one location giving an expression which can still
compile (but to the wrong type) results in an obscure error message
elsewhere?  I agree that that's occasionally a minor pain, but it's hardly
in the same league with memory leaks etc.  If that's ocaml's biggest
problem, then ocaml is the best computer language I've ever seen.

> 
> Ohhhh.. just imagine if GTK/Gnome/Gui stuff on RH linux
> were written in Ocaml .. it might actually work!
> 

*drool*  I would totally *love* to have this.

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] Universal Serializer (was: productivity improvement)

[Nicolas Cannasse]

> > >BTW OCaml functional programming and memory management are two ways of
> > >increasing productivity. Pattern matching on structures is also
wonderful.
> > >For most of the programs, I will say that the productivity rate against
C is
> > >around 1:3.
> > >
> > >Nicolas Cannasse
> > >
> > You must be an academic.:-) Try between 10:1 and 100:1,
> > *assuming* that any libraries you need are available,
> > and a reasonably complex piece of software.
> >
>
> I agree, but the productivity increase is going to depend a lot on the
> experience and skill of the ocaml programmer.  As a newbie, I find myself
> using a lot of lame imperative idioms before discovering more elegant (and
> concise) functional ones.

Yes perhaps I've been written too much C++ in my childhood so I'm no more
able to introduce memory bugs in C++ code :))
It's easier when you're using good data structures, and a good debugger
 MSVC++ one is wonderfull , sorry of *nix guys. )

> > The biggest problem in Ocaml is type inference,
> > and the resulting loss of localisation of error diagnostics, but
> > such compile time errors can be resolved *definitely*;
> > that is, you know for sure when you've fixed them
> > (because the compiler stops hassling you).
>
> What do you mean by "loss of localisation of error diagnostics"?  Do you
> mean that a type error in one location giving an expression which can
still
> compile (but to the wrong type) results in an obscure error message
> elsewhere?  I agree that that's occasionally a minor pain, but it's hardly
> in the same league with memory leaks etc.  If that's ocaml's biggest
> problem, then ocaml is the best computer language I've ever seen.

It is :)
Actually I really think that the reading of errors messages and the "type
debugging" that sometimes you have to do is really a part of the knowledge
of the language. I mean, instead of learning only syntax ( as in C ) you
also have to learn to handle such errors. Quite difficult in the beggining,
it becomes easier later.... ( BTW, that could be the definition of "what is
a good tool" )

Nicolas Cannasse

-------------------
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] Universal Serializer (was: productivity improvement)

[John Max Skaller]

Michael Vanier wrote:

>>You must be an academic.:-) Try between 10:1 and 100:1,
>>*assuming* that any libraries you need are available,
>>and a reasonably complex piece of software.
>>
>
>I agree, but the productivity increase is going to depend a lot on the
>experience and skill of the ocaml programmer.  As a newbie, I find myself
>using a lot of lame imperative idioms before discovering more elegant (and
>concise) functional ones.
>
Ocaml does imperative programming better than C and C++ too.
So even your 'lame' imperative code can be produced faster and more
reliably in Ocaml.

Example: values (declared in let bindings) scope better.
Variables (references) must be initialised -- sometimes this
is a pain, but usually it is a bonus.

>You just can't underestimate how difficult it is to find
>bugs in C codes of reasonable size. Such bugs almost never
>happen in Ocaml. 
>
>
>Definitely, although the same could be said for java or C#, if by "such
>bugs" you mean memory leaks and memory corruption. 
>
 Well, if you run java or C#, you still have to cast 'object' down, and 
so you can get run-time
errors -- where using Ocaml this class of error cannot happen.

Ocaml run time errors include array (and string) bounds exceptions and 
infinite recursions:
static type checking could detect the first, but not the second.


>>The biggest problem in Ocaml is type inference,
>>and the resulting loss of localisation of error diagnostics, but
>>such compile time errors can be resolved *definitely*;
>>that is, you know for sure when you've fixed them
>>(because the compiler stops hassling you).
>>
>
>What do you mean by "loss of localisation of error diagnostics"?  Do you
>mean that a type error in one location giving an expression which can still
>compile (but to the wrong type) results in an obscure error message
>elsewhere?  
>
Yes.

>I agree that that's occasionally a minor pain, but it's hardly
>in the same league with memory leaks etc.  
>
Agree.

>If that's ocaml's biggest problem,
>
It's one of them (IMHO)

>then ocaml is the best computer language I've ever seen.
>
I agree :-)

>Ohhhh.. just imagine if GTK/Gnome/Gui stuff on RH linux
>were written in Ocaml .. it might actually work!
>
>*drool*  I would totally *love* to have this.
>
heh :-)

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

[Caml-list] Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[Berke Durak]

On Fri, Jul 12, 2002 at 10:41:35PM +1000, John Max Skaller wrote:
[...]
> Ocaml run time errors include array (and string) bounds exceptions and 
> infinite recursions:
> static type checking could detect the first, but not the second.

Hey, wait a minute, how do you plan to statically detect bounds exceptions ?
It's as undecidable as detecting infinite recursions.

	let rec f () =
	   let a = [|1;2|] in
       if compiler_is_gonna_say_that_there_is_gonna_be_a_bounds_error f then
          a.(0)
       else
          a.(3)
-- 
Berke Durak
-------------------
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] Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[Alessandro Baretta]

Berke Durak wrote:
> On Fri, Jul 12, 2002 at 10:41:35PM +1000, John Max Skaller wrote:
> [...]
> 
> Hey, wait a minute, how do you plan to statically detect bounds exceptions ?
> It's as undecidable as detecting infinite recursions.
> 
> 	let rec f () =
> 	   let a = [|1;2|] in
>        if compiler_is_gonna_say_that_there_is_gonna_be_a_bounds_error f then
>           a.(0)
>        else
>           a.(3)

If the compiler attempted to catch at least the most evident 
  bounds errors, it would very simply detect that your code 
contains an expression which, if evaluated, would raise a 
runtime bounds error. Hence, the compiler should simply 
reject the code. Of course, in the absence of some unusual 
limitation on the expressive power of array creation and 
indexing expression, the general problem of static detection 
of array indexing errors is undecidable.

I wonder if the compiler gurus at the INRIA know what kinds 
of constraints imposed on the language would allow the 
compiler to statically check array indexing. I can imagine a 
few applications, such as signal analysis, where the program 
logic is simple enough that such a restricted language might 
suffice, and come to the aid of the developer who presently 
uses unsafe arrays for the sake of speed, but with no help 
from the compiler at prooving that the program is correct 
with respect to array indexing.

I have a feeling that most applications which would benefit 
from static checking of array indexing boil down to finite 
state automata. I'm pretty sure that a language based of 
FSAs could do static bounds checking.

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] Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[Xavier Leroy]

> Of course, in the absence of some unusual 
> limitation on the expressive power of array creation and 
> indexing expression, the general problem of static detection 
> of array indexing errors is undecidable.

Indeed.

> I wonder if the compiler gurus at the INRIA know what kinds 
> of constraints imposed on the language would allow the 
> compiler to statically check array indexing.

Well, for this purpose, array index expressions must be restricted to
a sub-language where inequations between index expressions are
decidable.  A well-known such sub-language is Presburger arithmetic:
index expressions are variables, constants, and sums and products of
expressions.  I don't know of any significantly more expressive
sub-language that has the required decidability properties.

> I can imagine a few applications, such as signal analysis, where the
> program logic is simple enough that such a restricted language might
> suffice, and come to the aid of the developer who presently uses
> unsafe arrays for the sake of speed, but with no help from the
> compiler at prooving that the program is correct with respect to
> array indexing.

Obligatory preliminary remark: the cost of run-time array bound checks
is not that high, since on modern processors it is performed
largely in parallel with the actual array access.  On my tests,
ocamlopt -unsafe is at best 25% faster than ocamlopt on array
intensive programs.

This said, the approach you outline was investigated in depth by
Hongwei Xi in his work on Dependent ML:

        http://www.ececs.uc.edu/~hwxi/DML/DML.html

It's an interesting reading.

- 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] Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[Noel Welsh]

--- Alessandro Baretta <alex@baretta.com> wrote:
> I wonder if the compiler gurus at the INRIA know
> what kinds 
> of constraints imposed on the language would allow
> the 
> compiler to statically check array indexing. 

I'm not a compiler guru from INRIA but I can point out
the languages SAC (Single Assignment C) and FiSH (ask
Google; I'm feeling lazy) that do array shape
inference.  Basically the type system for arrays in
augmented by their shape and shapes are inferred in a
similar way to types.  In addition to eliminating
bounds checks the compiler can do funky reordering
optimisations (because these are functional languages,
so evaluation order is not important) and produce code
faster than Fortran. Exciting stuff if you're into
numerical code.

Noel

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
-------------------
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] Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[Oleg]

On Monday 15 July 2002 04:39 am, Noel Welsh wrote:
> FiSH (ask
> Google; I'm feeling lazy)

Even Altavista doesn't support case-sensitive searches anymore.

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] Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[Michael Vanier]

http://www-staff.mcs.uts.edu.au/~cbj/FISh/

Mike

> From: Oleg <oleg_inconnu@myrealbox.com>
> Date: Mon, 15 Jul 2002 17:22:35 -0400
> 
> On Monday 15 July 2002 04:39 am, Noel Welsh wrote:
> > FiSH (ask
> > Google; I'm feeling lazy)
> 
> Even Altavista doesn't support case-sensitive searches anymore.
> 
> 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] Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[Florian Hars]

Oleg wrote:
> On Monday 15 July 2002 04:39 am, Noel Welsh wrote:
> 
>>FiSH (ask Google; I'm feeling lazy)
> 
> Even Altavista doesn't support case-sensitive searches anymore.

Learn to use search engines intelligently: You know that *FiSH* (correct 
capitalization is FISh, so a case sensitive search wouldn't have bought 
you anything, anyway :-)) is a *language* with good *array* processing 
capabilities. So here we go:

http://www.google.com/search?q=fish+language+array

The first four results are relevant.

Yours, Florian Hars

-------------------
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: Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[John Max Skaller]

Berke Durak wrote:

>On Fri, Jul 12, 2002 at 10:41:35PM +1000, John Max Skaller wrote:
>[...]
>
>>Ocaml run time errors include array (and string) bounds exceptions and 
>>infinite recursions:
>>static type checking could detect the first, but not the second.
>>
>
>Hey, wait a minute, how do you plan to statically detect bounds exceptions ?
>It's as undecidable as detecting infinite recursions.
>
Nah. Just depends on your mindset.
In Pascal, array indexes have a specific type,
(possibly a subrange type). So it isn't possible to
get an array bounds error, only a type error
if the index is the wrong type.

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




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

Re: [Caml-list] Re: Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[Johan Baltié]

Le Mardi 16 Juillet 2002 22:22, John Max Skaller a écrit :
> Berke Durak wrote:
> >On Fri, Jul 12, 2002 at 10:41:35PM +1000, John Max Skaller wrote:
> >[...]
> >
> >>Ocaml run time errors include array (and string) bounds exceptions and
> >>infinite recursions:
> >>static type checking could detect the first, but not the second.
> >
> >Hey, wait a minute, how do you plan to statically detect bounds exceptions
> > ? It's as undecidable as detecting infinite recursions.
>
> Nah. Just depends on your mindset.
> In Pascal, array indexes have a specific type,
> (possibly a subrange type). So it isn't possible to
> get an array bounds error, only a type error
> if the index is the wrong type.

What about defining type that are subranges of int ? 
à la ADA...

-- 
Ciao

Jo

-------------------
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] Re: Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[Hao-yang Wang]

> > >Hey, wait a minute, how do you plan to statically detect bounds
exceptions
> > > ? It's as undecidable as detecting infinite recursions.
> >
> > Nah. Just depends on your mindset.
> > In Pascal, array indexes have a specific type,
> > (possibly a subrange type). So it isn't possible to
> > get an array bounds error, only a type error
> > if the index is the wrong type.
>
> What about defining type that are subranges of int ?
> à la ADA...

Then how do you make sure that the result of an arithmetic expression is
still within that sub-range? For example, m.( i + j ) ?

Cheers,
Hao-yang Wang
-------------------
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] Re: Statically detecting arrays bound exceptions ?? (was: Universal Serializer)

[Noel Welsh]

Just to add my 2p again:  The way to remove index
checks is to stop using them in the first place!  Just
like we don't write loops over lists, don't write
loops over arrays; use higher level iterators.  Check
out the with-loop construct in SAC, or the for loops
in Sisal, or
the constructs in APL/J, or Matlab, or the
PSI-Calculus etc.  All of these languages, to a
greater or less extent, remove the need for the humble
for loop.  Loops are for losers!

A good place to start:
http://www.informatik.uni-kiel.de/~cg/bib/bookshelf.html

Noel
--- Everyone wrote wrote:
> Lots of stuff about inferring index values

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
-------------------
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] Universal Serializer (was: productivity improvement)

[Eray Ozkural]

On Wednesday 10 July 2002 19:06, John Max Skaller wrote:
>
> Ohhhh.. just imagine if GTK/Gnome/Gui stuff on RH linux
> were written in Ocaml .. it might actually work!

You guys really need my ocaml bindings for Qt/KDE (assuming I finish writing 
it....) ;)

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
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] OCaml QT bindings

[Stefano Zacchiroli]

On Fri, Jul 12, 2002 at 04:41:36AM +0300, Eray Ozkural wrote:
> > Ohhhh.. just imagine if GTK/Gnome/Gui stuff on RH linux
> > were written in Ocaml .. it might actually work!
> 
> You guys really need my ocaml bindings for Qt/KDE (assuming I finish writing 
> it....) ;)

Yup!!! I've been wondering for such a binding for months .... (anyway
the impressive work to build up one stops me from starting the work :-),
could you tell us when you expect to have a working version?

BTW, obviously if you need help, feel free to ask!

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
-------------------
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] OCaml QT bindings

[Eray Ozkural]

On Friday 12 July 2002 11:10, Stefano Zacchiroli wrote:
> On Fri, Jul 12, 2002 at 04:41:36AM +0300, Eray Ozkural wrote:
> > > Ohhhh.. just imagine if GTK/Gnome/Gui stuff on RH linux
> > > were written in Ocaml .. it might actually work!
> >
> > You guys really need my ocaml bindings for Qt/KDE (assuming I finish
> > writing it....) ;)
>
> Yup!!! I've been wondering for such a binding for months .... (anyway
> the impressive work to build up one stops me from starting the work :-),
> could you tell us when you expect to have a working version?
>
> BTW, obviously if you need help, feel free to ask!

I think I will need help. The ocaml type system makes it very easy to get it 
right at the abstraction level but the mundane work of providing entry points 
for all Qt classes itself is not an easy task since you need a successful 
translator, or you will have to correct things by hand which is highly 
undesirable.

I'm right now at the stage of writing a C++ parser that will be sufficient for 
header files in KDE. The parser isn't finished yet, but I've based it on a 
grammar which targeted part of the ISO standard so when it's done I think it 
will be worthwhile.

Since I'm fond of parser combinators I'm writing the translator in Haskell 
language using Parsec library.

I've thought about what should be involved in the library and it seems at 
least the following will be necessary:

1) "C" bindings which will be entry points for constructor/destructor, member 
functions and selector/modifier functions for each member variable in each Qt 
class... This will abstract away C++ dispatch, inline, etc. Template 
functions will not be addressed. (But it will not be a problem to implement 
things like QStringList which inherit from template classes....)

2) A mapping of class inheritance and subtyping relations to ocaml classes. 
This should be relatively straightforward since ocaml type/class system 
covers a lot more ground than C++.

3) A mapping of parameter passing, and "new" / "delete" to ocaml. We're 
passing mostly plain pointers/references in Qt, but I think there are cases 
where this is not true. The object model would be taken akin to Java where 
each object is allocated on the heap to simplify this matter.

Optionally, I will see if I can come up with some ocaml code that will provide 
high level access to GUI code.

The help I can use now is: do you observe any difficulties with the approach I 
have roughly outlined? And are there any vital points that I seem to be 
missing?

Thanks,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
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: productivity improvement

[Oleg]

On Wednesday 10 July 2002 12:06 pm, John Max Skaller wrote:
> >BTW OCaml functional programming and memory management are two ways of
> >increasing productivity. Pattern matching on structures is also wonderful.
> >For most of the programs, I will say that the productivity rate against C
> > is around 1:3.
> >
> >Nicolas Cannasse
>
> You must be an academic.:-) Try between 10:1 and 100:1,
> *assuming* that any libraries you need are available,
> and a reasonably complex piece of software.

Looking at Halo [1] credits, one can see that it was developed by about 10 
programmers (there were also testers and artists involved). A single O'Caml 
programmer capable of developing such a game alone should certainly stand to 
make tons of money. Then why don't we see much software written in O'Caml?

I'm not buying the argument that "O'Caml isn't used in the industry because 
investors and project managers are stupid". You don't need a project manager 
if you can replace a team of 100 C/C++ programmers alone (or just 10 of 
them if you work in your spare time < 1 hour a day) [2]

Regards,
Oleg

[1] By far the best first-person-shooter game I've ever played in terms of 
AI, graphics, playability and relative freedom from bugs.

[2] The number is supposed to be even higher if you take into account that an 
n-fold increase in individual productivity is equivalent to more than an 
n-fold increase in team size.
-------------------
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] Re: productivity improvement

[Markus Mottl]

On Fri, 12 Jul 2002, Oleg wrote:
> Looking at Halo [1] credits, one can see that it was developed by about 10 
> programmers (there were also testers and artists involved). A single O'Caml 
> programmer capable of developing such a game alone should certainly stand to 
> make tons of money. Then why don't we see much software written in O'Caml?

Easy: almost all commercial and most academic programmers have never
heard of OCaml. That's a fact.

> I'm not buying the argument that "O'Caml isn't used in the industry
> because investors and project managers are stupid".

Nobody has ever said so. They are at least uninformed what concerns
this language. And even if they are informed, there are many commercial
reasons why OCaml might be a sub-optimal choice: lack of programmers,
lack of libraries for commercial purposes, etc. This is not just a matter
of language features.

> You don't need a project manager if you can replace a team of 100 C/C++
> programmers alone (or just 10 of them if you work in your spare time <
> 1 hour a day) [2]

Another reason why project managers don't want OCaml :-)

Now seriously, I don't quite get your argument. Do you have any
imagination, how difficult it is to find OCaml-programmers? I can tell
you of maybe three somewhat competent OCaml-programmers in my country.
Other programmers here are not incompetent in the sense that they don't
know how to program in general but in the sense that they have never used
(most often not even heard) of this language. If I founded a company
here using this technology, I'd get into very serious troubles when my
main programmer gets a brick on his head. Just too risky!

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

Re: [Caml-list] Re: productivity improvement

[Oleg]

On Friday 12 July 2002 07:23 am, Markus Mottl wrote:
>  If I founded a company
> here using this technology, I'd get into very serious troubles when my
> main programmer gets a brick on his head. Just too risky!

That's what insurance companies are for. IAE why would you want to hire more 
programmers if you were worth a hundred of them (by John's estimate)? 

Regards,
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] Re: productivity improvement

[Markus Mottl]

On Fri, 12 Jul 2002, Oleg wrote:
> On Friday 12 July 2002 07:23 am, Markus Mottl wrote:
> >  If I founded a company
> > here using this technology, I'd get into very serious troubles when my
> > main programmer gets a brick on his head. Just too risky!
> 
> That's what insurance companies are for. IAE why would you want to hire more 
> programmers if you were worth a hundred of them (by John's estimate)? 

Insurance = costs. Furthermore, 1:100 sounds quite a bit too
astronomical. I'd say that depending on the kind of the problem 1:3
to 1:10 is reasonable and fits well to the experience of others. E.g.,
the Erlang developers also report productivity gains in this range on
large-scale commercial projects. OCaml will most likely have similar
ratios.

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

Re: [Caml-list] Re: productivity improvement

[Pierre Weis]

Hi Markus,
[...]
> Insurance = costs. Furthermore, 1:100 sounds quite a bit too
> astronomical. I'd say that depending on the kind of the problem 1:3
> to 1:10 is reasonable and fits well to the experience of others. E.g.,
> the Erlang developers also report productivity gains in this range on
> large-scale commercial projects. OCaml will most likely have similar
> ratios.

I completely agree with you on those, somewhat impossible to obtain and
prove, productivity ratio gains. 1:3 to 1:10 is reasonable.

However, an interesting ratio seems to be forgotten in the discussion:
infinity :)

I mean, I know a lot of problems that could simply not have been
solved in any other language, and in this casess we observe this
extreme limit ratio.

No flame, please: I know that SML or Haskell could do roughly speaking
the same as Caml could do for the programmer, I also know that once
the program has been written and is fairly stable you can rewrite it
in any other language you want, even C++ or Java, provided you have
enough time and money. I also do know that there are a lot of
situations where you do not have enough time and/or money...

Regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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] Re: productivity improvement

[Markus Mottl]

On Fri, 12 Jul 2002, Pierre Weis wrote:
> I completely agree with you on those, somewhat impossible to obtain and
> prove, productivity ratio gains. 1:3 to 1:10 is reasonable.
> 
> However, an interesting ratio seems to be forgotten in the discussion:
> infinity :)
> 
> I mean, I know a lot of problems that could simply not have been
> solved in any other language, and in this casess we observe this
> extreme limit ratio.

Well, this is a simple consequence of us humans having finite brains
(though some hack\b\b\b\bprogrammers don't believe that ;)

Even if FPLs reduce complexity only slightly, this implies that there
must be previously insoluble problems that become solvable by their
application.

> No flame, please: I know that SML or Haskell could do roughly speaking
> the same as Caml could do for the programmer, I also know that once
> the program has been written and is fairly stable you can rewrite it
> in any other language you want, even C++ or Java, provided you have
> enough time and money. I also do know that there are a lot of
> situations where you do not have enough time and/or money...

Right, as soon as there are constraints (scarce resources), economical
thinking demands more efficient tools (languages).

Regards,
Markus

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

Re: [Caml-list] Re: productivity improvement

[Dave Berry]

At 13:43 12/07/2002, Markus Mottl wrote:
>I'd say that depending on the kind of the problem 1:3
>to 1:10 is reasonable and fits well to the experience of others. E.g.,
>the Erlang developers also report productivity gains in this range on
>large-scale commercial projects. OCaml will most likely have similar
>ratios.

I find it unlikely that OCaml would increase productivity as much as
Erlang. Erlang is designed primarily for concurrent programming (I
believe).  When people attempt concurrent programming in C, C++ or Java,
they typically use primitive notions such as threads and locks.  This is
noticeably harder and more error-prone than sequential programming.
Therefore any language that concentrates on this problem has more to gain
than a primarily sequential language.  AFAIK, OCaml uses threads and locks
for concurrent programming, and so is no better in this respect than
conventional languages (it could even be worse, depending on how its GC
interacts with threads and distributed code).

As a commercial manager, I've seen a productivity improvement of about 50%
using Java over C++ -- mainly arising from automatic memory management, and
a slightly cleaner language.  I would expect OCaml to have that 50%, and
perhaps another for a more expressive type system, making 2:1.  For some
problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
comparison, this is also the productivity improvement I'd expect to see
using Visual Basic over C/C++ for small GUI/Database problems.

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

Re: [Caml-list] Re: productivity improvement

[Markus Mottl]

On Sun, 14 Jul 2002, Dave Berry wrote:
> At 13:43 12/07/2002, Markus Mottl wrote:
> >I'd say that depending on the kind of the problem 1:3
> >to 1:10 is reasonable and fits well to the experience of others. E.g.,
> >the Erlang developers also report productivity gains in this range on
> >large-scale commercial projects. OCaml will most likely have similar
> >ratios.
> 
> I find it unlikely that OCaml would increase productivity as much as
> Erlang. Erlang is designed primarily for concurrent programming (I
> believe).  When people attempt concurrent programming in C, C++ or Java,
> they typically use primitive notions such as threads and locks.  This is
> noticeably harder and more error-prone than sequential programming.
> Therefore any language that concentrates on this problem has more to gain
> than a primarily sequential language.

Erlang is very niche-specific (though, fault-tolerant distributed
computation is surely a worthy niche). I think that Erlang would find
it tough to compete against OCaml in most other niches, be it symbolic
or numeric computation, be it in terms of safety or performance-wise.

I am pretty convinced that a ratio of 1:10 in comparison to mainstream
imperative languages for tricky symbolic computation as found in theorem
provers, compilers or also in my field (symbolic machine learning
systems) is not absurd. Note that 1:10 was the upper bound for estimated
productivity gains on my projects over C, 1:3 the lower bound. Other
projects may have other bounds.

> AFAIK, OCaml uses threads and locks for concurrent programming,
> and so is no better in this respect than conventional languages (it
> could even be worse, depending on how its GC interacts with threads
> and distributed code).

I really don't think that OCaml has much to fear here. It's support for
threads is excellent.

> As a commercial manager, I've seen a productivity improvement of about 50%
> using Java over C++ -- mainly arising from automatic memory management, and
> a slightly cleaner language.  I would expect OCaml to have that 50%, and
> perhaps another for a more expressive type system, making 2:1.  For some
> problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
> comparison, this is also the productivity improvement I'd expect to see
> using Visual Basic over C/C++ for small GUI/Database problems.

Visual Basic lives from a wealth of tailor-made libraries and development
tools for such applications. This is "application development" rather
than "programming". It's difficult to estimate productivity gains by
language features as long as libraries/tools do most of the job. You'd
have to be specific about what you actually want to measure.

Anyway, I'd be really surprised if my average productivity gain using
OCaml over Java on arbitrary projects were only 2:1. I am pretty sure
it would be higher than this. Doubling the factor seems quite realistic
to me.

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

Re: [Caml-list] Re: productivity improvement

[Alwyn Goodloe]

  I'm not so sure it's that easy to compare productivity for most apps, no
theorem proving isn't a common app. For most apps written in Java, the
extensive class library accounts for much of the productivity gains over
C/C++.  Think of the difference in writing a simple web server in Java
over C/C++.  All you need to do is pick up the O'Riley Books on network
programming and you are off in a day or two. For most common network
programming you can get away without the details required for Unix
socket/thread programming. This is where O'Caml's library falls short of
Java's. While O'Caml has a good library it's nowhere near as extensive as
Java's.  Let's face it there are alot more people contributing to it and
from my experience the quality is very good.  In O'Caml, the productivity
gains come from the programming style.  If you have to build everything
from scratch or when the libraries are comprable I would bet that O'Caml
usually beats Java.


Alwyn Goodloe
agoodloe@gradient.cis.upenn.edu

On Mon, 15 Jul 2002, Markus Mottl wrote:

> On Sun, 14 Jul 2002, Dave Berry wrote:
> > At 13:43 12/07/2002, Markus Mottl wrote:
> > >I'd say that depending on the kind of the problem 1:3
> > >to 1:10 is reasonable and fits well to the experience of others. E.g.,
> > >the Erlang developers also report productivity gains in this range on
> > >large-scale commercial projects. OCaml will most likely have similar
> > >ratios.
> >
> > I find it unlikely that OCaml would increase productivity as much as
> > Erlang. Erlang is designed primarily for concurrent programming (I
> > believe).  When people attempt concurrent programming in C, C++ or Java,
> > they typically use primitive notions such as threads and locks.  This is
> > noticeably harder and more error-prone than sequential programming.
> > Therefore any language that concentrates on this problem has more to gain
> > than a primarily sequential language.
>
> Erlang is very niche-specific (though, fault-tolerant distributed
> computation is surely a worthy niche). I think that Erlang would find
> it tough to compete against OCaml in most other niches, be it symbolic
> or numeric computation, be it in terms of safety or performance-wise.
>
> I am pretty convinced that a ratio of 1:10 in comparison to mainstream
> imperative languages for tricky symbolic computation as found in theorem
> provers, compilers or also in my field (symbolic machine learning
> systems) is not absurd. Note that 1:10 was the upper bound for estimated
> productivity gains on my projects over C, 1:3 the lower bound. Other
> projects may have other bounds.
>
> > AFAIK, OCaml uses threads and locks for concurrent programming,
> > and so is no better in this respect than conventional languages (it
> > could even be worse, depending on how its GC interacts with threads
> > and distributed code).
>
> I really don't think that OCaml has much to fear here. It's support for
> threads is excellent.
>
> > As a commercial manager, I've seen a productivity improvement of about 50%
> > using Java over C++ -- mainly arising from automatic memory management, and
> > a slightly cleaner language.  I would expect OCaml to have that 50%, and
> > perhaps another for a more expressive type system, making 2:1.  For some
> > problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
> > comparison, this is also the productivity improvement I'd expect to see
> > using Visual Basic over C/C++ for small GUI/Database problems.
>
> Visual Basic lives from a wealth of tailor-made libraries and development
> tools for such applications. This is "application development" rather
> than "programming". It's difficult to estimate productivity gains by
> language features as long as libraries/tools do most of the job. You'd
> have to be specific about what you actually want to measure.
>
> Anyway, I'd be really surprised if my average productivity gain using
> OCaml over Java on arbitrary projects were only 2:1. I am pretty sure
> it would be higher than this. Doubling the factor seems quite realistic
> to me.
>
> 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
>


-------------------
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] Re: productivity improvement

[Dave Berry]

At 00:13 15/07/2002, Markus Mottl wrote:
>Erlang is very niche-specific (though, fault-tolerant distributed
>computation is surely a worthy niche). I think that Erlang would find
>it tough to compete against OCaml in most other niches

That Erlang is niche-specific is exactly my point -- it's a niche that is
ripe for major productivity improvements, and I can believe a factor of
10:1 for Erlang over traditional languages within that niche.

Other niches are less likely to show such gains, IMO -- even theorem
provers and compilers.  A gain of 10:1 means that you could write in 5
weeks using OCaml what it would take you a year to write in C.  I've used
SML and C/C++ to write compilers, and I didn't see anything like that sort
of improvement.  Even if OCaml is more productive than SML, it still seems
unlikely to me to reach a 10:1 improvement, at least for most people.

I really think you should be careful when trumpeting productivity
improvements. People have seen a lot of hype for various technologies, and
are understandably sceptical.  It's best if you can produce actual figures
(this is hard, of course).

>Visual Basic lives from a wealth of tailor-made libraries and development
>tools for such applications. This is "application development" rather
>than "programming". It's difficult to estimate productivity gains by
>language features as long as libraries/tools do most of the job. You'd
>have to be specific about what you actually want to measure.

I don't think it's worthwhile to distinguish between "languages",
"libraries" and "tools", when considering productivity. 

>Anyway, I'd be really surprised if my average productivity gain using
>OCaml over Java on arbitrary projects were only 2:1. I am pretty sure
>it would be higher than this. Doubling the factor seems quite realistic
>to me.

OK, I'll take that on board.

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

Re: [Caml-list] Re: productivity improvement

[Eric Merritt]

--- Dave Berry <daveb@tardis.ed.ac.uk> wrote:
> At 00:13 15/07/2002, Markus Mottl wrote:
> >Erlang is very niche-specific (though,
> fault-tolerant distributed
> >computation is surely a worthy niche). I think that
> Erlang would find
> >it tough to compete against OCaml in most other
> niches
> 
> That Erlang is niche-specific is exactly my point --
> it's a niche that is
> ripe for major productivity improvements, and I can
> believe a factor of
> 10:1 for Erlang over traditional languages within
> that niche.
> 

I would have to disagree with this guys. Erlang is no
more niche specific the Ocaml, C, C++, or any other
general purpose language. Simply becuase it was
created at Ericsson (a telecom company) and its used
primarily in telecom apps at the moment does not make
it a niche language. Now this niche mentioned is
filled very well by Erlang, but Erlang is by no means
limited to that niche. Many people that have never
seen or used Erlang by into this myth but it is simply
not the case. Granted it uses a somewhat diffrent
paradigm then the standard mainstream langauges be
they imperative or functional, but that doesn't make
it a niche langauge by defualt. Using that argument
all functional languages would be niche langauges, for
that matter so would OO languages. 

In any case, Erlang is not a niche langauge.

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
-------------------
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] Re: productivity improvement

[Alessandro Baretta]

Dave Berry wrote:
> At 13:43 12/07/2002, Markus Mottl wrote:
> 
>>I'd say that depending on the kind of the problem 1:3
>>to 1:10 is reasonable and fits well to the experience of others. E.g.,
>>the Erlang developers also report productivity gains in this range on
>>large-scale commercial projects. OCaml will most likely have similar
>>ratios.
> 
> 
> [comments on the use of Erlang for concurrent programming]

 From this standpoint, Erlang would probably yield a higher 
productivity in intrinsically concurrent problems. But a 
good deal of programming is intrinsically "sequential", from 
the point of view of traditional Von Neumann languages, 
"applicative", from the point of functional languages. 
Further, purely functional code (no refs or mutables) has no 
need for mutexes.

> As a commercial manager, I've seen a productivity improvement of about 50%
> using Java over C++ -- mainly arising from automatic memory management, and
> a slightly cleaner language.  I would expect OCaml to have that 50%, and
> perhaps another for a more expressive type system, making 2:1.  For some
> problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
> comparison, this is also the productivity improvement I'd expect to see
> using Visual Basic over C/C++ for small GUI/Database problems.

I respect your opinion, but I do believe that you are not 
considering issues arising from the debugging and 
maintainance of code. In my opinion, developing an 
application from the ground up is a task that might show 
only a marginal improvement of productivity, but in the 
subsequent phase of debugging and maintainance, I expect the 
difference should be much more significant. An overall 3:1 
productivity improvement is not unreasonable.

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] Re: productivity improvement

[Eray Ozkural]

On Sunday 14 July 2002 23:44, Dave Berry wrote:
> As a commercial manager, I've seen a productivity improvement of about 50%
> using Java over C++ -- mainly arising from automatic memory management, and
> a slightly cleaner language.  I would expect OCaml to have that 50%, and
> perhaps another for a more expressive type system, making 2:1.  For some
> problems, e.g. compilers, the increase might be more, say 3:1 or 4:1.  For
> comparison, this is also the productivity improvement I'd expect to see
> using Visual Basic over C/C++ for small GUI/Database problems.

I'd expect a much higher ratio for compilers or any form of symbolic 
computation. Having went through a few C++ compilers recently I would say 
more than 1:10. The problem is that I don't have a C++ compiler written in 
ocaml in front of me, so that's just a guess ;) However, compilers for 
languages with more complex semantics (like Haskell) seems to be achievable 
in the magnitude of a few ten thousands of lines while your casual Mono 
compiler took some 10^6 lines in C if you will remember. That ratio would be 
something like 1:30, 1:40 against C, and I suspect it would still be 1:10 to 
1:20 for C++.

For a C++ compiler, the ratio would be about the same since C++ has simpler 
semantics but a more involved syntax than well designed languages. Hence more 
code for syntax, less code for semantics in the case of C++ probably making 
the compiler as complex as Haskell.

That ratio would wildly change with respect to design of the compiler of 
course. There are lots of choices even in the simplest matters. Not to 
mention the need for a good programmer. A bad programmer can eventually
manage to blow up the code size worse than a good C++ implementation ;)

Just a rough comparison,

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] Re: productivity improvement

[Dave Berry]

At 11:38 15/10/2002, Eray Ozkural wrote:
>your casual Mono 
>compiler took some 10^6 lines in C if you will remember. That ratio would be 
>something like 1:30, 1:40 against C, and I suspect it would still be 1:10 to 
>1:20 for C++.

Microsoft's SSCLI distribution, which is freely downloadable, includes a
fast industrial-strength C# to .NET compiler. This is written in less than
100,000 lines of C++.  By your reckoning, you should be able to write an
equivalent compiler in 5,000 lines of O'Caml.  Are you willing to produce
an example compiler to substantiate your claim?

>For a C++ compiler, the ratio would be about the same since C++ has simpler 
>semantics but a more involved syntax than well designed languages.

I'm staggered at your suggestion that C++ has a simple semantics.  To me, a
major advantage of the ML family is that their semantics is relatively simple.

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

Re: [Caml-list] Re: productivity improvement

[Eray Ozkural]

On Friday 18 October 2002 00:27, Dave Berry wrote:
> >For a C++ compiler, the ratio would be about the same since C++ has
> > simpler semantics but a more involved syntax than well designed
> > languages.
>
> I'm staggered at your suggestion that C++ has a simple semantics.  To me, a
> major advantage of the ML family is that their semantics is relatively
> simple.
>

C++ has a less sophisticated and mathematically lacking semantics devoid of 
generality compared to ML family, especially modern incarnations such as 
ocaml.

The hard part of writing a C++ compiler is coping with several syntactic 
ambiguities and incoherent semantics (such as in templates and type system) 
rather than realizing a well defined and expressive semantics.

Where in C++ is orthogonality, reliability, parametrized/recursive  types, 
parametrized modules, etc.? I'm staggered at you claiming more than C++ 
deserves. Where C++ ought to be strongest, OOP, ocaml is much more general 
and complete. In other design objectives ocaml beats C++ by a good measure. 
No derivative of C can be a really good programming language design and C++ 
is not an exception.

It isn't just a coincidence that programming language research focuses on 
functional languages a la ML.

And that the industry uses largely C++ has nothing to do with semantics. I 
think it is clear why the industry prefers one language over another; it is 
collective stupidity.

As a side note, once you get past the parsing stage it should be relatively 
easy to implement an optimizing C++ or C# compiler. I've been working on a 
C++ parser, but the syntax is so hard it's almost impossible to implement 
everything and verify that it really works. (Another indication that the 
design sucks) The syntactic analyzer itself could take a couple of thousands 
of lines. All in all it would still take 10000 or more lines. I would 
estimate somewhere about 10000-20000 lines for a C++ compiler. A C# compiler 
could be made smaller.

If we had a good C++ parser written in ocaml or haskell we could proceed to a 
full compiler very fast. It just hasn't been done before.

I can put forward a challenge in front of you and I think you would be much 
more helpless than I am about writing a C++ compiler from scratch -- which is 
no easy undertaking whatever the implementation language is. What about 
writing a full-fledged ocaml or haskell compiler in C++? I am pretty sure 
that would be an overwhelming task, something which would require more than 
100.000 lines of C++ code.

I intend to release a version of my parser when it is able to parse KDE 
headers. Maybe then people experienced in C++ parsers can work on a 
full-fledged compiler. I'm writing a top-down parser like in the recent 
versions of g++ using haskell Parsec library.

Thanks,

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] Re: productivity improvement

[Dave Berry]

Eray, I think you misunderstand where I'm coming from.  I would love to see
more people using ML instead of C++.  I was part of a team that produced
one of the commercial SML compilers. All three commercial SML compilers
have failed, partly because it's very difficult to persuade people to
switch.  People aren't stupid, and they won't switch to a new language
without some compelling evidence that it gives an advantage.  I believe
that a 2:1 or 3:1 gain in a meaningful measure -- the best measure being
overall cost -- would be sufficient to persuade a reasonable number of
people to switch.  But, we need concrete evidence.  This is hard to obtain,
because few people have the time to write a project twice, using different
languages.  What's more, when studies of this sort have been done,
comparing more conventional languages, the results have shown that the
choice of language makes little difference to the overall cost of the
project.  So there's a widespread suspicion of claims that language X or Y
increases productivity by significant amounts.

In this context, figures plucked from the air are, at best, not helpful; I
think they're actually counter-productive.  To an extent, the bigger the
claims, the more counter-productive they are, because they're easier to
challenge.  I would rather have one verifiable claim of a 3:1 productivity
improvement -- which is a pretty big win -- than a hundred unverifiable
claims of 10:1, 20:1 or even 40:1 gains.  (Given earlier postings on this
thread, it's worth reiterating that the type of program is also vital --
e.g. figures for a one-week project may not scale to a ten-year project).

This thread gave one very useful example: the rewrite of Ensemble.  IIRC,
this gave a 7:1 gain in LoC over the original C version.  Even if one
allows for the benefit of writing the program a second time, and for the
fact that LoC doesn't necessarily correlate directly to development time,
this is still an impressive figure.

Way back when this thread started, I quoted another example: Andrew Appel's
Tiger compiler.  This has three versions, one in C, one in Java, and one in
SML.  The SML is shorter, but not to such a great extent.  (I need to
recheck the actual figures).

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

Re: [Caml-list] Re: productivity improvement

[Michael Vanier]

Dave,

I agree with your comments.  I think it's very important that we (ocaml
fans) avoid becoming dogmatic.  I think most of us would agree that we
would rather code in ocaml than in just about any other language.  That
said, the choice of problem is going to make a world of difference in
whether ocaml is really the language of choice.  Some problems are just
going to be more easily solved (or produce better results) in other
languages, and we just have to accept this.  No one tool is perfect for all
tasks.  For instance, trying to use ocaml in domains where C or Fortran
rule (heavy numerical computing on simple data structures) is interesting
but probably doomed to produce inferior results in many cases (unless you
use ocaml as a fancy compiler or partial evaluator that spits out C code,
that is ;-)).  As the ocaml developers have pointed out, when the data
structures become very intricate, then ocaml starts to win in a big way.

As for popularity, I feel that the grassroots approach is best.  Pass the
word about ocaml on to the ten best hackers you know, try to get them
hooked on the language, use it to tackle problems that would be absurdly
hard in other languages (not ones that can be done well in any language),
and publicize your results.  This will work, although it won't work
overnight.  I've already noticed that more and more courses in CS
departments are using ocaml because of its flexibility; this by itself is
going to introduce ocaml to a large number of new students, many of whom
will spread the word to others.

Mike

> Date: Sun, 20 Oct 2002 13:46:47 +0100
> From: Dave Berry <daveb@tardis.ed.ac.uk>
> 
> Eray, I think you misunderstand where I'm coming from.  I would love to see
> more people using ML instead of C++.  I was part of a team that produced
> one of the commercial SML compilers. All three commercial SML compilers
> have failed, partly because it's very difficult to persuade people to
> switch.  People aren't stupid, and they won't switch to a new language
> without some compelling evidence that it gives an advantage.  I believe
> that a 2:1 or 3:1 gain in a meaningful measure -- the best measure being
> overall cost -- would be sufficient to persuade a reasonable number of
> people to switch.  But, we need concrete evidence.  This is hard to obtain,
> because few people have the time to write a project twice, using different
> languages.  What's more, when studies of this sort have been done,
> comparing more conventional languages, the results have shown that the
> choice of language makes little difference to the overall cost of the
> project.  So there's a widespread suspicion of claims that language X or Y
> increases productivity by significant amounts.
> 
> In this context, figures plucked from the air are, at best, not helpful; I
> think they're actually counter-productive.  To an extent, the bigger the
> claims, the more counter-productive they are, because they're easier to
> challenge.  I would rather have one verifiable claim of a 3:1 productivity
> improvement -- which is a pretty big win -- than a hundred unverifiable
> claims of 10:1, 20:1 or even 40:1 gains.  (Given earlier postings on this
> thread, it's worth reiterating that the type of program is also vital --
> e.g. figures for a one-week project may not scale to a ten-year project).
> 
> This thread gave one very useful example: the rewrite of Ensemble.  IIRC,
> this gave a 7:1 gain in LoC over the original C version.  Even if one
> allows for the benefit of writing the program a second time, and for the
> fact that LoC doesn't necessarily correlate directly to development time,
> this is still an impressive figure.
> 
> Way back when this thread started, I quoted another example: Andrew Appel's
> Tiger compiler.  This has three versions, one in C, one in Java, and one in
> SML.  The SML is shorter, but not to such a great extent.  (I need to
> recheck the actual figures).
> 
> 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
> 
-------------------
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] Re: productivity improvement

[Eray Ozkural]

Oleg is probably going to get mad at such delays in a follow-up but 
nonetheless I have had very little time to write anything intelligible 
because of my unfortunate phd studies.  I am trying to catch up with some 
mails that I've neglected at the time.

For recall, Dave said that a measurable 2 or 3-fold improvement in code size 
could convince people to switch to ML.

On Sunday 20 October 2002 15:46, Dave Berry wrote:
> Way back when this thread started, I quoted another example: Andrew Appel's
> Tiger compiler.  This has three versions, one in C, one in Java, and one in
> SML.  The SML is shorter, but not to such a great extent.  (I need to
> recheck the actual figures).

What I would guess is that a C++ compiler implemented in Ocaml would improve 
code size considerably over one written in C. Even over those in C++, which 
seems to be the language of choice for efficient code nowadays. I have looked 
at some of the open source C++ compilers to see how the code organization was 
and I think that a C++ compiler does have the right amount of complexity to 
demonstrate our point about productivity.

I myself tried to go at some length previous summer by writing a combinatorial 
C++ parser with Parsec in Haskell. As you will guess, I quickly ran into a 
few hard resolution problems and then although I realized there was a nice 
LL(1) grammar that I could use, I didn't have enough time for the project (as 
you could also guess)

If somebody gets interested, I will try to clean up the parser and have it 
actually parse a subset of C++ so that we can begin some development on it. 
Then, if somebody pleases, it shouldn't be impossible to translate the code 
to ocaml or other functional languages. 

The reason I used Haskell was that I thought it would be interesting to see 
the pipeline effect of lazy monadic code in something like (pseudocode!)

do
    t <- parseProgram prog1;
    s <- semanticAnalyzer t;
    pr <- generatePR s;
    opr <- optimizePR pr;
    generateCode opr

I haven't really looked at any real compilers written in Haskell but I would 
think they use a fair amount of monadic functions.

But first I must program more data structures!!

Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
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] Re: productivity improvement

[Noel Welsh]

--- Markus Mottl <markus@oefai.at> wrote:
> I'd get into very serious troubles when my
> main programmer gets a brick on his head. 

Markus, you write as a brick to the head is a foregone
conclusion.  Is this how functional programmers are
treated in Austria?  ;-)

Seriously, Markus is right: many business decisions
are based on fear.  This is sad and leads to the kind
of lossage that Paul Graham has been writing about in
his recent essays.  It's up to small companies to gain
the advantages of innovative technology.

Noel

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
-------------------
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] Re: productivity improvement

[Markus Mottl]

On Fri, 12 Jul 2002, Noel Welsh wrote:
> --- Markus Mottl <markus@oefai.at> wrote:
> > I'd get into very serious troubles when my
> > main programmer gets a brick on his head. 
> 
> Markus, you write as a brick to the head is a foregone
> conclusion.  Is this how functional programmers are
> treated in Austria?  ;-)

Well, you never know how laid off project managers retaliate here ;-)

> Seriously, Markus is right: many business decisions
> are based on fear.  This is sad and leads to the kind
> of lossage that Paul Graham has been writing about in
> his recent essays.  It's up to small companies to gain
> the advantages of innovative technology.

It is possible to disperse risk when you happen to live in a country with
a well-developed market for venture capital. This, however, is not the
case here. At least in this respect you can be lucky to live in the UK.
OTOH, food and weather is so much better over here :-)

Regards,
Markus

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

Re: [Caml-list] Re: productivity improvement

[John Max Skaller]

Oleg wrote:

>Looking at Halo [1] credits, one can see that it was developed by about 10 
>programmers (there were also testers and artists involved). A single O'Caml 
>programmer capable of developing such a game alone should certainly stand to 
>make tons of money. Then why don't we see much software written in O'Caml?
>
>I'm not buying the argument that "O'Caml isn't used in the industry because 
>investors and project managers are stupid". 
>
Two major reasons.

    (1) licence uncertainty
    (2) lack of programmers

Issue (2) will go away with time as use snowballs,
it would help if Universities started teaching Ocaml instead
of stupid OO languages like Java, or at least as well as.

Lack of bindings to C libraries is also an obstacle, but I'd roll that
up into issue (2).

It would be really useful if all the run time parts of Ocaml were given
a simple no bull licence such as 'free for any use' so it was quite clear
that generated code was OWNED by the entity that owned
the inputs.

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




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

Re: [Caml-list] Re: productivity improvement

[Alan Schmitt]

* John Max Skaller (skaller@ozemail.com.au) wrote:
> It would be really useful if all the run time parts of Ocaml were given
> a simple no bull licence such as 'free for any use' so it was quite clear
> that generated code was OWNED by the entity that owned
> the inputs.

I just took a look at the license, and it says you can distribute
executables of your programs as you wish, even if they contain part of
the libraries of caml by linking. So I'm not sure I follow what you mean
here ...

Alan

-- 
The hacker: someone who figured things out and made something cool happen.
-------------------
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] Re: productivity improvement

[John Carr]

> >Looking at Halo [1] credits, one can see that it was developed by about 10 
> >programmers (there were also testers and artists involved). A single O'Caml 
> >programmer capable of developing such a game alone should certainly stand to
> >make tons of money. Then why don't we see much software written in O'Caml?
> >
> >I'm not buying the argument that "O'Caml isn't used in the industry because 
> >investors and project managers are stupid". 
> >
> Two major reasons.
> 
>     (1) licence uncertainty
>     (2) lack of programmers
> 


As a new OCaml programmer let me describe the other barriers to entry:
    (3) programming style
    (4) development environment
    (5) grammar, semicolons, and other quirks

(3) programming style

This is related to (2).

Leaving out classroom use, the majority of the target audience for a
general purpose language consists of C/C++ programmers.  (Some are
recent CS graduates -- see below -- and maybe Microsoft Visual-whatever
drones should be counted as a separate category.)

At my last job we switched from C++ to Java.  We had a few experienced
Java programmers and an MIT professer with her new Java textbook.  Two
weeks were sufficient to learn the new language sufficiently well to
start writing real code.  Java is designed to look like C with classes
and garbage collection.  As a result, it is easy to find or create
Java programmers.

OCaml is not related to C.  It doesn't look like C (see below) and it
doesn't work like C.  The object oriented features are harder to learn
than those in C++.  Moving from C to a functional language is not
natural.  Retraining software engineers will take longer and some will
not be able to make the transition.

Recent CS graduates may do better than established C programmers.
They should have had recent experience with functional languages.
(I hear many students have trouble with "lambda" in introductory
CS courses.  I assume those who graduate understand.)  However,
few students will come out of school knowing OCaml.

This is a fundamental barrier and managers are right to be wary.


I did use a non-mainstream language once in a commercial software
product.  I wrote the test suite for my program in Scheme.  This
was feasible because the group was very small and my boss liked
Scheme.  For the particular application it was a good choice.


(4) development environment

I wanted to compile the HTTP client tool from one of the ocaml web
sites.  Doing this required finding, compiling, and installing three
or four other ocaml libraries plus a C library which I had to search
elsewhere for.

The core language -- the tarball from the OCaml web site -- is well
packaged and seems reliable, but the surrounding chaos feels more like
a hacker project than a solid development platform.  A developer using
C on a Unix system has more software in a standard installation.

(Is it possible to do Java-style hierarchical naming or C++ namespaces
in OCaml?  One of these is probably essential in the long run.)


(5) quirks

If OCaml is to be taken seriously it needs a compiler with better
error messages.  I remember switching 15 years ago from pcc (the
"Portable C Compiler" that came with BSD 4.2) to Metaware High C and
gcc.  pcc emitted a single unhelpful error message followed by a
cascade of secondary messages.  The newer compilers generated helpful
error messages and had error recovery so any later messages were
likely to be related to further code errors.  My productivity
substantially increased as I was able to understand what errors meant
and fix more than one error per edit-compile cycle.

ocamlc is like pcc, but without the cascading errors.

A tool like "lint", that parses a file and looks for problems, might
be adequate for this purpose.  The ideal solution would be two
independent language implementations.

The use of semicolon as an optional statement separator rather than a
mandatory statement terminator causes a lot of extra work for me.  I
understand the C rules about where a statement begins and ends.  The
OCaml rules are confusing and I often must resort to trial and error
to resolve compilation errors.  I want to know WHY the compiler thinks
my exception handler expression should have type unit.  It should tell
me "the inferred type for the value expression of the try clause at
line 120 (unit) does not match the inferred type for the value
expression of the with clause at line 130 (string)".

The lack of operator overloading makes the transition from C to OCaml
harder.  (I understand why type inference and overloading are
difficult to reconcile, but the omission is still annoying.)



Having said all that, my personal goal for this summer is to learn
a new language and write a useful program in it.  I chose OCaml and
I will reserve judgement until I have completed that task, or failed.


    --John Carr (jfc@mit.edu)
-------------------
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] Re: productivity improvementu

[Pierre Weis]

--John Carr (jfc@mit.edu) wrote

> As a new OCaml programmer let me describe the other barriers to entry:
>     (3) programming style
>     (4) development environment
>     (5) grammar, semicolons, and other quirks

I would suggest you start by reading the programming guide lines for
Objective Caml, that precisely adress 3 and 5.

http://pauillac.inria.fr/caml/FAQ/pgl-eng.html 

Also the ``grammar quick reference guide'' can be useful.

http://pauillac.inria.fr/caml/FAQ/qrg-eng.html 

Regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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] Re: productivity improvement

[Brian Smith]

John Max Skaller wrote:
> Lack of bindings to C libraries is also an obstacle, but I'd roll that
> up into issue (2).

I hope I can offer some insight into this. I am a student at the 
University of Iowa in the U.S. I will say that I think that O'Caml is 
very interesting and I enjoy learning it. But, everything seems to be 
Java or VB over here, both at school and in the job market. So, that 
means I will seemingly forever be using O'Caml only in my free time.

Also, Java has the focus of so many open-source developers and 
open-source users. If I write my software in O'Caml, I worry that nobody 
will be interested in it because it isn't Java. And, contributions to 
other projects won't be accepted because they are not Java. And, it is 
an odd feeling to write code that seemingly nobody will ever use.

Finally, there is the user interface issue. I haven't seen any TCL/TK 
applications that have "good" user interfaces running on Windows or Mac 
OS. I want my applications to look like Windows applications on Windows 
and Mac applications on Mac. And, I don't want to learn a Windows GUI 
API and a Macintosh GUI API. TCL/TK does not provide this. But, Java 
_does_ do this, in a "mostly good enough" way that is always improving.

So, I think that, if people are interested in seeing O'Caml have more 
widespread use, at least in the short term there needs to be better 
interoperability between Java and O'Caml. In particular, it should be 
easy for me to write a user interface in Java and write my "business 
logic" in O'Caml. In general, it should not require a lot of work to 
reuse an existing Java library (there are so many). Currently, these 
things are not easy. Xavier's JNI bindings seem like they might help, 
but there needs to be something "above" those bindings. And, there needs 
to be some example application that makes use of these bindings. If 
these things are provided then O'Caml won't seem so much like its own 
far-off world to Java programmers.

Here is an example of what I would like to do with O'Caml: I would like 
to take a software model (described using UML or some other modeling 
languages) and transform that model into various other languages. For 
example, convert a UML package of classes into an O'Caml module of 
classes. Or, perhaps take a set of Java interfaces and make a set of 
O'Caml bindings for those interfaces. And, I want to integrate this tool 
with the NetBeans IDE which is written in Java.

Regarding syntax: It seems perhaps the O'Caml syntax is designed to be 
easy for the O'Caml parser to parse, instead of being easy for me to 
figure out. But, it would be nice if at least the object-oriented syntax 
could reduce the amount of punctuation needed, and also be a little more 
consistent within itself and the rest of the language. Also, it would be 
nice to have better support for recursive types/classes/exceptions so 
that introducing spurious type variables isn't needed. I would rather 
reserve type variables for use only when I want polymorphism.

Just my US$.02 (worth a whole US$.02 but look at our prescription drug 
prices!)

- 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] Re: productivity improvement

[Eray Ozkural]

On Friday 12 July 2002 16:44, John Max Skaller wrote:
> Two major reasons.
>
>     (1) licence uncertainty
>     (2) lack of programmers
>
> Issue (2) will go away with time as use snowballs,
> it would help if Universities started teaching Ocaml instead
> of stupid OO languages like Java, or at least as well as.

Indeed. The industry wants OO, the industry thinks Java is the
ultimate OO language, they persuade clueless academics (who might as well 
think that choice of PL is irrelevant to understanding the theory), and
then they start teaching Java (and now C#) at the university.

The problem is that OO is *not* the best approach to programming.
OO is a kind of program conceptualization that might be of some
use in certain domains while failing miserably in majority of domains. That's 
why most of the "OO" code is iteration constructs and imperative nonsense, 
over and over again. I once told a colleague that 90% percent of the code we 
are writing in C++ is iterators. Nothing in the world could be more stupid 
than that.

Besides, C does not hold the crown of imperative languages, especially when it 
comes to demonstrating the basics of programming. Pascal does a much better 
job at that in my opinion, and Algol might even do better but nobody 
comprehends its prominence among imperative languages.

It is so amusing when "Software Engineers" find out that the overblown UML 
can't be used to model every kind of program.

Happy hacking,

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] eproductivity improvement

[Alessandro Baretta]

Eray Ozkural wrote:
> On Friday 12 July 2002 16:44, John Max Skaller wrote:
> 
>>Two major reasons.
>>
>>    (1) licence uncertainty
>>    (2) lack of programmers
>>
>>Issue (2) will go away with time as use snowballs,
>>it would help if Universities started teaching Ocaml instead
>>of stupid OO languages like Java, or at least as well as.
> 
> 
> Indeed. The industry wants OO, the industry thinks Java is the
> ultimate OO language, they persuade clueless academics (who might as well 
> think that choice of PL is irrelevant to understanding the theory), and
> then they start teaching Java (and now C#) at the university.

"God is dead!" cried Zarathustra. I don't know about that, 
really, but I can tell you that "Culture is very ill!"

I have just been told that the Politecnico di Milano, 
acknowledging the industry's need for new class of 
engineers--more obtuse, acritical, and, overall, 
cheap--intends to swap the traditional Software Engineering 
course with the more modern, obtuse, and cheap "Software 
Engineering in Java". I feel *so* proud that my university 
should be *so* modern. Wow.

Vive la France! Vive l'X! Et surtout, vive le Caml!

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

[Caml-list] productivity improvement

[Basile STARYNKEVITCH]

>>>>> "Oleg" == Oleg  <oleg_inconnu@myrealbox.com> writes:


    Oleg> What are the _simplest_ examples that demonstrate
    Oleg> considerable (> 2:1) O'Caml vs C++ productivity improvement
    Oleg> (in terms of program size) and where can I find them?

I am not sure the question does make any real sense. You might ask an
Ocaml vs Java comparaison, or an Ocaml vs Python compraison ....

1. Try coding the Ocaml compiler, the ActiveDVI viewer, the Unison
   synchronizer, or the Coq proof system, ... in C++, then tell us
   about your findings. If possible, publish your working C++ code :-)

2. The simplest example I can think of is the hello world program. In
   Ocaml it is just a single line:
      print_endline "hello world";;

   but in C++ you'll need at least an #include, then a main function,
   containing a out << "hello world" << endl statement perhaps a
   simplest even example is the empty program: (a 0 byte file in
   Ocaml, but in C++ you need a main function. the size improvement is
   infinite in favor of Ocaml)


Ok, my answer is silly, but I feel the question a bit silly too. More
convincing examples are the many existing (and publicised) code in
Ocaml. See the ocaml hump for instance, and more generally try ocaml
in a Web search engine. Also the Oreilly book (originally in French,
but translated in english) on Ocaml will help. There are lots of stuff
from http://www.ocaml.org/ too.

Both Ocaml and C++ requires a significant learning effort, however
(you might compare the volume of the language reference manuals; the
core language of C++ is much heavier than the core language of
Ocaml). Try coding some stuff in Ocaml and you will learn by
yourself. The type inference system is really a big plus.

Ocaml does have some minor weaknesses: the syntax is sometimes painful
(you could look into the Revised syntax proposal of D.deRanglaudre in
camlp4); mixing datatypes (eg records) and classes is painful; there
are much less libraries in Ocaml than in C or C++; metaprogramming is
not really easy; runtime information is almost inexistant; Ocaml has
no overloading, etc...

The real convincing examples would be projects which failed in C++ but
were resurrected and worked in Ocaml (I heard there are some such
projects but I cannot name them) but I am not sure you'll find public
references to failed projects.


N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

---------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique * France
DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX 
phone:+33 1,6908.6055; fax: 1,6908.8395 home: 1,4665.4553; mobile: 6,8501.2359
work email: Basile point Starynkevitch at cea point fr 
home email: Basile at Starynkevitch point 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] productivity improvement

[Shannon --jj Behrens]

>     Oleg> What are the _simplest_ examples that
> demonstrate
>     Oleg> considerable (> 2:1) O'Caml vs C++
> productivity improvement
>     Oleg> (in terms of program size) and where can I
> find them?

I wrote a bunch of programs comparing several
languages using two different algorithms ("Simple" and
"Modcount") for finding primes.  Eventually, I hope to
throw these up on a Web page, but here is a summary of
the results:

Simple:
  C:
    Source: 76 lines
    Binary: 5833 bytes
    Sample Run: 1.56 seconds
  Cyclone:
    Source: 63 lines
    Binary: 127264 bytes
    Sample Run: 1.63 seconds
  Ocaml:
    Source: 35 lines
    Binary: 138726 bytes
    Sample Run: 3.57 seconds
  Python:
    Source: 28 lines
    Binary: 1629 bytes
    Sample Run: 13.6 seconds

ModCount:
  C:
    Source: 95 lines
    Binary: 6020 bytes
    Sample Run: 1.08 seconds
  Cyclone:
    Source: 83 lines
    Binary: 127391 bytes
    Sample Run: 1.35 seconds
  Ocaml:
    Source: 54 lines
    Binary: 139091 bytes
    Sample Run: 3.66 seconds
  Python:
    Source: 44 lines
    Binary: 4054 bytes
    Sample Run: 91.8 seconds

Line counts do not include blank lines or comments.
Sample runs were calculated using "time ./executable
5000".  Ocaml programs where compiled using the native
compiler.  Python binary sizes were taken from .pyo's
which still require the Python interpretter.  My
friend did a Java version.  It required more lines of
code that OCAML, and was slightly slower.  I don't
have the exact numbers, so I haven't written them
here. :(

Here are some of the things that I learned:

1) C is the fastest (of course).
2) Python requires the fewest lines of code.
3) Ocaml provides (in my mind) the best ratio of
execution speed per lines of code.
4) I don't agree that having a higher level language
will often result in using better algorithms, which
compensate for the language overhead.

I have the code of the programs, if you wish.

Best Regards,
-jj

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
-------------------
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] productivity improvement

[Oleg]

On Tuesday 09 July 2002 02:20 pm, Shannon --jj Behrens wrote:

> I wrote a bunch of programs comparing several
> languages using two different algorithms ("Simple" and
> "Modcount") for finding primes.  Eventually, I hope to
> throw these up on a Web page, but here is a summary of
> the results:
>
> Simple:
>   C:
>     Source: 76 lines
>     Binary: 5833 bytes
>     Sample Run: 1.56 seconds
>   Cyclone:
>     Source: 63 lines
>     Binary: 127264 bytes
>     Sample Run: 1.63 seconds
>   Ocaml:
>     Source: 35 lines
>     Binary: 138726 bytes
>     Sample Run: 3.57 seconds
>   Python:
>     Source: 28 lines
>     Binary: 1629 bytes
>     Sample Run: 13.6 seconds
>
> ModCount:
>   C:
>     Source: 95 lines
>     Binary: 6020 bytes
>     Sample Run: 1.08 seconds
>   Cyclone:
>     Source: 83 lines
>     Binary: 127391 bytes
>     Sample Run: 1.35 seconds
>   Ocaml:
>     Source: 54 lines
>     Binary: 139091 bytes
>     Sample Run: 3.66 seconds
>   Python:
>     Source: 44 lines
>     Binary: 4054 bytes
>     Sample Run: 91.8 seconds
>
> Line counts do not include blank lines or comments.

Hi

I intensionally used "program size" and not LOC, because C/C++ programmers 
like to use short lines and very short lines (containing a single "{" or 
"}"). How do the program sizes compare in terms of the number of non-blank 
characters, for example? [1]

Thanks

Oleg
[1] cat source | sed "s/ //" | wc -c
-------------------
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] productivity improvement

[Shannon --jj Behrens]

> Hi
> 
> I intensionally used "program size" and not LOC,
> because C/C++ programmers 
> like to use short lines and very short lines
> (containing a single "{" or 
> "}"). How do the program sizes compare in terms of
> the number of non-blank 
> characters, for example? [1]
> 
> Thanks
> 
> Oleg
> [1] cat source | sed "s/ //" | wc -c

Hmm, that's not really a reasonable comparison,
because even the commenting style will mess it up. 
I'll post the code, and you can compare.  If anyone
has any comments on my usage (or lack thereof) of
OCAML idioms, I'd be quite happy to hear them:

<http://ironorchid.com/jjinux/patches/findprimes.tar.gz>

Best Regards,
-jj

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
-------------------
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] productivity improvement

[sebastien FURIC]

 Hello,

 I've tested your O'Caml program on my PC:

time ./findprimes_modcount 10000

real    1m26.089s
user    0m0.010s
sys     0m0.040s

 To my surprise, this naive lazy version in Clean (5 lines of code!)
outperforms your version:

<clean>

   module sieve

   import StdEnv

   primes =: sieve [2, 3 ..]
   where sieve [p : xs] = [p : sieve [x \\ x <- xs | x mod p <> 0]]

   Start = take 10000 primes

</clean>

time ./sieve

real    1m17.460s
user    0m0.010s
sys     0m0.020s

 The corresponding version in O'Caml (using a lazy list module) is far
from being as efficient:

<caml>

   type 'a stream = Empty | Cons of 'a * 'a stream Lazy.t

   let rec iter f = function
       | Empty -> ()
       | Cons (x, xs) -> f x; iter f (Lazy.force xs)

   let rec filter p = function
       | Empty -> Empty
       | Cons (x, xs) ->
           if (p x) then Cons (x, lazy (filter p (Lazy.force xs))) else
filter p (Lazy.force xs)

   let rec take n s = match (n, s) with
       | _, Empty -> Empty
       | 0, _ -> Empty
       | n, Cons (x, xs) -> Cons (x, lazy (take (n - 1) (Lazy.force
xs)))


   let rec from n = Cons (n, lazy (from (n + 1)))

   let print_int_stream = iter (function x -> print_int x; print_string
"; ")

   let primes =
       let rec sieve = function
           | Empty -> Empty
           | Cons (p, xs) -> Cons (p, lazy (sieve (filter (function n ->
n mod p <> 0) (Lazy.force xs))))
       in sieve (from 2);;

   print_int_stream (take 10000 primes)

</caml>

real    11m9.021s
user    0m0.020s
sys     0m0.030s

 Sebastien.
-------------------
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] productivity improvement

[Dave Mason]

Further to my comment on benchmarking...

I just ran your ocaml lazy version, and got:

real	14m15.124s
user	13m26.769s
sys	0m2.510s

This on a 533MHz Alpha with 3/4GB of RAM.  There is no swapping.

Even when I compile it with the optimizing compiler, I get:

real	9m8.763s
user	8m51.626s
sys	0m1.667s

Based on the (small) differences between the byte-code version and the
optimized version, I hypothesize that a large amount of that time is spent
in garbage collection.  This looks like a perfect garbage-collector
stress test!

My guess for why Clean does well suggests a garbage collector better
tuned to the problem, but more importantly, a much more efficient
handling of laziness.  I suspect you'd see similar results for this
problem in Haskell.  Of course that doesn't mean Clean or Haskell will
beat OCaml at most, or even many, other benchmarks.  But when laziness
is inherent in a solution, expect lazy languages to do much better
than eager languages.

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

Re: [Caml-list] productivity improvement

[sebastien FURIC]

Dave Mason a écrit :
> 
> Further to my comment on benchmarking...
> 
> I just ran your ocaml lazy version, and got:
> 
> real    14m15.124s
> user    13m26.769s
> sys     0m2.510s
> 
> This on a 533MHz Alpha with 3/4GB of RAM.  There is no swapping.
> 
> Even when I compile it with the optimizing compiler, I get:
> 
> real    9m8.763s
> user    8m51.626s
> sys     0m1.667s
> 
> Based on the (small) differences between the byte-code version and the
> optimized version, I hypothesize that a large amount of that time is spent
> in garbage collection.  This looks like a perfect garbage-collector
> stress test!
> 
> My guess for why Clean does well suggests a garbage collector better
> tuned to the problem, but more importantly, a much more efficient
> handling of laziness.  I suspect you'd see similar results for this
> problem in Haskell.  Of course that doesn't mean Clean or Haskell will
> beat OCaml at most, or even many, other benchmarks.  But when laziness
> is inherent in a solution, expect lazy languages to do much better
> than eager languages.
> 
> ../Dave

 Dave,

 My strange user times are obtained under Cygwin. I forgot to mention I
did the test under Windows NT 4.0 (Intel 200 MHz, 128 MB RAM) using the
last version of Cygwin (hence the last version of time.exe!) and
Objective Caml 3.04. There was no swapping, so sys time is a good
approximation of the time spent by the program to solve the problem.
 It is not very surprising to beat O'Caml using a language that is tuned
to perform lazy computations natively when the problem to solve is lazy!
 More surprising is the fact that the lazy program outperforms a strict
one (written in an imperative style).

 Cheers,

 Sebastien.
-------------------
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] productivity improvement

[nadji]

sebastien FURIC wrote:

> Dave Mason a écrit :
> >
> > Further to my comment on benchmarking...
> >
> > I just ran your ocaml lazy version, and got:
> >
> > real    14m15.124s
> > user    13m26.769s
> > sys     0m2.510s
> >
>

...

> > in garbage collection.  This looks like a perfect garbage-collector
> > stress test!
>

I did some tests and it seems a lot of time is being spent on garbage collection.

> >
> > My guess for why Clean does well suggests a garbage collector better
> > tuned to the problem, but more importantly, a much more efficient
> > handling of laziness.  I suspect you'd see similar results for this
> > problem in Haskell.  Of course that doesn't mean Clean or Haskell will
> > beat OCaml at most, or even many, other benchmarks.  But when laziness
> > is inherent in a solution, expect lazy languages to do much better
> > than eager languages.
> >

... with a lazy style of programming. I ran your test with my computer, and it
took
it around 5mn to complete. I programmed the same test in a functional way
(and with DDR's syntactic sugar), and it now completes in 21s. Moreover,
the program is nearly as short as your Clean one. See below.

>  It is not very surprising to beat O'Caml using a language that is tuned
> to perform lazy computations natively when the problem to solve is lazy!

I don't agree with you when you say that the problem to solve is lazy. The
_algorithm_ you use is lazy. There are certainly lots of ways to solve it
with imperative style, and lots of optimisations (I think of multiprocessor
ones) that you can't implement with your algorithm.


file erat.ml :
(* defines 2 streams : the first one is the functional that I have written,
and the second is Sébastien Furic's one *)
let primes1 =
  let rec erat isprime n =
    if isprime n then [< 'n; erat (fun k -> isprime k && k mod n <> 0) (n + 1) >]

    else erat isprime (n + 1)
  in erat (fun _ -> true) 2

let primes2 =
  let rec filter f = parser
      [< 'n; xs >] -> if f n then [< 'n; filter f xs >] else filter f xs
  in let rec sieve = parser
      [< 'p; xs >] -> [< 'p; sieve (filter (fun x -> x mod p <> 0) xs) >]
  in let rec from k = [< 'k; from (k + 1) >]
  in sieve (from 2)

let _ =
  let primes = match Sys.argv.(1) with "1" -> primes1 | "2" -> primes2
  | _ -> failwith "syntax: erat (1|2) n" in
  let rec print_stream = function
    | 0 -> Printf.printf "\n"
    | n -> Printf.printf "%d " (Stream.next primes); print_stream (n - 1)
  in print_stream (int_of_string (Sys.argv.(2)))

compile it with :
    ocamlopt -o erat -pp camlp4o erat.ml
on my computer,
    time ./erat 1 10000 ->  0:21.74
    time ./erat 2 10000 -> 5:15.87

Cheers,
Nadji

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

Sieve of Eratosthenes Performance: various languages (Re: [Caml-list] productivity improvement)

[Oleg]

On Wednesday 10 July 2002 06:02 am, sebastien FURIC wrote:

<snip>

> </caml>
>
> real    11m9.021s
> user    0m0.020s
> sys     0m0.030s
>
>  Sebastien.

I guess this is an example of when very idiomatic C++ shines:

    1   #include <iostream>
    2   #include <vector>
    3
    4   typedef std::vector<int> vec;
    5
    6   void next_prime_candidate(int c, vec& v) {
    7       for(int i = 0; i < v.size(); ++i) 
    8           if(c % v[i] == 0) return;
    9       v.push_back(c);
   10   }
   11
   12   void print_vec(vec& v) {
   13       for(int i = 0; i < v.size(); ++i)
   14           std::cout << ' ' << v[i];
   15   }
   16
   17   int main() {
   18       vec v; v.push_back(2);
   19       for(int i = 3; v.size() < 10000; ++i)
   20           next_prime_candidate(i, v);
   21       print_vec(v);
   22   }   

Compiled with g++-3.0 -O2 on my aging AMD K6-2 550 MHz, I get

real    0m4.632s
user    0m3.290s
sys     0m0.260s

while for Sebastien's findprimes_simple.ml, compiled with ocamlopt, I get

real    0m43.809s
user    0m41.590s
sys     0m0.040s

C++ version does not get faster if I add v.reserve(10000) in the beginning, 
so its bottleneck is probably not in memory allocation.

Perhaps O'Caml version can be made faster: here's my shot at it:

    1   let next_prime_candidate c v = 
    2   let _ = try 
    3   Array.iter (fun x -> if c mod x = 0 then failwith "not a prime") !v;
    4   v := Array.append !v [| c |];
    5   with Failure "not a prime" -> () in ();;
    6
    7   let print_array v = 
    8   Array.iter (fun i -> print_char ' '; print_int i) v;;
    9
   10   let v = ref [| 2 |] in
   11   let i = ref 2 in
   12   let _ =
   13   while Array.length !v < 10000 do
   14       i := !i + 1;
   15       next_prime_candidate !i v
   16   done in
   17   print_array !v;;

Timing:

real    0m11.645s
user    0m11.370s
sys     0m0.010s

Still 3-4 times slower.  Is it because exceptions are used instead of 
[non-existent ?] early function return or loop break?

A version of the last program with Lists instead of Arrays is 7-8 times 
slower than the Array version.

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

[Caml-list] Re: Sieve of Eratosthenes Performance: various languages (Re: [Caml-list] productivity improvement)

[William D. Neumann]

Gah!!! You guys are making me nuts!

Not because of this topic (I actually find this somewhat interesting --
even if I don't know why), but because every post on the subject has
ignored the two most basic optimizations that should be done for this
small prime generation:
  Doing trial division only up to the square root of the candidate (and)
  Incrementing your candidates by 2 rather than 1 (2 is the only even
  prime -- don't waste your time on even numbers!)

Seriously, why pull out vector libraries, etc. while leaving these pigs in
your pantry?

For what it's worth, here is my naive 10 minute solution that takes about
0.2 seconds to generate the first 5000 primes on my 500MHz G4 (and no
fair laughing at my poor programming chops!):

(* ********************************** *)

type pState = {primes : int array; 
	       mutable top : int; 
	       mutable cur : int;
	       max : int};;

let print_prime op =
  match op with
      None -> ()
    | Some p -> Printf.printf "%d\n" p;;

let next state = state.cur <- state.cur + 2;;
let update state = 
  begin
    Array.set state.primes state.top state.cur;
    state.top <- state.top + 1;
    next state
  end;;

let is_prime state= 
  let b = (int_of_float (sqrt (float_of_int state.cur))) and
    index = ref 1 and
    prime = ref true in
    while ((state.primes.(!index) <= b) & !prime) do
      if (state.cur mod state.primes.(!index) = 0) 
      then prime := false
      else index := (!index + 1)
    done;
    !prime;;

let rec next_prime state =
  if state.top >= state.max then
    None
  else
    if is_prime state then
      (update state; Some state.primes.(state.top - 1))
    else
      (next state; next_prime state);;

let main () =
  let num_primes = (int_of_string Sys.argv.(1)) in
  let state = {primes = Array.make num_primes 2;
	       top = 1;
	       cur = 3;
	       max = num_primes;} in
  let p = ref (next_prime state) in
    while (!p <> None) do
      print_prime !p;
      p := (next_prime state);
    done;;

main ();;

(* ********************************** *)

William D. "Cranky or something" Neumann

On Wed, 10 Jul 2002, Oleg wrote:

> On Wednesday 10 July 2002 06:02 am, sebastien FURIC wrote:
> 
> <snip>
> 
> > </caml>
> >
> > real    11m9.021s
> > user    0m0.020s
> > sys     0m0.030s
> >
> >  Sebastien.
> 
> I guess this is an example of when very idiomatic C++ shines:
> 
>     1   #include <iostream>
>     2   #include <vector>
>     3
>     4   typedef std::vector<int> vec;
>     5
>     6   void next_prime_candidate(int c, vec& v) {
>     7       for(int i = 0; i < v.size(); ++i) 
>     8           if(c % v[i] == 0) return;
>     9       v.push_back(c);
>    10   }
>    11
>    12   void print_vec(vec& v) {
>    13       for(int i = 0; i < v.size(); ++i)
>    14           std::cout << ' ' << v[i];
>    15   }
>    16
>    17   int main() {
>    18       vec v; v.push_back(2);
>    19       for(int i = 3; v.size() < 10000; ++i)
>    20           next_prime_candidate(i, v);
>    21       print_vec(v);
>    22   }   
> 
> Compiled with g++-3.0 -O2 on my aging AMD K6-2 550 MHz, I get
> 
> real    0m4.632s
> user    0m3.290s
> sys     0m0.260s
> 
> while for Sebastien's findprimes_simple.ml, compiled with ocamlopt, I get
> 
> real    0m43.809s
> user    0m41.590s
> sys     0m0.040s
> 
> C++ version does not get faster if I add v.reserve(10000) in the beginning, 
> so its bottleneck is probably not in memory allocation.
> 
> Perhaps O'Caml version can be made faster: here's my shot at it:
> 
>     1   let next_prime_candidate c v = 
>     2   let _ = try 
>     3   Array.iter (fun x -> if c mod x = 0 then failwith "not a prime") !v;
>     4   v := Array.append !v [| c |];
>     5   with Failure "not a prime" -> () in ();;
>     6
>     7   let print_array v = 
>     8   Array.iter (fun i -> print_char ' '; print_int i) v;;
>     9
>    10   let v = ref [| 2 |] in
>    11   let i = ref 2 in
>    12   let _ =
>    13   while Array.length !v < 10000 do
>    14       i := !i + 1;
>    15       next_prime_candidate !i v
>    16   done in
>    17   print_array !v;;
> 
> Timing:
> 
> real    0m11.645s
> user    0m11.370s
> sys     0m0.010s
> 
> Still 3-4 times slower.  Is it because exceptions are used instead of 
> [non-existent ?] early function return or loop break?
> 
> A version of the last program with Lists instead of Arrays is 7-8 times 
> slower than the Array version.
> 
> 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
> 


---

"The magnum opus of rms and his Foundation is called 'GNU', a project to
completely rewrite the propritorially soiled Unix operating system. 
(Apparently, 'GNU' stands for "Gnu's Not Unix", and is proudly held to be
the world's first 'recursive acronym'. Which, of course, proves that rms
didn't get out enough in his youth.) 

	-- Nick Roberts


-------------------
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] Re: Sieve of Eratosthenes Performance: various languages

[Alexander V.Voinov]

Hi William,

But it is completely imperative. As I understand, the original Oleg's
concern was that he doesn't see a point in learning something which
doesn't bring any benefit over C++. Personally, I don't see a point
in using OCaml _solely_ as a Pascal with GC. 

The only reason which justifies for me your quoted exercise is that
when you deadly need an efficient imperative part in your program you
can (quite likely) achieve this without leaving the language (to a C
extension or whatever).

Alexander

From: "William D. Neumann" <wneumann@cs.unm.edu>
Subject: [Caml-list] Re: Sieve of Eratosthenes Performance: various languages (Re: [Caml-list] productivity improvement)
Date: Wed, 10 Jul 2002 14:34:52 -0600 (MDT)

> Gah!!! You guys are making me nuts!
> 
> Not because of this topic (I actually find this somewhat interesting --
> even if I don't know why), but because every post on the subject has
> ignored the two most basic optimizations that should be done for this
> small prime generation:
>   Doing trial division only up to the square root of the candidate (and)
>   Incrementing your candidates by 2 rather than 1 (2 is the only even
>   prime -- don't waste your time on even numbers!)
> 
> Seriously, why pull out vector libraries, etc. while leaving these pigs in
> your pantry?
> 
> For what it's worth, here is my naive 10 minute solution that takes about
> 0.2 seconds to generate the first 5000 primes on my 500MHz G4 (and no
> fair laughing at my poor programming chops!):
-------------------
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] Re: Sieve of Eratosthenes Performance: various languages

[William D. Neumann]

Well, let's face it.  This particular problem doesn't do much to address
Oleg's (C vs. OCaml productivity ) question at all.  And I wasn't posting
my solution as an example of increased productivity either -- I was simply
venting a bit (you have to understand, I'm a cryptographer, so seeing
times in the minutes and seconds for generating the first 5000 primes is
enough to make my skin crawl).

Anyway, you don't see the point of using OCaml _solely_ as a Pascal with
GC, and I don't see the point of writing bad code, simply for the sake of
keeping it purely functional (after all, slow execution and sexy code
isn't a productivity boost either).  Still, your second point is very
valid -- If the best I can do to generate a stream of primes in a
functional manner is 250/second, something is wrong, and I'm going to need
a better way of doing things.  And with OCaml I can do that effortlessly,
even if the rest of my code is functional out the wazoo.

William D. Neumann

On Wed, 10 Jul 2002, Alexander V.Voinov wrote:

> Hi William,
> 
> But it is completely imperative. As I understand, the original Oleg's
> concern was that he doesn't see a point in learning something which
> doesn't bring any benefit over C++. Personally, I don't see a point
> in using OCaml _solely_ as a Pascal with GC. 
> 
> The only reason which justifies for me your quoted exercise is that
> when you deadly need an efficient imperative part in your program you
> can (quite likely) achieve this without leaving the language (to a C
> extension or whatever).
> 
> Alexander

---

"The magnum opus of rms and his Foundation is called 'GNU', a project to
completely rewrite the propritorially soiled Unix operating system. 
(Apparently, 'GNU' stands for "Gnu's Not Unix", and is proudly held to be
the world's first 'recursive acronym'. Which, of course, proves that rms
didn't get out enough in his youth.) 

	-- Nick Roberts


-------------------
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] Re: Sieve of Eratosthenes Performance: various languages (Re: [Caml-list] productivity improvement)

[William D. Neumann]

Not that I need to add more noise to the channel, but just in case
someone cares, that time listed below is for the bytecode compiled
version.  Times for native compiled versions are as follows:

5000 primes:
0.050u 0.000s 0:00.07 71.4%     0+0k 0+6io 0pf+0w
10000 primes:
0.100u 0.030s 0:00.16 81.2%     0+0k 0+6io 0pf+0w
50000 primes:
0.710u 0.020s 0:01.26 57.9%     0+0k 0+0io 0pf+0w
500000 primes:
21.460u 0.330s 0:29.02 75.0%    0+0k 0+3io 0pf+0w

Now then...I suppose it's time to get back to work.

William D. Neumann

On Wed, 10 Jul 2002, William D. Neumann wrote:

> For what it's worth, here is my naive 10 minute solution that takes about
> 0.2 seconds to generate the first 5000 primes on my 500MHz G4 (and no
> fair laughing at my poor programming chops!):


---

"The magnum opus of rms and his Foundation is called 'GNU', a project to
completely rewrite the propritorially soiled Unix operating system. 
(Apparently, 'GNU' stands for "Gnu's Not Unix", and is proudly held to be
the world's first 'recursive acronym'. Which, of course, proves that rms
didn't get out enough in his youth.) 

	-- Nick Roberts



-------------------
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] Array.resize ?

[Oleg]

Hi

Is there an efficient way in O'Caml to append an element to an array ref?

let append_elt r x = r := Array.append !r [| x |];;

copies the contents of the whole array in its body, while e.g. C++ vector 
push_back in most cases won't (memory is reserved in chunks automatically, or 
it can be reserved manually)

IOW it seems strange to me that functions of arrays can change their contents 
but not their size, while functions of array ref's can do it, but 
inefficiently. How about 

Array.resize :  'a array -> int -> unit

or at least 

Array.resize: 'a array ref -> int -> unit ?

Thanks
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] Array.resize ?

[Alessandro Baretta]

Oleg wrote:
> Hi
> 
> Is there an efficient way in O'Caml to append an element to an array ref?
> 
> let append_elt r x = r := Array.append !r [| x |];;
> 
> copies the contents of the whole array in its body, while e.g. C++ vector 
> push_back in most cases won't (memory is reserved in chunks automatically, or 
> it can be reserved manually)

Ah, wait a minute. A vector is not an arraw. Whatever its 
implementation it only behaves like an array from a 
syntactic point of view: it defines the operator[] for array 
indexing, but it might as well be implemented as a list for 
all you know; however, the STL imposes constraints on the 
complexity of the different algorithms used to manage a 
vector. I have found the following definition of a vector:
 > A vector is a Sequence that supports random access to
 > elements, constant time insertion and removal of elements
 > at the end, and linear time insertion and removal of
 > elements at the beginning or in the middle. The number of
 > elements in a vector may vary dynamically; memory
 > management is automatic.

This is much different from either a C array or an O'Caml 
array. Again, the issue is raised: do we need an OCaSTL?

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] Array.resize ?

[John Max Skaller]

Alessandro Baretta wrote:

> This is much different from either a C array or an O'Caml array. 
> Again, the issue is raised: do we need an OCaSTL?

No, but we do need a richer library. Unlike Python, efficiency is important
for Ocaml. A lot of work has gone into making Ocaml fast: right from the 
start,
the decision to generate native code directly rather than going via C 
indicates
that performance is treated very seriously. As it should be!


Now recently, big arrays of various types have been added with
unboxed elements. And I can guess that the problem
of supporting arrays of unboxed elements of a more general class
of types is being looked at.


[Do I guess right?]

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




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

Re: [Caml-list] Array.resize ?

[Shawn Wagner]

On Fri, Jul 12, 2002 at 11:01:43PM +1000, John Max Skaller wrote:
> Alessandro Baretta wrote:
> 
> > This is much different from either a C array or an O'Caml array. 
> > Again, the issue is raised: do we need an OCaSTL?
> 
> No, but we do need a richer library. 

Something I've been thinking lately of doing is taking the scheme list and
string libraries (http://srfi.schemers.org/srfi-1/srfi-1.html and
http://srfi.schemers.org/srfi-13/srfi-13.html) and writing ocaml versions of
many of the functions described in them that are missing from the standard
library.  Some of the algorithms from the C++ STL would be useful too.

-- 
Shawn Wagner
shawnw@speakeasy.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] Array.resize ?

[Markus Mottl]

On Thu, 11 Jul 2002, Oleg wrote:
> Is there an efficient way in O'Caml to append an element to an array ref?

You might want to try my RES-library, which provides for automatically
resizing arrays and strings (the resizing strategies can be
parameterized):

  http://www.oefai.at/~markus/home/ocaml_sources.html

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

Re: [Caml-list] Array.resize ?

[John Max Skaller]

Oleg wrote:

>Hi
>
>Is there an efficient way in O'Caml to append an element to an array ref?
>
>let append_elt r x = r := Array.append !r [| x |];;
>
>copies the contents of the whole array in its body, while e.g. C++ vector 
>push_back in most cases won't (memory is reserved in chunks automatically, or 
>it can be reserved manually)
>
>IOW it seems strange to me that functions of arrays can change their contents 
>but not their size, while functions of array ref's can do it, but 
>inefficiently. How about 
>
>Array.resize :  'a array -> int -> unit
>
>or at least 
>
>Array.resize: 'a array ref -> int -> unit ?
>
I might add that I have requested a variable length array, similar to a 
C++ vector.
It is possible to make one using pure Ocaml + a little Obj.magic. **
But it would be better if it were in the standard distribution.

[you need allocate initialise unused slots using Obj.magic ..
this is considered naughty :-]

Similar for Strings .. though IMHO module String should be deprecated:
we don't need Strings when we have Arrays.

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




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

Re: [Caml-list] Array.resize ?

[Olivier Andrieu]

 John Max Skaller [Friday 12 July 2002] :
 > Similar for Strings .. though IMHO module String should be
 > deprecated: we don't need Strings when we have Arrays.

You mean throwing away, the compact, C-compatible representation of
strings and using instead some `char array' (that is, arrays of 32bits
integers) ? 

Uck, no way !

-- 
   Olivier
-------------------
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] Array.resize ?

[John Max Skaller]

Olivier Andrieu wrote:

> John Max Skaller [Friday 12 July 2002] :
> > Similar for Strings .. though IMHO module String should be
> > deprecated: we don't need Strings when we have Arrays.
>
>You mean throwing away, the compact, C-compatible representation of
>strings
>
> and using instead some `char array' (that is, arrays of 32bits
>
That is an optimisation problem for the compiler.
32 bits is the right size for a Unicode character - but byte arrays are 
still useful.

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




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

Re: [Caml-list] Array.resize ?

[Brian Rogoff]

John Max Skaller writes:
> I might add that I have requested a variable length array, similar to a 
> C++ vector.
> It is possible to make one using pure Ocaml + a little Obj.magic. **

It's possible to write them without any unsafe primitives in core ML. 

> But it would be better if it were in the standard distribution.

I think a built in Dynarray or Vect module would probably be worthwhile. 

> [you need allocate initialise unused slots using Obj.magic ..
> this is considered naughty :-]

That depends on the interface you provide. If you only allow construction
through functions (and not [||]) you always have a default value. A 
builtin Dynarray needn't have this restriction, and would probably be
written in C anyways. 

> Similar for Strings .. though IMHO module String should be deprecated:
> we don't need Strings when we have Arrays.

I think I understand where you're coming from, but I think you really mean 
that we don't need Strings when we have Bigarrays. 

-- 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] Array.resize ?

[Eray Ozkural]

On Friday 12 July 2002 19:09, Brian Rogoff wrote:
>
> I think a built in Dynarray or Vect module would probably be worthwhile.
>

Let me give it a shot, I guess I wrote that more than a couple of times in 
other languages. (/me launches konqueror to take a look at C++ code)

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] debugger losing contact with debuggee process

[Lex Stein]

Hello,

A process I am debugging has a bus error and crashes. When it crashes, it
loses contact with ocaml_debug. The output looks something like this:

calling db->put with db=3c8c0 txn=0 flags=0
Invalid argument (error number 22)
BDB: aborting transaction
Lost connection with process 3531 (active process)
between time 290000 and time 300000
Trying to recover...
Time : 290000 - pc : 59612 - module Printf
186 <|b|>let res = Buffer.contents dest in

The debugger loses contact with the debuggee process because the debuggee
has a bus error and terminates.

The information provided by ocamldebug above isn't very helpful. How do I
get a backtrace at the time of the bus error ? Something along the lines
of a bactrace on a core dump file would be great. How does one get this
information using ocamldebug ?

Sincerely,
Lex

[ I posted this question to the ocaml_beginners list. After receiving no
replies on that list after 12hours, I conclude that the people on that
list don't have the experience with ocamldebug to answer the question and
am posting it to this list. ]

-------------------
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] debugger losing contact with debuggee process

[Pierre Weis]

Hello,

> A process I am debugging has a bus error and crashes. When it crashes, it
> loses contact with ocaml_debug. The output looks something like this:
> 
> calling db->put with db=3c8c0 txn=0 flags=0
> Invalid argument (error number 22)
> BDB: aborting transaction
> Lost connection with process 3531 (active process)
> between time 290000 and time 300000
               ^^^^^^          ^^^^^^
These numbers are very valuable information...

> Trying to recover...
> Time : 290000 - pc : 59612 - module Printf
         ^^^^^^
> 186 <|b|>let res = Buffer.contents dest in
> 
> The debugger loses contact with the debuggee process because the debuggee
> has a bus error and terminates.
> 
> The information provided by ocamldebug above isn't very helpful. How do I
> get a backtrace at the time of the bus error ? Something along the lines
> of a bactrace on a core dump file would be great. How does one get this
> information using ocamldebug ?

The information that ocamldebug gave you is helpful : it provides the
mean to go back way before the bus error (Time 290000), and ensures
that the bus error will appear before Time 300000. To go (go) just before
the bus error and ask for a backtrace then (bt) is just a matter of
dichotomy and is very fast. Once your very near the bus error you can
step use instruction stepping (s) and print (p) and next event (n) to
understand what happens.

(Use help in the debugger to get help in the debugger.)

> Lex
> 
> [ I posted this question to the ocaml_beginners list. After receiving no
> replies on that list after 12hours, I conclude that the people on that
> list don't have the experience with ocamldebug to answer the question and
> am posting it to this list. ]

This is a bit fast: don't forget the time difference between you and
the rest of the world! Also consider that people may have something
else to do than answering to your message just now!

Sincerely,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/
-------------------
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] debugger losing contact with debuggee process

[Xavier Leroy]

> A process I am debugging has a bus error and crashes. When it crashes, it
> loses contact with ocaml_debug. The output looks something like this:
> 
> calling db->put with db=3c8c0 txn=0 flags=0
> Invalid argument (error number 22)
> BDB: aborting transaction

To complement Pierre's reply: if you do the dichotomy trick that
Pierre described, you'll probably find that the crash occurs in a 
C function (declared "external" in Caml).  Thus, you'll have to run
your program under a C debugger such as gdb.  To make this easier,
try to compile the C code with "-g", and link the Caml code with
"ocamlc -o myprog -custom -ccopt -g".  This way, you'll get a
standalone executable named myprog, with debug information attached.

Then, do "gdb myprog", and "run", until it crashes.  gdb "bt" command
will show you where the crash is located.  If it's in a C function
called directly or indirectly from OCaml's "interprete" function,
you're lucky: the error is indeed inside C code, and can be tracked
down just like you'd do for a C program.  If the crash is in
"interprete" or some other function of the OCaml runtime system,
things will be harder: presumably, some C code returned an illegal
Caml value, or messed up with the GC, causing a crash later in the
OCaml runtime system.  A good way to attack these problems is to
conduct a careful code review of the C/OCaml stub code, questioning
every single allocation and construction of OCaml values.

> [ I posted this question to the ocaml_beginners list. After receiving no
> replies on that list after 12hours, I conclude that the people on that
> list don't have the experience with ocamldebug to answer the question and
> am posting it to this list. ]

Your post is on-topic for this list.  However, your expectation that
you should get answers within 12 hours is ridiculous.  Even if you
paid a hefty support contract for a commercial development tool, you
would not get that.

- 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] Array.resize ?

[Eray Ozkural]

On Friday 12 July 2002 01:30, Oleg wrote:
> Hi
>
> Is there an efficient way in O'Caml to append an element to an array ref?
>
> let append_elt r x = r := Array.append !r [| x |];;
>
> copies the contents of the whole array in its body, while e.g. C++ vector
> push_back in most cases won't (memory is reserved in chunks automatically,
> or it can be reserved manually)

Hi Oleg,

Here is some Data Structures 101 for you.

A vector is not an array. It is more like one of the "extensible array" types 
that are around since 1960's. The implementation of vector types use what we 
call an open table with amortized time for n consequent inserts being O(n) 
making a single insert O(1). (See the MIT Algorithms textbook for details) 
This also answers why memory alloc doesn't cost much when using vectors. 
Since the array is expanded or contracted by a factor of 2 in size you need 
only a logarithmic number of memory allocation calls.

A vector is not a special type in C++. You can implement one in ocaml just as 
well or better.

Cheers,

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] Array.resize ?

[Oleg]

On Thursday 17 October 2002 11:05 pm, Eray Ozkural wrote:
> On Friday 12 July 2002 01:30, Oleg wrote:
> > Hi
> >
> > Is there an efficient way in O'Caml to append an element to an array ref?
> >
> > let append_elt r x = r := Array.append !r [| x |];;
> >
> > copies the contents of the whole array in its body, while e.g. C++ vector
> > push_back in most cases won't (memory is reserved in chunks
> > automatically, or it can be reserved manually)
>
> Hi Oleg,
>
> Here is some Data Structures 101 for you.
>
> A vector is not an array. It is more like one of the "extensible array"
> types that are around since 1960's. The implementation of vector types use
> what we call an open table with amortized time for n consequent inserts
> being O(n) making a single insert O(1). (See the MIT Algorithms textbook
> for details) This also answers why memory alloc doesn't cost much when
> using vectors. Since the array is expanded or contracted by a factor of 2
> in size you need only a logarithmic number of memory allocation calls.

This is exactly what I meant when I wrote "memory is reserved in chunks 
automatically ... " above.  

(BTW might I suggest you save the condescending tone for somewhere else?)

> A vector is not a special type in C++. You can implement one in ocaml just
> as well or better.

Which is why I asked for it.

Oleg

P.S. You keep replying to messages that are over THREE months old and 
probably long since lost their relevance: e.g. my question has been answered 
(see RES by Markus Mottl)
-------------------
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] Array.resize ?

[Eray Ozkural]

On Saturday 19 October 2002 04:51, Oleg wrote:
> This is exactly what I meant when I wrote "memory is reserved in chunks
> automatically ... " above.
>
> (BTW might I suggest you save the condescending tone for somewhere else?)
>

I may have wanted to say an array is not something you append to, but a 
"vector" in C++ terminology is.... Sorry for the inappropriate manner.

In fact, the data structure library should be careful enough to distinguish 
list ADT implemented with extensible arrays from list ADT implemented with 
linked lists. I was thinking about this the other day. That distinction is 
probably one of the few things that C++ standard library has implemented 
quite well. (I personally don't like the "iterator" abstraction at all)

Also, a dynamic array which you can resize would be worthwhile. Any name 
suggestions for such a module? I used Dynarray for the small code I posted on 
the list but somebody else may have a better one (like "flex" in algol) I 
always end up using strange names.

Best Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
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: Sieve of Eratosthenes Performance: various languages (Re: [Caml-list] productivity improvement)

[Markus Mottl]

On Wed, 10 Jul 2002, Oleg wrote:
> Compiled with g++-3.0 -O2 on my aging AMD K6-2 550 MHz, I get
> 
> real    0m4.632s
> user    0m3.290s
> sys     0m0.260s

Here is a very fast version, which you'll probably find difficult to
beat using C:

---------------------------------------------------------------------------
let count =
  let count = ref 100 in
  let n_opt = "-n", Arg.Int ((:=) count), "nth prime (default 100)"
  and usage = "Usage: fsieve [-n number] calculates primes" in
  Arg.parse [n_opt] (fun _ -> raise (Arg.Bad "unknown argument!")) usage;
  !count

let primes =
  let primes = Array.create (max count 3) 0 in
  primes.(0) <- 2; primes.(1) <- 3; primes.(2) <- 5; primes

let rec is_prime i pr bd =
  let p = primes.(i) in p > bd || pr mod p <> 0 && is_prime (i + 1) pr bd

let get_psize psize nr bd =
  if is_prime 2 nr bd then begin primes.(psize) <- nr; psize + 1 end
  else psize

let rec prime_n psize nr tog bd bd2 =
  if psize < count then
    if bd2 <= nr then
      let bd = bd + 1 in
      prime_n (get_psize psize nr bd) (nr + tog) (6 - tog) bd (bd * bd)
    else prime_n (get_psize psize nr bd) (nr + tog) (6 - tog) bd bd2

let _ =
  prime_n 3 7 4 3 9;
  Array.iter (Printf.printf "%d\n") primes
---------------------------------------------------------------------------

Timing of ("time ocaml fsieve.ml -n 10000") on an AMD 800MHz, interpreted:

  real    0m0.586s
  user    0m0.460s
  sys     0m0.030s

Compiled to native code (-unsafe -noassert):

  real    0m0.207s
  user    0m0.100s
  sys     0m0.020s

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

Re: Sieve of Eratosthenes Performance: various languages (Re: [Caml-list] productivity improvement)

[Anton E. Moscal]

11 Июль 2002 00:48, Markus Mottl wrote:

> Compiled to native code (-unsafe -noassert):
>
>   real    0m0.207s
>   user    0m0.100s
>   sys     0m0.020s

Really the main part of the time spent in console output: with redirection 
stdout to /dev/null on PIII-630:

real    0m0.128s
user    0m0.080s
sys     0m0.000s

Without any output:

real    0m0.049s
user    0m0.050s
sys     0m0.000s

The more intersing point is that  the straightforward version of this 
algorithm works only slightly slower than yours:

let prime_n' n = 
  let rec gen cnt primes buffer = function 
    | _ when cnt = n -> primes @ List.rev buffer
    | n' -> 
	let rec test primes buffer = function
	  | p::_ when p*p > n' -> (primes, buffer, true)
	  | p::_ when n' mod p = 0 -> (primes, buffer, false)
	  | _::tl -> test primes buffer tl
	  | [] -> 
	      let nxt = List.rev buffer in 
	      test (primes @ nxt) [] nxt
	in
	let (primes, buffer, res) = test primes buffer primes in
	if res 
	then gen (cnt + 1) primes (n'::buffer) (n'+ 2)
	else gen cnt primes buffer (n'+2)
  in
  gen 1 [2] [] 3

without any output and count=200000 on PIII/630 timings is the following: 
yours -  2'83"  my - 3'38".

Regards, Anton
-------------------
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: Sieve of Eratosthenes Performance: various languages (Re: [Caml-list] productivity improvement)

[Eray Ozkural]

On Wednesday 10 July 2002 23:48, Markus Mottl wrote:
> Compiled to native code (-unsafe -noassert):
>
>   real    0m0.207s
>   user    0m0.100s
>   sys     0m0.020s
>

This shows that the programmer makes an awful lot of difference as I said 
before :>

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] productivity improvement

[John Max Skaller]

Oleg wrote:

>What are the _simplest_ examples that demonstrate considerable (> 2:1) O'Caml 
>vs C++ productivity improvement (in terms of program size) and where can I 
>find them?
>
Try doing this in C++:

    type 'a node = Leaf of 'a | Unop of ('a->'a) * node | Binop of ('a * 
'a -> 'a)
    let rec eval n = match n with
    | Leaf  i -> i
    | Unop (f,n) -> f (eval n)
    | Binop (f,n1,n2) -> f ((eval n1), (eval n2))

[Hint: it cannot be done without one of:
    a) casts, or
    b) serious difficulties wth memory management
]


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




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

Re: [Caml-list] productivity improvement

[Nicolas barnier]

John Max Skaller wrote:
> 
> Try doing this in C++:
> 
>     type 'a node = Leaf of 'a | Unop of ('a->'a) * node | Binop of ('a *
> 'a -> 'a)
>     let rec eval n = match n with
>     | Leaf  i -> i
>     | Unop (f,n) -> f (eval n)
>     | Binop (f,n1,n2) -> f ((eval n1), (eval n2))

Just if some newbie wants to copy and paste this piece of code,
there is a small mistake in the type:

type 'a node =
   Leaf of 'a
 | Unop of ('a->'a) * 'a  node
 | Binop of ('a * 'a -> 'a)  * 'a  node * 'a  node;;

-- Nicolas
-------------------
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] Is this a bug?

[John Max Skaller]

There is a bug here: is it in:

 Objective Caml version 3.04+11 (2002-05-16)

or is it in my code:
 
in one module:

    | `TYP_none -> print_endline ("NONE DETECTED");
       0,"Unknown"
 
in another module:

       | `DCL_val t ->
          print_endline ("val " ^ id^ "[old] : " ^ string_of_typecode t);
          let t' = match t with | `TYP_none -> `TYP_var n | _ -> t in
          print_endline ("val " ^ id^"[new] : " ^ string_of_typecode t');

output (2 test cases):

val printv[old] : Unknown
NONE DETECTED
val printv[new] : Unknown
NONE DETECTED
val x[old] : Unknown
NONE DETECTED
val x[new] : Unknown


The code also fails if I replace the match t with |`TYP_none with
and if/then/else construction.

It looks like the constructor `TYP_none isn't equal to itself :-)

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




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

Re: [Caml-list] Is this a bug?

[Xavier Leroy]

> There is a bug here

Perhaps, but there's no way to tell from the limited context that you give.

As I already explained you in the past, if you expect us to
investigate, please package a test program that reproduces the
unexpected behavior, and submit a bug report to caml-bugs@inria.fr.
(This list doesn't really care.)

- 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] productivity improvement

[Oleg]

On Wednesday 10 July 2002 11:39 am, John Max Skaller wrote:
> Oleg wrote:
> >What are the _simplest_ examples that demonstrate considerable (> 2:1)
> > O'Caml vs C++ productivity improvement (in terms of program size) and
> > where can I find them?
>
> Try doing this in C++:
>
>     type 'a node = Leaf of 'a | Unop of ('a->'a) * node | Binop of ('a *
> 'a -> 'a)
>     let rec eval n = match n with
>
>     | Leaf  i -> i
>     | Unop (f,n) -> f (eval n)
>     | Binop (f,n1,n2) -> f ((eval n1), (eval n2))
>
> [Hint: it cannot be done without one of:
>     a) casts, or
>     b) serious difficulties wth memory management
> ]

Shame on you! I hear you are on the C++ standardization committee :)
Code first [1], comments below.

<C++>
    1   #include <iostream>
    2   #include <cmath>
    3
    4   template<class T>
    5   struct node { 
    6       virtual T eval() = 0;
    7   };
    8
    9   template<class T>
   10   struct leaf : public node<T> {
   11       T i;
   12       T eval() { return i; }
   13       leaf(const T& t) : i(t) {};
   14   };
   15
   16   template<class T>
   17   struct unop : public node<T> {
   18       T (*fun)(T);
   19       node<T>& n;
   20       T eval() { return fun(n.eval()); }
   21       unop(T (*f)(T), node<T>& N) : fun(f), n(N) {}
   22   };
   23
   24   template<class T>
   25   struct binop : public node<T> {
   26       T (*fun)(T, T);
   27       node<T> &n1;
   28       node<T> &n2;
   29       T eval() { return fun(n1.eval(), n2.eval()); }
   30       binop(T (*f)(T, T), node<T>& N1, node<T>& N2) : fun(f), n1(N1), 
n2(N2) {}
   31   };
   32
   33   int main() {
   34       typedef node<double> N;
   35       typedef leaf<double> L;
   36       typedef unop<double> U;
   37       typedef binop<double> B;
   38       L a(4);
   39       U b(std::sin, a);
   39       U b(std::sin, a);
   40       U c(std::cos, a);
   41       B d(std::atan2, b, c);
   42       std::cout << d.eval() << '\n';
   43   }
</C++>

As one can see, the code is reasonably idiomatic C++, there are no casts or 
explicit memory management. Templates are used only for genericity. If one 
looks past the superficial syntax differences, the C++ code is not even much 
more verbal than the O'Caml example, namely:

1) one needs to define the abstract (interface) class instead of O'Caml's 
succinct "type 'a node = ".
2) writing "template<class T>", "struct", ": public node<T>", "};" adds to 
program size, while decreasing readability and compilation speed. But writing 
these really happens without much thinking.
3) constructors do have to be written manually, but that's only 3 LOC total 
(1 per each derived class / variant), and they are very simple and idiomatic.
4) as used in "main()", the C++ code will not take any "abstraction" [2]
performance pentalty

John's example was still very interesting [3], thanks: we've learned that 
O'Caml variant types translate into C++ single inheritance from abstract 
classes, not unions. Give me more! 

Best regards,
Oleg

P.S. What I do like about C++, is that even though the language claims to be 
multi-paradigm, good design is really class-based (structs are classes), 
while in O'Caml one has to decide on using classes vs records + HOFs, and 
lists vs arrays vs bigarrays. IMHO maybe O'Caml needs fewer types.

[1] I'm no language lawyer, but I think this is 100% ANSI/ISO C++. BTW, it 
compiled with "g++-3.0 -pedantic" without warnings or errors.

[2] In C terms, "calling function through a pointer" in node<double>'s 
virtual table. There will be no penalty, because the C++ compiler is required 
to infer types at compile time here. How about O'Caml? Will it do "match" at 
compile time, if possible?

[3] Special Simpsons quote today:
KITENGE: This is the earliest known fossil of a human being. It's over two 
million years old. 
HOMER: Pff, I've got more bones than that guy. If you're trying to impress 
me, you've failed.
KITENGE: It's not the number of bones, sir, it's the...
HOMER: You have failed!
-------------------
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] productivity improvement

[Eray Ozkural]

On Tuesday 16 July 2002 06:34, Oleg wrote:
>
> As one can see, the code is reasonably idiomatic C++, there are no casts or
> explicit memory management. Templates are used only for genericity. If one
> looks past the superficial syntax differences, the C++ code is not even
> much more verbal than the O'Caml example, namely:

Are you nuts? That code you've written is outlandish. It's typical C++ 
verbooooosity without a point. Did you notice how many lines that is?

It's just the kind of code that I said "should never be written". I can't 
afford programming non-sense like that.

If that looks pretty to you, you ought to revise your sense of aesthetics. 

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] productivity improvement

[Oleg]

On Tuesday 09 July 2002 04:04 pm, John Carr wrote:
> > [1] cat source | sed "s/ //" | wc -c
>
> You need a 'g' at the end of the sed command, or use the simpler:
>
> tr -d ' ' < source | wc -c

cat source | sed "s/[[:space:]]//g" | wc -c

to catch '\t' too, while we are at it.

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] productivity improvement

[Oleg]

On Tuesday 16 July 2002 01:29 pm, Shannon --jj Behrens wrote:

> Wow, that's an impressive piece of C++!!!  C++ never
> seems to stop surprising me!  Nonetheless, I feel the
> OCAML version is infinitely more readable.
>
> Best Regards,
> -jj
[...]

I'd say, to a person equally familiar with O'Caml and C++, the readability 
ratio is less than 2 [1] The readability of compiler messages is a whole 
different story: G++ gives horrible messages when templates, or, god forbid, 
STL errors are present [2]

However, the C++ version looks more "extensible" to me: Suppose that in a 
while, you decide that you want your "node" to be not only Leaf or Unop or 
Binop, but also Triop:

type 'a node = Leaf of 'a | Unop of ('a->'a) * 'a node | Binop of ('a * 'a -> 
'a) * 'a node * 'a node | Triop of ('a * 'a * 'a -> 'a) * 'a node * 'a node * 
'a node;;

You will need to modify the original node type and function "eval" by adding 
an extra pattern to "match" statement, and then recompile everying that 
depends on it. At the same time, with C++ the type of node remains the same. 
You just need to derive a new class  from it:

template<class T>
struct triop : public node<T> {
      T (*fun)(T, T, T);
      node<T> &n1;
      node<T> &n2;
      node<T> &n3
      T eval() { return fun(n1.eval(), n2.eval(), n3.eval); }
      triop (T (*f)(T, T, T), node<T>& N1, node<T>& N2, node<T>& N3) : 
fun(f), n1(N1),  n2(N2), n3(N3) {}  
};

Recompiling isn't necessary. In fact, "old code" may call "new code" if you 
happen to pass it a node that happens to be a triop.

Oleg

P.S. Having read the CalTech tutorial and chapters 1-4 & 14 of the O'Reilly 
book, and having gotten some experience with O'Caml, I'm running low on 
motivation right now. Please give me examples of what's 
hard/awkward/impossible in C++, but relatively easy in O'Caml, if any (I have 
only finite time, so 50 KLOC Coq is not a good example :)

P.P.S. My primary interest is statistical AI (artificial neural networks). I 
haven't found any relevant libraries or applications in SML or O'Caml. That 
is a bit discouraging.

[1] And the example was hand-picked!
[2] If one doesn't want "ad hoc" genericity, templates aren't necessary, of 
course.
-------------------
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] productivity improvement

[Brian Smith]

Oleg wrote:
> You will need to modify the original node type and function "eval" by adding 
> an extra pattern to "match" statement, and then recompile everying that 
> depends on it. At the same time, with C++ the type of node remains the same. 
> You just need to derive a new class  from it:

I am wondering about this point too. But, perhaps you can use O'Caml 
classes to do the same thing as the C++ template classes?

Anway, I think that the above "problem" can also be an asset. If you are 
building an interpreter, and you add a new construct to the interpreted 
language, then all code that claims to know about every construct will 
become erroneous, and so you will know right away what new code needs to 
be added. There doesn't seem to be anything like that in an 
inheritance-based model.

- 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] productivity improvement

[William Lovas]

On Thu, Jul 18, 2002 at 07:14:06PM -0400, Oleg wrote:
> However, the C++ version looks more "extensible" to me: Suppose that in a 
> while, you decide that you want your "node" to be not only Leaf or Unop or 
> Binop, but also Triop:
> 
> type 'a node = Leaf of 'a | Unop of ('a->'a) * 'a node | Binop of ('a * 'a -> 
> 'a) * 'a node * 'a node | Triop of ('a * 'a * 'a -> 'a) * 'a node * 'a node * 
> 'a node;;
> 
> You will need to modify the original node type and function "eval" by adding 
> an extra pattern to "match" statement, and then recompile everying that 
> depends on it. At the same time, with C++ the type of node remains the same. 
> You just need to derive a new class  from it:
> 
> [snip]
>
> Recompiling isn't necessary. In fact, "old code" may call "new code" if you 
> happen to pass it a node that happens to be a triop.

Yes, but what if you decide to add a new function on nodes?  Like say,
typecheck, or eval2, with slightly different semantics?  In the O'Caml
version, it's as simple as that -- add a new function and run with it.
With the C++ version, though, now you have to modify *every* *single*
*class* that inherits from node, and recompile them all.  

So it really seems that it's just a question of what's most important for
your own particular purpose.  Someone looking to extend the definition of
node indefinitely would prefer an object-oriented version, while someone
focused on providing new functionality over nodes would prefer the
functional version.

> Oleg
> 
> P.S. Having read the CalTech tutorial and chapters 1-4 & 14 of the O'Reilly 
> book, and having gotten some experience with O'Caml, I'm running low on 
> motivation right now. Please give me examples of what's 
> hard/awkward/impossible in C++, but relatively easy in O'Caml, if any (I have 
> only finite time, so 50 KLOC Coq is not a good example :)

It strikes me that although you were able to quite easily translate this
toy evaluator example into C++, this may not have been the case with a
larger, more complex example.  It's something that scales exponentially, so
you're probably not going to find very many small, concise examples that 
show conclusively how much easier O'Caml is.  (And, of course, you have to 
take into account the style question mentioned above.  One style does not
necessarily fit all.)

William
-------------------
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] productivity improvement

[Oleg]

On Thursday 18 July 2002 07:54 pm, William Lovas wrote:
> On Thu, Jul 18, 2002 at 07:14:06PM -0400, Oleg wrote:
> > However, the C++ version looks more "extensible" to me: Suppose that in a
> > while, you decide that you want your "node" to be not only Leaf or Unop
> > or Binop, but also Triop:
> >
> > type 'a node = Leaf of 'a | Unop of ('a->'a) * 'a node | Binop of ('a *
> > 'a -> 'a) * 'a node * 'a node | Triop of ('a * 'a * 'a -> 'a) * 'a node *
> > 'a node * 'a node;;
> >
> > You will need to modify the original node type and function "eval" by
> > adding an extra pattern to "match" statement, and then recompile everying
> > that depends on it. At the same time, with C++ the type of node remains
> > the same. You just need to derive a new class  from it:
> >
> > [snip]
> >
> > Recompiling isn't necessary. In fact, "old code" may call "new code" if
> > you happen to pass it a node that happens to be a triop.
>
> Yes, but what if you decide to add a new function on nodes?  Like say,
> typecheck, or eval2, with slightly different semantics?  In the O'Caml
> version, it's as simple as that -- add a new function and run with it.
> With the C++ version, though, now you have to modify *every* *single*
> *class* that inherits from node, and recompile them all.
[...]

Not really. Run-time type identification (RTTI) and a "switch" statement 
should work in a free (non-member) function just like O'Caml's "match" AFAIK.

Regards,
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] productivity improvement

[Oleg]

On Friday 19 July 2002 03:03 am, Issac Trotts wrote:
> Right, so how is your C++ compiler going to remind you when you forget to
> include a needed case in the switch statement (assuming there is something
> in the typeinfo to switch on; you can't switch on a string in C++.)  OCaml
> will remind you, but I don't see how a C++ compiler could.

Correct. Since C++ compiler can not possibly know of all existent sub-types, 
there is no way it can warn you. This is why virtual member functions are 
still preferred. 

Regards
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] productivity improvement

[Andreas Rossberg]

Oleg wrote:
> 
> On Friday 19 July 2002 03:03 am, Issac Trotts wrote:
> > Right, so how is your C++ compiler going to remind you when you forget to
> > include a needed case in the switch statement (assuming there is something
> > in the typeinfo to switch on; you can't switch on a string in C++.)  OCaml
> > will remind you, but I don't see how a C++ compiler could.
> 
> Correct. Since C++ compiler can not possibly know of all existent sub-types,
> there is no way it can warn you. This is why virtual member functions are
> still preferred.

And how would you do more complex case analysis, corresponding to nested
patterns? This is more than cumbersome and error-prone in C++ - with
RTTI, and even more so with method dispatch, where your single algorithm
will have to be scattered over tons of distant functions. A maintenance
nightmare.

BTW, as Issac noted, you cannot even use switch statements to perform
RTTI in C++. You have to program if cascades.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
 as kids, we would all be running around in darkened rooms, munching
 magic pills, and listening to repetitive electronic music."
 - Kristian Wilson, Nintendo Inc.
-------------------
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] productivity improvement

[Alessandro Baretta]

Andreas Rossberg wrote:
> Oleg wrote:
>>
>>Correct. Since C++ compiler can not possibly know of all existent sub-types,
>>there is no way it can warn you. This is why virtual member functions are
>>still preferred.
> 
> And how would you do more complex case analysis, corresponding to nested
> patterns? This is more than cumbersome and error-prone in C++ - with
> RTTI, and even more so with method dispatch, where your single algorithm
> will have to be scattered over tons of distant functions. A maintenance
> nightmare.
> 
> BTW, as Issac noted, you cannot even use switch statements to perform
> RTTI in C++. You have to program if cascades.
> 

Yes, but RTTI is a hack. Nobody would seriously "plan" to 
use RTTI during the design stage of a software system. You 
just "happen" to need RTTI when most of the code is already 
there and you realize there is a bug in the specification 
which would require to redesign the inheritance hieararchy. 
In such cases you go with RTTI. Otherwise, you'd stick to 
simple OO polymorphism, which is the "Right Way(TM)" to use 
case/pattern matching constructs in C++. In C++ all you have 
to encapsulate runtime types is the class construct. Because 
of its native polymorphism, one could argue that RTTI and 
case statements are never really needed. The only arise out 
of design errors. Of course, the latter seem to be fairly 
frequent in a language that does not enforce sensible coding 
conventions. Consider <reinterpret_cast> ...

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] productivity improvement

[John Max Skaller]

Alessandro Baretta wrote:

>
> Yes, but RTTI is a hack. 


Matches on ocaml unions _also_ use run time checks.

> Nobody would seriously "plan" to use RTTI during the design stage of a 
> software system. 

Sure they do.

> You just "happen" to need RTTI when most of the code is already there 
> and you realize there is a bug in the specification which would 
> require to redesign the inheritance hieararchy. In such cases you go 
> with RTTI. Otherwise, you'd stick to simple OO polymorphism, which is 
> the "Right Way(TM)" to use 


No. (class based) object orientation is utterly flawed as a paradigm, as 
can be seen
by posing the trivial problem of representing any type with a binary 
operator.
It just can't be done, the problem is called 'covariance problem'.

I find it hard to state what the problem is here, but I'll try:
the problem is you can write an unimplementable interface
and not get a type error:

    struct X { virtual bool binop(X const&)const=0; };

No (realistic) instances of this class can be constructed
because no derived class can implement the method binop.
[That is a fact not to be debated] The problem then is that
you can reasonably expect to write this interface for
say a 'number' type.

In commerical applications, almost ALL data is relational,
and so cannot be abstracted. The OO paradigm is not just
useless here, but downright destructive.

Example:

    class Transaction { ..
    class Invoice { ...

Well, suppose you wanted more than one kind of transaction,
and more than one kind of invoice .. some ignorant designer
would think polymorpism would work here.

I doesn't though. You you end up using RTTI hacks,
NOT because of a design error .. but because the very paradigm
is faulty.

Not I'm not saying objects/classes etc are useless. I'm saying
they're just a tool with some limited uses: they perform well
when restricted to those uses. If no covariant methods are needed,
abstraction works. For example: device drivers typically have
methods with invariant arguments.

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




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

Re: [Caml-list] productivity improvement

[Brian Smith]

John Max Skaller wrote:
> Alessandro Baretta wrote:
> No. (class based) object orientation is utterly flawed as a paradigm, as 
> can be seen by posing the trivial problem of representing any type
 > with a binary operator.
> It just can't be done, the problem is called 'covariance problem'.
> 
> I find it hard to state what the problem is here, but I'll try:
> the problem is you can write an unimplementable interface
> and not get a type error:
> 
>    struct X { virtual bool binop(X const&)const=0; };

Do you really mean _all_ class-based object orientation? Don't 
multimethods and/or overloading help in this case?

bool equals(x : 'a,      y : 'b)      = false ;
bool equals(x : Integer, y : Integer) = x.intValue() = y.intValue() ;
bool equals(x : String,  y : String)  = (* compare all the chars *) ;
bool equals(x : String,  y : Integer) = equals(x, y.toString()) ;

This seems to be what Nice does. Nice is based on the 
ML(less-than-or-equal) type system.

Perhaps, your comments only apply to a certain subset of class-based 
object-orietned languages?

- 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] productivity improvement

[John Max Skaller]

Brian Smith wrote:

> John Max Skaller wrote:
>
>> Alessandro Baretta wrote:
>> No. (class based) object orientation is utterly flawed as a paradigm, 
>> as can be seen by posing the trivial problem of representing any type
>
> > with a binary operator.
>
>> It just can't be done, the problem is called 'covariance problem'.
>>
>> I find it hard to state what the problem is here, but I'll try:
>> the problem is you can write an unimplementable interface
>> and not get a type error:
>>
>>    struct X { virtual bool binop(X const&)const=0; };
>
>
> Do you really mean _all_ class-based object orientation? Don't 
> multimethods and/or overloading help in this case? 


I don't understand really. The requirment is for an interface specification
and (the possibility of) multiple representations.

Multimethods are just a slightly more sophisticated dispatch technique,
they necessarily break object encapsulation, and there is still
no way to represent n squared functions any way other
than with n squared functions. :-)

Does overloading help? Sure. It is the only solution.
More precisely,  a convenient syntax for naming
the n squared functions.

>
>
> bool equals(x : 'a,      y : 'b)      = false ; 


> bool equals(x : Integer, y : Integer) = x.intValue() = y.intValue() ;
> bool equals(x : String,  y : String)  = (* compare all the chars *) ; 

Both these cases show a common representation.

What is the type of x.intValue()?
Obviously this is bogus. There is a total loss of abstraction.
Clearly, the only type of Integer of any use at all is 'int'.
Obviously won't work for 'long long int'. ;-)

The second case is more interesting, since the String
contents are concrete, but the representation of the
sequencing of them internally is abstracted.

In other words, different implementations can
exist of the *same* type String.  This is a good use
of class based object orientation (providing
one level of representation independence).

Q: Why does it work?
A: because the characteristic methods of the abstraction

    x.get(i) // get nth char
    x.set(i,c) // set ith char to c

have *invariant* arguments. In particular,
i and c are specific concrete types.

> bool equals(x : String,  y : Integer) = equals(x, y.toString()) ; 

Urg :-)

>
> This seems to be what Nice does. Nice is based on the 
> ML(less-than-or-equal) type system.
>
> Perhaps, your comments only apply to a certain subset of class-based 
> object-orietned languages?

My comment applies to considering object orientation as a *paradigm*.
It is language independent, entailing mutable objects, encapsulation,
and subtyping (possibly via inheritance).

Ocaml and C++  are both object oriented languages, and they are both better
than pure ones precisely because classes are only one available
technique.  Classes are useful, dynamic *linear* dispatch is not to be
sneered at. (and multimethod research is useful, to find
'almost linear' dispatch techniques). [linear dispatch uses
an indexed table lookup, and so is constant time]


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




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

Re: [Caml-list] productivity improvement

[Alessandro Baretta]

John Max Skaller wrote:
> Alessandro Baretta wrote:
> 
>>
>> Yes, but RTTI is a hack. 
> 
> 
> 
> Matches on ocaml unions _also_ use run time checks.

Sure. Pattern matching is not a problem when it's idiomatic 
and safe. You can say that pattern matching is the most 
basic construct in O'Caml--even let x = 1 is a pattern 
matching. C++, on the other hand, has *no* pattern matching 
construct. RTTI is a kludge, retrofitted on a badly flawed 
language, because there were situations where OO 
polymorphism could not be used.

>> Nobody would seriously "plan" to use RTTI during the design stage of a 
>> software system. 
> 
> Sure they do.

Some people even go bungee jumping o sky diving. You just 
wouldn't beleive how crazy people can get.

>> You just "happen" to need RTTI when most of the code is already there 
>> and you realize there is a bug in the specification which would 
>> require to redesign the inheritance hieararchy. In such cases you go 
>> with RTTI. Otherwise, you'd stick to simple OO polymorphism, which is 
>> the "Right Way(TM)" to use 
> 
> No. (class based) object orientation is utterly flawed as a paradigm, as 
> can be seen
> by posing the trivial problem of representing any type with a binary 
> operator.
> It just can't be done, the problem is called 'covariance problem'.

I searched Google for a covariance problem related to 
unimplementable interfaces but with no luck. Could you point 
me to some literature?

>    struct X { virtual bool binop(X const&)const=0; };

Tell me if I got this straight: OO polymorphism requires 
that inheriting classes wishing to override methods of 
parents must use covariant return types and contravariant 
parameter types, so as to guarantee that inheritance implies 
subtyping. In this case, it would be meaning less to 
implement interface X because, applying the contravariance 
principle to the formal parameter of binop, you'd end up 
with a class whose binop will accept as rhs parameters any 
instance of any subtype of X. Therefore a class Integer will 
have a greater_than_binop accepting instances of class 
Rational, Real, Complex, Quaternion ... This is meaningless, 
of course, so we conclude that establishing an identity 
between inheritance and subtyping relations is paradoxical. 
Correct?

> In commerical applications, almost ALL data is relational,
> and so cannot be abstracted. The OO paradigm is not just
> useless here, but downright destructive.

Slow... What? I don't follow you here.

> Example:
> 
>    class Transaction { ..
>    class Invoice { ...
> 
> Well, suppose you wanted more than one kind of transaction,
> and more than one kind of invoice .. some ignorant designer
> would think polymorpism would work here.
> 
> I doesn't though. You you end up using RTTI hacks,
> NOT because of a design error .. but because the very paradigm
> is faulty.

I can't say. All the literature I read on OO languages 
(_Teach_yourself_C++_in_21_days_/_Java_for_Dummies_ :-) ) 
seems to indicate that RTTI is "intracardiac adrenaline" of 
fibrillating software systems. You try RTTI, then, if it 
dies all the same, you type "rpm --install 
ocaml-3.04.<your_arch>.rpm" and start a new life.

> Not I'm not saying objects/classes etc are useless. I'm saying
> they're just a tool with some limited uses: they perform well
> when restricted to those uses. If no covariant methods are needed,
> abstraction works. For example: device drivers typically have
> methods with invariant arguments.

That's why Linux is coded in C as opposed to C++. I wonder 
about the possibility of writing a functional kernel...

Anyway, it is now appropriate to conclude with: Long live 
the Caml!

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] productivity improvement

[John Max Skaller]

Alessandro Baretta wrote:

>
>>    struct X { virtual bool binop(X const&)const=0; };
>
>
> Tell me if I got this straight: OO polymorphism requires that 
> inheriting classes wishing to override methods of parents must use 
> covariant return types and contravariant parameter types, so as to 
> guarantee that inheritance implies subtyping. In this case, it would 
> be meaning less to implement interface X because, applying the 
> contravariance principle to the formal parameter of binop, you'd end 
> up with a class whose binop will accept as rhs parameters any instance 
> of any subtype of X. Therefore a class Integer will have a 
> greater_than_binop accepting instances of class Rational, Real, 
> Complex, Quaternion ... This is meaningless, of course, so we conclude 
> that establishing an identity between inheritance and subtyping 
> relations is paradoxical. Correct? 


The problem is that for arbitrary implementations of the abstractionX,
you clearly cannot encode the primitive binop without knowing
the representation of 'this' and the argument. This is a precise
assertion compared to saying it is 'meaningless': often there
is a good meaning (sure you can add Rationals and quaternions .. :-)

Note that the assertion is not a theorem: it is an *assumption*.
So it cannot be questioned.

>
>
>> In commerical applications, almost ALL data is relational,
>> and so cannot be abstracted. The OO paradigm is not just
>> useless here, but downright destructive.
>
>
> Slow... What? I don't follow you here. 


A relational database is just an encoding of
functions like

    'a ~b'

by making a table of a and b columns.
But ~ is a binary operator.


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




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

Re: [Caml-list] productivity improvement

[Oleg]

On Friday 19 July 2002 04:57 am, Andreas Rossberg wrote:
> And how would you do more complex case analysis, corresponding to nested
> patterns? 

I think I know what nested patterns are (something like 
Node (x, y, Bla(1, _)) -> ...), but I don't see where any extra difficulty 
will come from while using virtual functions. Could you give specific 
examples please?

> This is more than cumbersome and error-prone in C++ - with
> RTTI, and even more so with method dispatch, where your single algorithm
> will have to be scattered over tons of distant functions. A maintenance
> nightmare.

Why would maintaining code organized by data type be harder? Isn't it what 
encapsulation is all about?

> BTW, as Issac noted, you cannot even use switch statements to perform
> RTTI in C++. You have to program if cascades.

That is correct. I never actually had to use RTTI, so I thought typeid could 
be converted into int.

Regards,
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] productivity improvement

[Andreas Rossberg]

Oleg wrote:
> 
> > And how would you do more complex case analysis, corresponding to nested
> > patterns?
> 
> I think I know what nested patterns are (something like
> Node (x, y, Bla(1, _)) -> ...), but I don't see where any extra difficulty
> will come from while using virtual functions. Could you give specific
> examples please?

Consider a simple expression language again. This time extended with
variables and function expressions:

  type 'a expr = Const of 'a | Var of string
               | Unop of 'a -> 'a
               | Binop of 'a -> 'a -> 'a
               | Lambda of string * 'a expr
               | Apply of 'a expr * 'a expr

Evaluation has to rely on (one-step) reduction (sketch only):

 let rec reduce1 env = function
 | Var x -> List.assoc x env
 | Apply (Lambda (x, e), v) -> eval ((x,v)::env) e
 | Apply (Unop f,  Const x) -> Const (f x)
 | Apply (Binop f, Const x) -> Unop (f x)
 | Apply  _ -> raise Error
 | e -> e

Doing this with method dispatch requires serious amounts of object
spaghetti. I believe you are imaginative enough to see that this is
absolutely hopeless for realistic examples with a large number of more
complex cases - the number of additional helper methods polluting all
your classes will grow exponentially. (And note that even multiple
dispatch isn't expressive enough to avoid that.)

> > This is more than cumbersome and error-prone in C++ - with
> > RTTI, and even more so with method dispatch, where your single algorithm
> > will have to be scattered over tons of distant functions. A maintenance
> > nightmare.
> 
> Why would maintaining code organized by data type be harder? Isn't it what
> encapsulation is all about?

No. That's one of the things OO ideology gets wrong. Making the type the
unit of encapsulation is much too inflexible. Often you want to
encapsulate several types simultanously, e.g. when you have functions
operating on a group of closely related types, which cannot sensibly be
implemented knowing only one of the types' internals. Thus
orthogonalising types and modules is a definite plus.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
 as kids, we would all be running around in darkened rooms, munching
 magic pills, and listening to repetitive electronic music."
 - Kristian Wilson, Nintendo Inc.
-------------------
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] productivity improvement

[John Max Skaller]

Andreas Rossberg wrote:

>
>No. That's one of the things OO ideology gets wrong. Making the type the
>unit of encapsulation is much too inflexible. Often you want to
>encapsulate several types simultanously, e.g. when you have functions
>operating on a group of closely related types, which cannot sensibly be
>implemented knowing only one of the types' internals. Thus
>orthogonalising types and modules is a definite plus.
>
Yes. When I read OOSC (Meyer), I thought it was pretty good science.
I still do, because one can pinpoint the error to the decision to map
both modules and types onto the class construction.

 From a category viewpoint, however,
it is obvious OO is limited and gets a fundamental idea completely wrong:
in OO, methods are used to abstract a type from its representation,
and the coding is *intrinsic*, that is, 'inside the object' which is called
encapsulation.

But in the categorical model, the types are simple points
with no properties at all: the 'type' structure is *extrinsic*.
The beauty of the categorical model is that the semantics
of the 'types' can be determined entirely without
specifying any encoding of the functions!
It is necessary only to specify how they compose.

Anyhow, this is why I think OO is a waste of time as a 'paradigm':
it get the fundamental answer to the question completely wrong.
The question, of course is:

    how do we represent abstractions?

Ocaml modules are not right either, but they're much
better answer in general.

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




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

Re: [Caml-list] productivity improvement

[Brian Rogoff]

William Lovas writes:
> It strikes me that although you were able to quite easily translate this
> toy evaluator example into C++, this may not have been the case with a
> larger, more complex example. 

Even this toy example was not really translated into C++. Translating OCaml 
functions, which can be closures, to C style function pointers, is a cheat. 
To be accurate, you need to model these as C++ functors (yes, I hate that 
terminology but that's what Stroustrup uses) to simulate closures. This is 
inevitably a pain, because simulating nested functions in a lexically
scoped language means that the object constructor has to have the variables 
that the "execute" function uses explicitly passed in. 

> It's something that scales exponentially, so you're probably not going to 
> find very many small, concise examples that show conclusively how much 
> easier O'Caml is. 

Actually, I think that there are quite a few.

Anyways, if you're interested in pursuing the extensibility question raised
here further, Jacques Garrigue wrote a nice little paper comparing sum types,
polymorphic variants, and classes on a simple evaluator example. 

http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/fose2000.html

-- 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] productivity improvement

[Eray Ozkural]

On Friday 19 July 2002 19:35, Brian Rogoff wrote:
> To be accurate, you need to model these as C++ functors (yes, I hate that
> terminology but that's what Stroustrup uses) to simulate closures. This is

You can just say "function object" instead. "Functor" in STL is abuse of 
terminology. The "functor" in caml makes mathematical sense since a functor 
goes from one category to another as we all know. :P

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] productivity improvement

[Alessandro Baretta]

Oleg wrote:

> P.S. Having read the CalTech tutorial and chapters 1-4 & 14 of the O'Reilly 
> book, and having gotten some experience with O'Caml, I'm running low on 
> motivation right now. Please give me examples of what's 
> hard/awkward/impossible in C++, but relatively easy in O'Caml, if any (I have 
> only finite time, so 50 KLOC Coq is not a good example :)

I am in the process of finishing up a simple XML stylesheet 
processor which formats ascii data for a line printer. Very 
simple. About 1000 odd lines of code in O'Caml. Would a 
project of this kind and size suit your interest? You might 
try to code a processor for the same dtd, so that we can 
measure di difference in "semantic density" of O'Caml and 
C++, within the limits of our respective abilities with the 
two languages (I'm not an O'Caml guru--yet...)

> P.P.S. My primary interest is statistical AI (artificial neural networks). I 
> haven't found any relevant libraries or applications in SML or O'Caml. That 
> is a bit discouraging.

I have a feeling that O'Caml was born out INRIA's need for a 
language to use in symbolic AI projects. The two worlds seem 
to be very difficult to reconcile.

> [1] And the example was hand-picked!
> [2] If one doesn't want "ad hoc" genericity, templates aren't necessary, of 
> course.

Ah! Wait a minute. I have another toy project I could 
propose to you: an interpreter for rule based language, à la 
CLIPS. 197 lines of code in ocaml, including comments. This 
is probably the kind of compelling example you are looking 
for. I coded it in 24 h, including time for sleep, nutrition 
and general self care.

Let me know if you are interested.

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] productivity improvement

[Oleg]

On Thursday 18 July 2002 09:25 pm, Alessandro Baretta wrote:

[...]

> Ah! Wait a minute. I have another toy project I could
> propose to you: an interpreter for rule based language, à la
> CLIPS. 197 lines of code in ocaml, including comments. This
> is probably the kind of compelling example you are looking
> for. I coded it in 24 h, including time for sleep, nutrition
> and general self care.
>
> Let me know if you are interested.

Sure, if it's really compelling, and if I won't have to guess the language 
specifications.

Thanks
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] productivity improvement

[Eray Ozkural]

On Friday 19 July 2002 04:25, Alessandro Baretta wrote:
>
> > P.P.S. My primary interest is statistical AI (artificial neural
> > networks). I haven't found any relevant libraries or applications in SML
> > or O'Caml. That is a bit discouraging.
>
> I have a feeling that O'Caml was born out INRIA's need for a
> language to use in symbolic AI projects. The two worlds seem
> to be very difficult to reconcile.
>

Interesting, but I still think ocaml maintains its superiority not only in 
traditional string and list processing but algorithmic prowess as well.

I have a feeling I can beat any ANN implementation written in C++ for that 
matter ;) I was writing a generic ANN library in C++ and found it to be quite 
difficult to put together different kinds of networks and algorithms in the 
same basket. It would really benefit from a well designed generic graph 
library which I can imagine would be possible only in a functional language.

Cheers,

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] productivity improvement

[Oleg]

On Tuesday 15 October 2002 05:31 am, Eray Ozkural wrote:

> I have a feeling I can beat any ANN implementation written in C++ for that
> matter ;) I was writing a generic ANN library in C++ and found it to be
> quite difficult to put together different kinds of networks and algorithms
> in the same basket. It would really benefit from a well designed generic
> graph library which I can imagine would be possible only in a functional
> language.

"Beat" in what sense? Should you decide to write an O'Caml ANN library that 
learns better or faster than PDP++, SNNS and Torch, I can't imagine anyone 
trying to keep you from doing it.

BTW BOOST has some sort of template graph library by Jeremy Siek.

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] productivity improvement

[Eray Ozkural]

On Tuesday 15 October 2002 15:34, Oleg wrote:
> On Tuesday 15 October 2002 05:31 am, Eray Ozkural wrote:
> > I have a feeling I can beat any ANN implementation written in C++ for
> > that matter ;) I was writing a generic ANN library in C++ and found it to
> > be quite difficult to put together different kinds of networks and
> > algorithms in the same basket. It would really benefit from a well
> > designed generic graph library which I can imagine would be possible only
> > in a functional language.
>
> "Beat" in what sense? Should you decide to write an O'Caml ANN library that
> learns better or faster than PDP++, SNNS and Torch, I can't imagine anyone
> trying to keep you from doing it.
>

I think better in the sense of extensibility, it could be made to allow more 
sophisticated learning algorithms or ANN models. It could be made just as 
efficient as any C code, or even faster who knows. Actually, what I have in 
mind is a general purpose machine learning library which has all the standard 
networks under the "ANN" module: single layer, multi layer feed forward 
(together with BP), hopfield and kohonen nets... I wrote all that in C++ for 
a grad course but I think it has its shortcomings, so I intend to rewrite it 
in ocaml so that I can have a convenient machine learning shell.

Nevertheless, it's an awful lot of work if you want to have your interfaces 
tidy.

> BTW BOOST has some sort of template graph library by Jeremy Siek.

Yes I know, but I prefer to use my own stuff. Even though that library is 
supposed to go into C++ standard some time in the future ;) I think C++ will 
be obsolete by then ;)


Here is some C++ client code for character recognition to give you a feel of 
the approach I have in mind. I would like to have an ANN library that is more 
generic than the one I crafted in C++ ;) Any ideas welcome.

  typedef Neuron< Bipolar_Sigmoidal_Custom > Neuron;
  typedef Sqr_Matrix<double,5> Matrix;
  typedef Matrix_Source< Matrix > Source;
  typedef pair<Source *, vector<double> > Training_Pair;

  // use a multi layered neural network
  Feed_Forward_Net<Neuron, Raw_Input_Neuron, Neuron> ff_net;

  // add hidden neurons initialized at small random values.
  for (int i=0; i<11; i++)
    ff_net.add_hidden(Neuron(Rand::rand_double(-0.005, 0.005), 0));
  // initialize with random values
  ff_net.init_random();

  // a square 5x5 matrix
  Matrix Amtx;

  // we now configure our network for ebp

  Source source(Amtx);
  ff_net.connect_input(source);
  ff_net.connect_output(10); // our coding requires ten outputs

  // the net has been put to required topology

  // read the training sets into this training pairs list
  vector< Training_Pair > pairs;

  // this is all hardwired, not much config
  // is required.

  list< Matrix* > matrices;
//   list< auto_ptr<Matrix> > matrices;
  list< Source > sources;
  for (int character = 0; character < 10; character++) {
    ostrstream name_stream;
    name_stream << "data/char-" << character  << ".txt" << ends;
    ifstream file_in( name_stream.str()  );
    // 4 patterns each
    for (int i = 0; i<4; i++) {
      Matrix *Amtx = new Matrix;
      matrices.push_back( Amtx );
      sources.push_back( Source(*Amtx) );
      vector<double> desired = cons_max(10, character);
      pairs.push_back( Training_Pair(&sources.back(), desired) );
      file_in >> *Amtx;
    }
  }

  // train the network with this data
  // the learning coefficient is 0.02
  CPU_Time start_time;
  ff_net.train(pairs, 0.02, 0.00002, 100000);
  cout << "Trained in " << CPU_Time() - start_time << endl;

  // voila
  nlog << ff_net << endl;

  // now testing with the original training set
  list< Source >::iterator source_it = sources.begin();
  int correct_results = 0;
  for (int character = 0; character < 10; character++) {
    cout << "testing character " << character << endl;
    for (int i = 0; i<4; i++) {
      ff_net.compute(*source_it++);
      vector<double> result_vec(10);
      for (int res=0; res<10; res++)
        result_vec[res] = ff_net.output_layer[res].read();
      double result =select_max(result_vec);
      cout << "  pattern " << i
           << " : " << result << endl;
      if (result == character)
        correct_results++;
    }
  }
  double train_success = double(correct_results) / 40 * 100;
  cout << "Training success is " << train_success << "%" << endl;

and so forth...

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] productivity improvement

[Emmanuel Renieris]

On Thu, Jul 18, 2002 at 07:14:06PM -0400, Oleg wrote:
> Please give me examples of what's 
> hard/awkward/impossible in C++, but relatively easy in O'Caml, if any (I have 
> only finite time, so 50 KLOC Coq is not a good example :)

I can tell you what I found problematic with C++ but those would be
_my_ problems, not yours. (Remember in the Hitch Hiker's Guide To The
Galaxy, where  pretending you are somebody else's problem makes you
invisible?)

Back at the beginning of this thread, you said that you ported some
small personal utilities, and that you saw no productivity improvement.
You postulated some reasons:
1) You were using the same imperative style
2) your knowledge of O'Caml is rudimental
3) there is no productivity enhancement
4) there is no productivity enhancement the programs you were 
   translating
5) there is no productivity enhancement for small programs in general.

Based on your posted C++ code, I will add a sixth one: you know C++
so well that few things seem hard in it.

I see two ways to weed through this list: 
Tell us what _you_ find hard/awkward/impossible in C++. Maybe somebody
will be able to point out how they are easier in Ocaml (if indeed they
are).
Show us some of your ocaml code. Maybe there is some idiom you don't 
have yet, and that would make a difference.

> P.P.S. My primary interest is statistical AI (artificial neural networks). I 
> haven't found any relevant libraries or applications in SML or O'Caml. That 
> is a bit discouraging.

If the FFI is not enough for you, then this comes into the productivity 
equation. There is also a section of the humps where you can state your wishes.
The language-libraries issue is a chicken and egg problem, but things
should get better with time. I'm not so sure that it's possible to reach the 
size of the C-syntaxed languages, but Python (and, I hear, Perl) did it,
so there is a chance.

-- Manos
-------------------
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] productivity improvement

[Oleg]

On Friday 19 July 2002 12:42 am, Emmanuel Renieris wrote:
> I see two ways to weed through this list:
> Tell us what _you_ find hard/awkward/impossible in C++. Maybe somebody
> will be able to point out how they are easier in Ocaml (if indeed they
> are).

The first thing that comes to mind: a program that would read, write, listen, 
look, speak, comprehend and pass the Turing test seems to be hard to create 
in C++. So hard, I've never tried[1] I'm not sure if it's the language 
though, although it could be.

> Show us some of your ocaml code. Maybe there is some idiom you don't
> have yet, and that would make a difference.

Since this is the second time I'm asked, I will have to do that, even though 
the program is really straight-forward, silly and uninstructive. Description 
first, code at the end: Sometimes, when I feel like being organized and 
productive[2], which happens no more than thrice per fortnight, I plan things 
to do in advance and estimate time it will take me to do them: I edit a file 
containing a list of tasks and time in minutes, e.g.

<stdin>
finish reading chapter 13 of ocaml book 30
Determine Dr. Leroy's involvement in JFK assassination 180
call dad 20
have supper 20
Go through T&R level in Halo in Legendary mode 30000
</stdin>

The program reads it from STDIN, calculates completion times and formats 
everything into a neat HTML table in STDOUT. I have a bash alias that glues 
VIM, this program and browser together, of course.

Oleg

[1] I'm not kidding. It really is hard.
[2] And I actually am much more productive when I do that

-------------------------------------------------------
let print_aux hours minutes = 
    if hours < 10 then print_char ' ';
    print_int hours;
    print_char ':';
    if minutes < 10 then print_char '0';
    print_int minutes;;

let print_time m =
    let m = m mod (60*24) in
    let hours = m / 60 in
    let hours = hours mod 24 in
    let hours = if hours > 12 then hours - 12 else hours in
    let tag = if m >= 12*60 then "pm" else "am" in
    let minutes = m mod 60 in
    print_aux hours minutes;
    print_string tag;;
    
let print_duration m =
    let hours = m / 60 in
    let hours = hours mod 24 in
    let minutes = m mod 60 in
    print_aux hours minutes;;

let curr_time = 
    let tmp = Unix.localtime (Unix.time ()) in
    tmp.Unix.tm_min + 60 * tmp.Unix.tm_hour;;

let isdigit = function '0' | '1' .. '9' -> true | _ -> false;;

let split_string s = 
    let i = ref (String.length s - 1) in
    while !i >= 0 && (s.[!i] = ' ' || s.[!i] = '\t') do i := !i-1 done;
    while (!i >= 0) && (isdigit (s.[!i])) do i := !i-1 done;
    i := !i+1;
    String.sub s 0 !i, int_of_string (String.sub s !i (String.length s - 
!i));;

let print_table_entry name duration curr_time = 
    print_string ("\t<tr><td align=left>" ^ name ^ "</td><td align=right>");
    print_duration duration;
    print_string "</td><td align=right>";
    print_time (curr_time + duration);
    print_string "</td></tr>\n";;

print_string "<html>
<title> Schedule </title>
<body bgcolor=\"#773333\" text=\"#00ff00\">
<table border=\"2\">\n";;

let rec read_and_print curr_time =
    let s = input_line stdin in
    let (s, v) = split_string s in
    print_table_entry s v curr_time;
    read_and_print (curr_time + v) 
in try
    read_and_print curr_time
with
    _ -> ();;

print_string "</table>
</body>
</html>\n";;
-------------------
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] productivity improvement

[Alessandro Baretta]

Oleg wrote:
> On Friday 19 July 2002 12:42 am, Emmanuel Renieris wrote:
> 
>>I see two ways to weed through this list:
>>Tell us what _you_ find hard/awkward/impossible in C++. Maybe somebody
>>will be able to point out how they are easier in Ocaml (if indeed they
>>are).
> 
> 
> The first thing that comes to mind: a program that would read, write, listen, 
> look, speak, comprehend and pass the Turing test seems to be hard to create 
> in C++. So hard, I've never tried[1] I'm not sure if it's the language 
> though, although it could be.

To think of it, I never tried running the hundred meter dash 
  in 9.50s... Did anyone ever pass the Turing test anyway?

>>Show us some of your ocaml code. Maybe there is some idiom you don't
>>have yet, and that would make a difference.
> 
> 
> Since this is the second time I'm asked, I will have to do that, even though 
> the program is really straight-forward, silly and uninstructive. Description 
> first, code at the end: Sometimes, when I feel like being organized and 
> productive[2], which happens no more than thrice per fortnight, I plan things 
> to do in advance and estimate time it will take me to do them: I edit a file 
> containing a list of tasks and time in minutes, e.g.
> 
> <stdin>
> finish reading chapter 13 of ocaml book 30
> Determine Dr. Leroy's involvement in JFK assassination 180
> call dad 20
> have supper 20
> Go through T&R level in Halo in Legendary mode 30000
> </stdin>
> 
> The program reads it from STDIN, calculates completion times and formats 
> everything into a neat HTML table in STDOUT. I have a bash alias that glues 
> VIM, this program and browser together, of course.
> 
> Oleg
> 
> [1] I'm not kidding. It really is hard.
> [2] And I actually am much more productive when I do that
> 
> -------------------------------------------------------
> let print_aux hours minutes = 
>     if hours < 10 then print_char ' ';
>     print_int hours;
>     print_char ':';
>     if minutes < 10 then print_char '0';
>     print_int minutes;;

let print_aux h m = printf
   (if minutes < 10 then "%2d:0%1d" else "%2d:%2d") h m

One line vs. 5

> let print_time m =
>     let m = m mod (60*24) in
>     let hours = m / 60 in
>     let hours = hours mod 24 in
>     let hours = if hours > 12 then hours - 12 else hours in
>     let tag = if m >= 12*60 then "pm" else "am" in
>     let minutes = m mod 60 in
>     print_aux hours minutes;
>     print_string tag;;

let print_time m = print_aux
   (m mod 60) (m / (60*24) mod 12);
   print_string
     (if m mod (60*24) >= 12*60 then "pm" else "am")

3 vs. 8

If you continue to program more or less the same way you 
would in C you cannot notice any improvement. The language 
is functional. Don't think in terms of assignments. Don't 
redefine an identifier (hours). Use functions: apply them to 
expressions. You ought to think in terms of computations as 
opposed to operations.


I have no more time now. Good bye.

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] productivity improvement

[Daniel de Rauglaudre]

> > let print_aux hours minutes = 
> >     if hours < 10 then print_char ' ';
> >     print_int hours;
> >     print_char ':';
> >     if minutes < 10 then print_char '0';
> >     print_int minutes;;
> 
> let print_aux h m = printf
>    (if minutes < 10 then "%2d:0%1d" else "%2d:%2d") h m

let print_aux = printf "%02d:%02d"

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
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] productivity improvement

[Alessandro Baretta]

Daniel de Rauglaudre wrote:
>>>let print_aux hours minutes = 
>>>    if hours < 10 then print_char ' ';
>>>    print_int hours;
>>>    print_char ':';
>>>    if minutes < 10 then print_char '0';
>>>    print_int minutes;;
>>
>>let print_aux h m = printf
>>   (if minutes < 10 then "%2d:0%1d" else "%2d:%2d") h m
> 
> 
> let print_aux = printf "%02d:%02d"

You're a real O'Caml Jedi. Type inference be with you!

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] productivity improvement

[Xavier Leroy]

> Determine Dr. Leroy's involvement in JFK assassination 180

Should take less time than this, given that I wasn't born at that time :-)

As everyone else, I'll point out that your code can be shortened and
made more readable by judicious use of printf and regexps (see below).
But really, if this is the kind of programs you're interested in
(text-based I/O with no data structures), forget about C++ and Caml,
and use Perl.

- Xavier Leroy

open Printf

let print_time m =
  let hours = (m / 60) mod 24 and minutes = m mod 60 in
  printf "%2d:%02d%s"
         (if hours > 12 then hours - 12 else hours)
         minutes
         (if hours > 12 then "pm" else "am")

let print_duration m =
  let hours = (m / 60) mod 24 and minutes = m mod 60 in
  printf "%2d:%02d" hours minutes

let re = Str.regexp "\\(.*\\)[ \t]+\\([0-9]+\\)$"

let split_string s =
  if Str.string_match re s 0
  then (Str.matched_group 1 s, int_of_string (Str.matched_group 2 s))
  else failwith "bad line"
-------------------
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] productivity improvement

[Eray Ozkural]

On Friday 19 July 2002 14:10, Xavier Leroy wrote:
> > Determine Dr. Leroy's involvement in JFK assassination 180
>
> Should take less time than this, given that I wasn't born at that time :-)
>
> As everyone else, I'll point out that your code can be shortened and
> made more readable by judicious use of printf and regexps (see below).
> But really, if this is the kind of programs you're interested in
> (text-based I/O with no data structures), forget about C++ and Caml,
> and use Perl.
>

Definitely so.

Also "portage" from C/C++ cannot automatically result in a productivity 
enhancement for obvious reasons. A straightforward port will preserve
the painstaking style of those languages.

For truly enhancing the quality of code the first step I take is to design
the program to benefit from the higher level of abstraction and modularity
modern functional languages provide for.

Especially using generic data types work very well. In ocaml you can really 
write algorithms that work on generic structures, which is good for cutting 
down code size and getting to the point. Using the module system, one can 
clearly decompose the code into interfaces and implementations...

For instance in a stock market prediction code I have been working on, it took 
no more than a couple of days to rewrite a large portion of the code in 
Haskell that was previously written in C. The resulting code was 
significantly shorter and more modular; allowing me to play with new 
algorithms / metrics easily. The same would not be the case with C++. (The 
code isn't too Haskell specific and could be done as well in ocaml)

That code I think went down from about 2500 lines to 500 lines which isn't 
bad. To attain that kind of improvement, you need a change in style. The C 
program apparently used lots of text I/O to transfer and store data between
modules. The Haskell program didn't have to.

It is also true that it is not correct to expect such improvements in code 
that is too simple. If all you want to do is to sum over an array of 
integers, you can do it in C easily.

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] productivity improvement

[Pal-Kristian Engstad]

On Tuesday 15 October 2002 02:24 am, Eray Ozkural wrote:
> For instance in a stock market prediction code I have been working on, it
> took no more than a couple of days to rewrite a large portion of the code
> in Haskell that was previously written in C. The resulting code was
> significantly shorter and more modular; allowing me to play with new
> algorithms / metrics easily. The same would not be the case with C++. (The
> code isn't too Haskell specific and could be done as well in ocaml)

I've found Haskell's use of IO monads to be "interesting", but terribly 
restricting and hard to understand. I do like their operator and function 
overloading mechanisms though - I wish Ocaml would have something similar (it 
just gets tedius having to add a "." in every floating point calculation). 
I've also had problems with converting stateful programs into Haskell.

> That code I think went down from about 2500 lines to 500 lines which isn't
> bad. To attain that kind of improvement, you need a change in style. The C
> program apparently used lots of text I/O to transfer and store data between
> modules. The Haskell program didn't have to.

That's strange. How could the Haskell program not have to do IO?

> It is also true that it is not correct to expect such improvements in code
> that is too simple. If all you want to do is to sum over an array of
> integers, you can do it in C easily.

Now, that is very true.

PKE.
-- 
  _       
  \`.       Pål-Kristian Engstad, Senior Software Engineer,
   \ `|     Naughty Dog, Inc., 1315 3rd Street Promenade, 
  __\ |`.   Santa Monica, CA 90046, USA. (310) 752-1000 x799. 
    /  /o   mailto:engstad@naughtydog.com http://www.naughtydog.com
   /  '~    mailto:mrengstad@yahoo.com    http://www.engstad.com
  / ,'      Go hang-gliding!
  ~'

-------------------
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] productivity improvement

[Eray Ozkural]

On Tuesday 15 October 2002 21:47, Pal-Kristian Engstad wrote:
>
> > That code I think went down from about 2500 lines to 500 lines which
> > isn't bad. To attain that kind of improvement, you need a change in
> > style. The C program apparently used lots of text I/O to transfer and
> > store data between modules. The Haskell program didn't have to.
>
> That's strange. How could the Haskell program not have to do IO?
>

Like many UNIX C codes, each module in the C code was a separate executable 
storing intermediate results in ASCII files. That is a good programming style 
for not so simple C codes because:
1) C is terribly hard to debug
2) C programs are easy to break
3) It's very hard to implement complex/dynamic data structures in C
And so on

However, in a functional language I can afford to implement those data 
structures to handle everything in-core. The reliability of the language 
helps me to keep it relatively bug-free, and it's very easy to write 
functions that accomplish complex tasks. I tried to do the same with C++ but 
it would result in meaningless container classes (like for each session, 
stock, stock market, etc.) and glue code.

That kind of thing is what I mean by change of style. If you do not change 
style, your program is not going to differ too much. You have to use the 
powerful features of the functional language to your advantage for gaining 
the edge.

It's pretty much like the old arguments about C vs. C++. Well you can write 
code that is just like C code in C++. There isn't much point in doing so, and 
still you can see incompetent programmers going all printf, atoi and int 
a[100] in C++.

You can even write assembly-style code in C++, but what purpose would that 
serve?

So if you're not using higher-order functions, recursive types, etc. in your 
program, your program is *not* really functional.[+] It is often quite 
*impossible* to translate a program in functional style to C++ without 
significant loss of quality and performance, ie. your code size is going to 
blow up to a factor of 2-3 at least and performance is going to suck.[|]

In addition, I shouldn't have to mention how useful an interpreter can be 
while developing complex applications like machine learning. With C++, you 
would cringe at never-ending compilations and SIGSEGVs... With your
ultra-hip functional language you don't work that way. Talk about 
productivity.

After all, we all know how the "functional paradigm" was addressed in the C++ 
standard: by a severely deficient imitation of (1st class?) functions through 
templates. Sorry, but I can't afford my code to look anywhere similar to STL. 
Using the standard lib for those data structures and algorithms may be okay, 
but writing something like STL itself is a big NO-NO.

I think to understand how futile that exercise is, every C++ programmer must 
undertake an impossible-in-C++ project.

Here is one for you: write a general purpose parallel array library with
syntax similar to that of blitz, should implement efficient parallel 
algorithms for a large class of topologies. That was the project which led me 
to conclude that C++ was *not* fitting for generic programming....

Nobody should ever write code like the following snippet, yet I suspect 
intermediate C++ programmers would be delighted by the looks of it: "Wow it 
looks just like part of the standard library" How great! What a big bunch of 
crap! Just imagine you are trying to add a new feature to this kind of code, 
you have to change like hundreds of template parameters, signatures and 
functions....

That project was a difficult piece of C++ trickery after which I concluded 
that C++ was not the right language to implement such a system. I also wrote 
that down in the report. There was simply no way it could be done without 
making it an enormous portion of spaghetti. (Supporting 
distributions/alignments a la HPF was virtually impossible)

There are many academic projects in the field of scientific computing with 
similar goals. Just try to compile them or understand a bit of the 
implementation.

-------------------------------- awful C++ code.....

template <typename _Expression> template <typename RHS_Gen_Expr>
Gen_Expr< Array_Add_Expression<_Expression,
  typename Object_Traits<RHS_Gen_Expr>::Expression> >
Gen_Expr<_Expression>::operator+ (const RHS_Gen_Expr& gen_right)
{
  typedef typename Object_Traits<RHS_Gen_Expr>::Expression RHS;
  typedef Array_Add_Expression<Expression,
    typename Object_Traits<RHS_Gen_Expr>::Expression> Add_Expression;
  typedef Gen_Expr<Add_Expression> Gen_Add;

  RHS right = Object_Traits<RHS_Gen_Expr>::reference
    (const_cast<RHS_Gen_Expr&>(gen_right));

//   nlog << node_str << *this << " + " << right << endl;
  Gen_Add return_expr(Add_Expression(expression, right));
  return return_expr;
}

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

[+] You don't really have to use lists everywhere, that's LISP not ocaml.
[|] Don't bring up ghc's poor performance in this discussion, think ocaml

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] productivity improvement

[Diego Olivier Fernandez Pons]

    Bonjour,

I do not understand very well why are you arguing, or is there anyone
in this list who is not convinced that Caml (and functional languages)
are more suited for any complex work than C/C++ (and other imperative
languages) ?

> Sorry, but I can't afford my code to look anywhere similar to STL.
> Using the standard lib for those data structures and algorithms may
> be okay, but writing something like STL itself is a big NO-NO.

When I wrote Baire, I read a lot of data structures and algorithms
code in other languages (C, C++, Java, SML, Haskell, Lisp, Scheme).

Compared with all those libraries, Baire is :
- much more complex (more algorithms and data structures)
- cleaner
- smaller
- easier to maintain and debug

It is faster than Java, SML, Haskell, Lisp and Scheme librairies
(since Caml is faster than all these languages and Baire uses same or
better algorithms), and we have good reasons to believe that it is at
least as fast as C++ code when you choose a data structure more suited
to the data you are manipulating (which Baire offers but STL/LEDA does
not)

Moreover, I wrote it in a few month and did it alone

Finally, Baire has not yet said its last word since it is only a
pre-release

Does anyone need more evidence ?

> Here is one for you: write a general purpose parallel array library with
> syntax similar to that of blitz, should implement efficient parallel
> algorithms for a large class of topologies. That was the project which led me
> to conclude that C++ was *not* fitting for generic programming....

C++ in not fitting for any kind of programming and there is no need of
such a specific application to demostrate it.


        Diego Olivier

-------------------
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] productivity improvement

[Jeffrey Palmer]

Hello all. I have a request.

Can we please cease the C++ flamefest? Some of us are not able to choose 
our implementation language quite as easily as others, and, frankly, 
endless discussions about language X's failings just irritate the 
people that are forced to use X daily. Making blanket statements like 
"language X clearly isn't good for anything" is just ridiculous - 
nothing is ever that clear cut. 

If we were to talk about the aspects of C++ (or Java, or ...) that we 
could apply to ocaml, that might be a different story (there might not 
be many!)

For my part, I'm under the impression that cross-module functor 
specializations (terminology?) in ocaml, akin to C++ template 
instantiation, are not optimized in the same manner as C++ templates 
(compiled away). Is this true? This is a killer for me, as I can't even 
afford the overhead of a function call (don't ask).

I would love to be able to write my product in ocaml, and plop a C++ 
wrapper on top of it, but practicalities unfortunately make this an 
impossibility. I need to do things similar to Blitz, which I suppose 
dooms me to template hell. ;)

	- j

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

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

Re: [Caml-list] productivity improvement

[brogoff]

On Thu, 17 Oct 2002, Jeffrey Palmer wrote:
> Hello all. I have a request.
> 
> Can we please cease the C++ flamefest? Some of us are not able to choose 
> our implementation language quite as easily as others, and, frankly, 
> endless discussions about language X's failings just irritate the 
> people that are forced to use X daily. Making blanket statements like 
> "language X clearly isn't good for anything" is just ridiculous - 
> nothing is ever that clear cut. 

Right, it's also kind of silly because OCaml is an imperative language, so 
flames like "imperative languages suck" belong on the Haskell, Clean, and 
Mercury mailing lists, but not here! 

> If we were to talk about the aspects of C++ (or Java, or ...) that we 
> could apply to ocaml, that might be a different story (there might not 
> be many!)

Sure, you've probably nailed the most popular one, which is doing C++ 
style compilation by monomorphizing everything. I doubt this will happen in 
OCaml because it is a research vehicle for research in language design, 
and that implementation strategy makes lots of things hard in a language like 
OCaml. This where the "Standard" in SML is somewhat meaningful, as some 
researchers in that community have focused on those kind of optimizations. 

There was a recent thread on this, here 

http://caml.inria.fr/archives/200202/msg00055.html

-- 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] productivity improvement

[Diego Olivier Fernandez Pons]

    Bonjour,

> people that are forced to use X daily. Making blanket statements like
> "language X clearly isn't good for anything" is just ridiculous -
> nothing is ever that clear cut.

We are not responsible of the design mistakes your company may have
done.

> This is a killer for me, as I can't even afford the overhead of a
> function call (don't ask).

If what you need is real speed you should better try a 2 stages Caml/C
solution, like the FFTW (fastest fourier transformation in the west
which produces C code from a Caml function) or using CIL
(Infrastructure for C Program Analysis and Transformation).

It will be cleaner, easier to maintain, much more portable and ...
FASTER ! (you should read Matteo Frigo's papers on the subject)

- FFTW home page : www.fftw.org
- CIL home page : http://manju.cs.berkeley.edu/cil/

        Diego Olivier

-------------------
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] productivity improvement

[Francois Pottier]

> For my part, I'm under the impression that cross-module functor 
> specializations (terminology?) in ocaml, akin to C++ template 
> instantiation, are not optimized in the same manner as C++ templates 
> (compiled away). Is this true?

It is true. However, a source-to-source transformer is being developed
at Orsay which statically unfolds functor applications, eliminating
this overhead, and suppressing the antagonism between modularity and
efficiency. As far as I have heard, it should be released `real soon
now'.

-- 
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/
-------------------
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