[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

[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

[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

[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

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

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

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] 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: 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: [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] 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] 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 ?

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

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

[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

[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

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

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

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

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

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

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

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

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

[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: 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: 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] 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

[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

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

[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] 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 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] 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] 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 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: [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

[Dave Berry]

At 09:00 15/07/2002, Ohad Rodeh wrote:
>The previous incarnations of the system were written in C. Comparing
>line-counts for similar modules we got a 7:1 reduction when using OCaml.

I'm rather sceptical of line-counts as a measurement of overall
productivity, but that's still an impressive improvement.  For constrast,
Andrew Appel wrote the sample compiler for his textbook in C, SML and Java,
and found that SML was the most concise, but not by anything like 7:1.

>The resulting system was also a lot more stable and easier
>to maintain.

Now that I can believe!

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

[Ohad Rodeh]

The numbers for the Ensemble group communication
(www.cs.cornell.edu/Info/Projects/Ensemble),
where more like 7:1, instead of 2:1.

The previous incarnations of the system were written in C. Comparing
line-counts for similar modules
we got a 7:1 reduction when using OCaml. The resulting system was also a
lot more stable and easier
to maintain.

This would counteract the notion of Caml being good only for producing
compilers.

      Ohad.

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

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


                                                                                                                                  
                      Dave Berry                                                                                                  
                      <daveb@tardis.ed.ac.uk        To:       Markus Mottl <markus@oefai.at>, Oleg <oleg_inconnu@myrealbox.com>   
                      >                             cc:                                                                           
                      Sent by:                      Subject:  Re: [Caml-list] Re: productivity improvement                        
                      owner-caml-list@pauill                                                                                      
                      ac.inria.fr                                                                                                 
                                                                                                                                  
                                                                                                                                  
                      14/07/2002 23:44                                                                                            
                      Please respond to 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




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