Re: [Caml-list] Easy solution in OCaml?

[Brian Hurt <brian.hurt@qlogic.com>]

On Sun, 27 Apr 2003, Siegfried Gonzi wrote:

> It is often very comfortable to use this sort of bad hacking, because in 
> science when you develop new functions or tries to solve problems you 
> often do not know in advance what you want and not.
> 
> For example: function1 has as return: erg1 = (list (list 2 3 4))
> 
> function2 expects output from function1  and function2 uses this output 
> as follows:
> 
> (list-ref  erg1 0)
> 
> But now I decide for reason of its own that erg1 should include just one 
> more information:
> 
> erg1 = (list1 (list 2 3 4)  (list (vector 2 3 4) "nice day"))
> 
> function2 now is not affected because it always uses the first element 
> of the list, but it dramatically shortens your development time, because 
> you do not have to cope with other structures or tuples in erg1 as you 
> would do lets say in Clean. And you do not have to change  all your 
> other dependencies.

It allows you to ignore the bug.  And it may not bite you.  But that 
doesn't mean it's still not a bug.  Otherwise, you need to define what 
"nice day"/3 is.

Although it's looking like you want to use tuples, not lists.  It's 
perfectly valid, in ocaml, to do:

[ 2; 3; 4 ], ( [| 2; 3; 4 |], "nice day" )

Tuples are sort of a lazy man's structure.  Or you can actually define a 
structure- which has the advantage that you can reference members by name, 
and ignore members you don't care about.  So you might want to do:

type foo_t = { datalist : int list ; 
               datavector : int array ; 
               otherinfo : string
             };;

let get_foo : ... -> foo_t = fun ... -> ... ;;

(* All I want to deal with is the int list- ignore the rest *)
    let mylist = (get_foo ...).datalist
    in ...

This allows you to add elements to the structure foo_t and the above code 
will simply ignore them.

> 
> This was the reason to ask in my first post of the topic are there any 
> guys out there who successfully use OCaml for data evaluation or lets 
> call it statistic (which means reading files, coping with array and 
> lists and that sort of). Maybe the aforementioned bad feature of 
> Scheme/Lisp/Python... makes them that usefull for coping with "dynamic" 
> data.

It lets you program by coincidence.  Which may be forgivable for a 
throw-away program, but it's still a bad idea.  Nothing is as permanent as 
that which is called temporary.

> 
> This also  leads to the question: is development time really reduced in 
> (strict typed) functional programming, or is it only reduced when you 
> compare quicksort in Haskell and the verbose version in C.
> 

I'm a C pro.  It's been my main language for more than a decade now.  I
mean, I know what a sequence point is- and why they exist.  I'm an ocaml
newbie, I've only been coding in Ocaml for a couple of months now, and I'm
still learning the language (so my code is likely not going to be the best
example of how to do things in Ocaml).  But I'm already at least as
efficient in Ocaml than I am in C, in terms of correct behaviors per hour
of work.

There are lots of reasons for this, but one of the big ones is the type
checking system plus type inference.  I have, on occasion, had to stare at
an ocaml error message for upwards of ten minutes to figure out what was
wrong.  As I become more familiar with ocaml, such "puzzler" errors are
becoming less and less frequent.  If I have to fire up a debugger,
reproduce the problem, and figure out what the problem is, ten minutes is
closer to the minimum.  The worst bug I've ever had to track down took me
a solid *month* of 60-hour weeks to figure out (and resulted in a two-line
change in the code).  So every bug, every problem, the compiler can find
for me is an incredible time savings and an incredible productivity boost.

Yes, I compile with warnings on.  All of them.  And treat warnings as 
errors.  And no, my code doesn't have signifigantly more typedefs than 
normal code does- because even in my C code I think about what types 
things should be.  Loop variables are not implicitly an int, for example 
(actually, size_t is the most common loop variable type in my code).  If 
the variables are the correct type to begin with, you don't need to 
typecast them.

With type inference, most of the bondage & discipline aspects of strong
typing (that we all learned to hate with languages like Pascal and Java)
are gone.  You get all the benefits of strong typing without the
annoyances.  Let the compiler figure out what types things should be.

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