On Fri, 3 Aug 2001, Johann Spies wrote:

> Thank you to everyone that replied. I have realized now that it is not
> that easy to start programming in ocaml (or a functional language)
> when you are an amateur and coming from a procedural/imperative
> programming background.

 Why? Your falut is very common! I was a Lisp and Scheme programmer
with a years of experience when I started to use ML, and I had same
problems. Static typing is not so common... ;)

> Maybe Sylvain summarized my problems with his questions:
>
> > There are many different things in your code. Answering to some
> > questions might help you:
> > + what is the type of lys?
> > + what is the type of the elements of lys?
>
> I am not sure about the difference between these two questions.

 The second one specifies type as a list or any other *set of elements*.
The first question is much more generic.

> I realised my mistake that lys was a char list and I expected wys_dit to
> print strings.

 Another mistake was that your function produced a useless unit list.

> > + what is the type of wys_dit?
>
> As I understand it wys_dit is a function.  I always thought of
> functions as using types not necessarily having types.

 It's a main point of functional programming. Function is a first-class
object, as generic as integers, etc. E.g. function from integer to integer
is an element of a set, specified by the type (int -> int). And, sure,
there could be a function with a type ((int -> int) -> int) which takes
the first function as a parameter.

> > + how many parameters do you want for wys_die_lys?
>
> I thought it needed one, originally, but it did not work, so I tried a
> second.  At least the interpreter did not complain.  Another response
> to my question, explained why I did not see an interpreter complaint.

 Compiler guessed a type of your function from a case of it's usage.

> No, I did not see that.  I do not always understand the messages of
> the interpreter.

 It's just a type of your expression. Always.

> > But the easiest way is:
> >
> > let wys_die_lys = List.iter print_string;;
>
> In this function, there is no explicit parameter.  Where is this
> behaviour documented?

 Just check it's type, and you'll understand all.
# let wys_die_lys = List.iter print_string;;
val wys_die_lys : string list -> unit = <fun>

 List.iter have a type ('a -> unit) -> 'a list -> unit.
print_string  takes one string argument, and, as it is a first argument
of List.iter, it binds 'a to string.
So, compiler knows exactly, that the right part of expression is a
function from string list to unit, and let ... = expression just binds it
to the name wys_die_lys.

> > + do you expect wys_dit to return a result?
> I did.

 And your result was a unit list - list of NULLs ;)

> > + what type for that result?
> A printed string.

 It's not a result. It's a side effect.

> > + what is the exact meaning of the :: operator?
>
> I am not sure.  I could not find an explanation for it.  I have just
> now searched the "operator" section of the ocaml-manual for :: again
> and could only find :
>
>      type 'a list = [] | :: of 'a * 'a list

 As you can see from a definition, :: is a list constructor. "cons", if
you know lisp.

> > I would recommend not to use print_string as long as
> > you're not comfortable with the language; writing purely
> > functional code (no side effects) will be easier.
>
> I have always used print statements in programs to help me with
> debugging and to see what is going on (that is besides the necessity
> to get some output from the program). A program with no side effects
> does not make sense to me.  What is the use of it?

 What use? Result of the function. Any program is just a function from
input to output, without side-effects.

> As you can see, these questions revealed my lack of understanding of
> some of the basics.  I suspect the only way to get to understand it is
> by reading, asking and trying.

 Please, try to read and understand this lectures:
http://www.cl.cam.ac.uk/Teaching/Lectures/funprog-jrh-1996/index.html


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr