(no subject)

[Johann Spies]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: multipart/mixed; boundary="Frank Atanassow <franka@cs.uu.nl>, Francois.Pottier@inria.fr,", Size: 5553 bytes --]

Frank Atanassow <franka@cs.uu.nl>, Francois.Pottier@inria.fr,
    Basile.Starynkevitch@cea.fr, Benedikt.Rosenau@dlr.de,
    Wolfgang Lux <lux@wi.uni-muenster.de>,
    Stefano Lanzavecchia <stf@apl.it>,
    Sebastien Briais <sbriais@ens-lyon.fr
Subject: Re: [Caml-list] Please help a newbie
References: <87lml2a896.fsf@#maties.sun.ac.za> <3B6949D5.784BAC9F@xrce.xerox.com>
From: Johann Spies <jspies@maties.sun.ac.za>
Date: 03 Aug 2001 10:58:03 +0000
In-Reply-To: Sylvain Pogodalla's message of "Thu, 02 Aug 2001 14:38:45 +0200"
Message-ID: <87g0b98l6s.fsf@#maties.sun.ac.za>
Lines: 132
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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.

My knowledge of the theory of programming is not good.  I started
programming as a hobby using Basic, Pascal, Dbase III, a little bit of
Prolog and for the past few years, Python.

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.  I
realised my mistake that lys was a char list and I expected wys_dit to
print strings.

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

> + do you think wys_dit is able to print one element of lys?

Answered above.

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

> + do you see the interpreter answers that it "expects" two
>   parameters?

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

> + can you compare the function f1 and f2 such that:
> let f1 x = match x with
> | [] -> print_string "empty list";print_newline()
> | h::t -> print_string "not empty list";print_newline();;
> let f2 = function 
> | [] -> print_string "empty list";print_newline()
> | h::t -> print_string "not empty list";print_newline();;
> + how many parameters do they need?

Maybe this is what I am struggling to understand.  I can not see how
f2 can work.  What data does it use?

Related to this is what Benedikt referred to:

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

Francois Thomasset's remark on the same topic also underlines my lack
of understanding of the handling of arguments a function:

> 2/ your wys_die_lys has 2 arguments, as can be seen from the
> signature val wys_die_lys : 'a -> string list -> unit list = <fun>
> (the system deduced the string list type for the type of the second
> argument from the call to print_string in wys_dit).



> + do you expect wys_dit to return a result?
I did.
> + what type for that result?
A printed string.
> + 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

>From that I suspect that :: is an alternative for [] - telling the
compiler that the tipe is a list?

I tried to figure out what it does by reading examples of it's use.


> + do you really want to build a unit list, as the type of wys_die_lys
> describes ?

No.  I am do not see the of what use a "unit list" can be. 

Some of you also helped me to see the necessity of flushing the
output:

> You need to flush stdout or print_newline; also the function
> wys_die_lys does not need to return a unit list but just a unit;

Someone wrote:

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

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.

I have not responded to everything. I appreciate all the help, remarks
and code sent to me and I will probably ask some more questions in the
future.

Johann
-- 
Johann Spies          Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch

     "Love is patient, love is kind. It does not envy, it
      does not boast, it is not proud. It is not rude, it is
      not self seeking, it is not easily angered, it keeps
      no record of wrongs. Love does not delight in evil but
      rejoices with the truth. It always protects, always
      trusts, always hopes, always perseveres." 
                                I Corinthians 13:4-7 
-------------------
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

[Caml-list] Re: your mail

[Francois Pottier]

> Someone wrote:
> 
> > 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?

I am the one who wrote that, so I'll clarify. Clearly, you are right
in thinking that `real' programs must have side effects. However, the
interactive environment (also known as the `toplevel loop') allows you
to evaluate expressions (that is, program fragments) which have no side
effects and to examine their result. This can be very useful. For
instance, consider the following interactive session:

  $ ocaml
	  Objective Caml version 3.02

  # let rec increment_list = function
    | [] ->
	[]
    | element :: rest ->
	(element + 1) :: (increment_list rest)
    ;;
  val increment_list : int list -> int list = <fun>
  # increment_list [1;2;3];;
  - : int list = [2; 3; 4]

Here, I have defined a function of one argument, which accepts an
integer list and returns a list where all elements have been
incremented by 1. The function has no side effects (it does not
print anything), yet you can easily test it and see how it works.

I hope this helps,

-- 
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/
-------------------
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

[Caml-list] Re: your mail

[Vitaly Lugovsky]

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

Re: [Caml-list] Please help a newbie

[md5i]

Johann Spies <jspies@maties.sun.ac.za> writes:

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

I wouldn't say that it is difficult, so much that there are some new
concepts to be learned.

> 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.  I
> realised my mistake that lys was a char list and I expected wys_dit to
> print strings.

>From your session:

  # let lys = ['a';'b';'c'];;
  val lys : char list = ['a'; 'b'; 'c']

Based on this we can say that the type of lys is a char list, and the
type of the elements of lys is char.  ('a', 'b', and 'c' are the
elements of lys).

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

Even in C, you can think of functions as having a type.  A function's
type encompasses its arguments and its retrn value.  Let's look at
wys_dit:

  # let wys_dit woord = print_string woord;;
  val wys_dit : string -> unit = <fun>

According to the interpreter, the type of wys_dit is string -> unit.
This means that it is a function which takes as an argument a string
and returns a value of type unit.  (BTW, in OCaml, the type unit is
sort of equivilent to C's void.)

>> + 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.
> 
>> + do you see the interpreter answers that it "expects" two
>>   parameters?
> 
> No, I did not see that.  I do not always understand the messages of
> the interpreter.

Okay.  Let's take a look:

  # let rec wys_die_lys l = function
      [] -> []
          | h :: t -> wys_dit h ::    wys_die_lys l t;;
  val wys_die_lys : 'a -> string list -> unit list = <fun>

Okay, the interpreter says that the type of wys_die_lys is 
'a -> string list -> unit list

The simplest explanation of this is that wys_die_lys is a function
that takes two arguments, one of which is of any type ('a), and the
second of which is a list of strings.  It returns a list of units.
Why is this?  Primarily because you are misusing the function
keyword.  This is not surprising; function can be a confusing special
case to the beginner.  More explained below:

>> + can you compare the function f1 and f2 such that:
>> let f1 x = match x with
>> | [] -> print_string "empty list";print_newline()
>> | h::t -> print_string "not empty list";print_newline();;
>> let f2 = function 
>> | [] -> print_string "empty list";print_newline()
>> | h::t -> print_string "not empty list";print_newline();;
>> + how many parameters do they need?
> 
> Maybe this is what I am struggling to understand.  I can not see how
> f2 can work.  What data does it use?

The thing is, function defines a function which takes one argument,
and does pattern matching on it. You don't see the argument above
because it is implicit.  Until you understand this, use the first
pattern above which uses match.

> Related to this is what Benedikt referred to:
> 
>> 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?

Okay, here is where I tell you that something I said above is a white
lie.  A function with a signature of 'a -> string list -> unit list
does not really take two arguments.  It actually takes one.  The type
could be rewritten as:

'a -> (string list -> unit list)

I.e., it is a function which takes an argument of any type, and
returns a function that takes a string list and returns a unit list.
Whew!  Guess what?  You are learning about what is called "Currying".
Let's use a simple example to explain.

  # let add (a, b) = a + b;;
  val add : int * int -> int = <fun>
  # add (1, 2);;
  - : int = 3

Okay.  Here add is a function with the type signature 
  int * int -> int
This means it takes a pair of ints and returns an int.  In FP
parlance, int * int is a touple of two ints.  int * string would be a
touple of an int and a string, and 'a * 'b * 'c would be a touple of 3
items of types 'a, 'b, and 'c.  So, in practice, the function plus
above takes a single argument which just happens to be two ints, and
returns an int.  Okay, lets look at a very similar function:

  # let plus a b = a + b;;
  val plus : int -> int -> int = <fun>
  # plus 1 2;;
  - : int = 3

Okay, here we have a slightly different function.  It has the
following type signature:
  int -> int -> int
As we can see, it seems to take two int arguments and returns an int.
But there is a little more going on here than that.

  # let plusone = plus 1;;
  val plusone : int -> int = <fun>

Okay, what is going on here?  We are calling the plus function, but we
are only calling it with one argument!  How does this work?  Well, in
Caml, all functions really only take one argument. Lets look at the
type signature again, only let's add some parenthesies to make things
clearer: 

int -> (int -> int)

plus is a function which takes an int, and returns a function which
takes an int and returns an int.  Above, when we defined plusone, we
called plus with the int 1, and got back a function which takes and
int and returns an int.  This is sometimes called partial function
application.  Let's try it out.

  # plusone 2;;
  - : int = 3

Tadah!  When you are calling making a function call like plus 1 2,
this is actually interpreted as ((plus 1) 2), i.e., call the function
returned by plus 1 with the argument 2.

Now, let's return to Sylvain's suggestion:

>> let wys_die_lys = List.iter print_string;;

  # List.iter;;
  - : f:('a -> unit) -> 'a list -> unit = <fun>

Okay, the type of List.iter is 
('a -> unit) -> 'a list -> unit
[You can forget about the f:() stuff for now.  These are labels, and
we can discuss those in another message.]  Let's interpret this type.
List.iter takes as an arguemnt a function which takes an argument of
any type ('a), and returns a function which takes an argument of a
list of that type ('a list), and returns unit.  Wow.  That's a bit
complicated.  Now let's look at the type of print_string.

  # print_string;;
  - : string -> unit = <fun>

That was simple enough.  print_string takes an argument of type
string, and returns unit.  Now, if you remember, List.iter takes as
it's argument a function from any type to unit.  Let's use
print_string as the argument to List.iter.

  # let wys_die_lys = List.iter print_string;;
  val wys_die_lys : string list -> unit = <fun>

Now wys_die_lys is a function which takes a string list as an
argument, and returns a unit.  this is exactly what you would have
gotten if you plugged in the signature from print_string into the
signature for List.iter above.  As for what List.iter does, we will
have to refer to the manual.  List.iter takes a function and a list of
items, and will apply that function to each of the items in order.
Hence, wys_die_lys will take a list of strings and call print_string
on each one.

Whew!  My fingers are tired.  I'll let you think about the above
before I try to reply to the rest of your post.  I hope this has
helped a little.

-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)
-------------------
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

Re: [Caml-list] Please help a newbie

[John Max Skaller]

md5i@cs.cmu.edu wrote:
> 
> Johann Spies <jspies@maties.sun.ac.za> writes:

>(BTW, in OCaml, the type unit is
> sort of equivilent to C's void.)

	As an aside: in Felix, there are two types,
unit (which has a single value, the empty tuple),
and void, which has no values. The two are
distinct (indeed, dual): unit is the categorical terminal, void
is the categorical initial.

	In Ocaml, the categorical initial also exists,
thanks to polymorphic variants:

	type void = [] 

It is my contention that the type of procedures is wrong
in ocaml precisely because they return unit, when they
_should_ be returning void (that is, nothing).

An example of the kind of thing this typing
permits is:

	let f () = print_endline "Hi" in
	f ( f() )

This works, because the type of f is 

	unit -> unit

instead of what it should be:

	unit -> void

I note that the sequencing operator ; in such a system
can't work correctly with the type

	(;): unit -> unit -> unit

used in Ocaml. It can't be translated to

	(;): void -> void -> void

but has to be translated to

	(;): (unit->void) -> (unit->void) -> (unit->void)

which means the result is never actually executed.
You need 

	(;;): unit->void->void

for that, and call it a stamement: statements can 
be concatenated, there cannot be a 'functional'
way to execute statements in sequence, which provides
a division between expressions and statements.

I'm experimenting with a coherent syntax for this
in Felix (which distinguishes expressions from statements,
and functions from procedures).

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net
-------------------
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

empty type (was [Caml-list] Please help a newbie)

[Hendrik Tews]

   
   	In Ocaml, the categorical initial also exists,
   thanks to polymorphic variants:
   
   	type void = [] 
   
   It is my contention that the type of procedures is wrong
   in ocaml precisely because they return unit, when they
   _should_ be returning void (that is, nothing).
   
So what typing rules do you use for the empty type? Usually a
type theory is inconsistent as soon as one has an inhabitant of
the empty type.

Bye,

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

Re: empty type (was [Caml-list] Please help a newbie)

[John Max Skaller]

Hendrik Tews wrote:

>    It is my contention that the type of procedures is wrong
>    in ocaml precisely because they return unit, when they
>    _should_ be returning void (that is, nothing).
> 
> So what typing rules do you use for the empty type? Usually a
> type theory is inconsistent as soon as one has an inhabitant of
> the empty type.

	Felix has statements and expressions. The typing
rule is:

	f:T -> void,  a:T 
	|- f a: void

Note that 'f a' cannot occur inside an expression, indeed,
it isn't an expression but a statement.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net
-------------------
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

[Caml-list] Re: your mail

[Mike Potanin]

On Thu, 6 Feb 2003, Nikolaj Bjorner wrote:

> I am pretty sure this is not related to references, but to let-rec.
>
> Try:
>
> let rec f x = x and g y = f y + 1;;
>
> you will see that the type inferred is:
>
> val f : int -> int
> val g : int -> int
>
> Now try:
>
> let f x = x and g y = f y + 1;;
      ^                 ^
This is different functions. First "f" defined new function. Second "f"
referred to old function "f".

>
> this time:
>
> val f : 'a -> 'a
> val g : int -> int
>
> You may still be wondering why, of course.
> The basic answer (I hope I am not too rusty in this)
> is that type inference for polymorphic let-rec is not decidable
> (you have to solve a semi-unification problem).
> Hence, the "solution" is not to abstract type variables
> until all type inference for all
> let-rec-and clauses have been analyzed.
>
> So:
>
> let rec f x = x and g y = f y + 1 and h z = not (h z);;
>
> does not type check at all, but again:
> let f x = x and g y = f y + 1 and h z = not (h z);;
> does work.
>
>
> Nikolaj
>
>
>
>
> From: Chris Hecker [mailto:checker@d6.com]
> Sent: Thu 2/6/2003 5:31 PM
> To: caml-list@inria.fr
> Subject: [Caml-list] streams and value restriction
>
>
>
>
> I assume I'm running into the polymorphism restriction thing here, but
> I'm not sure why (I kind of understand it when references are in play,
> but this is baffling me).
>
> Here's a simple version of some stream parser code.  I'd like
> parse_opt_comma_list to be polymorphic so I can use it to parse lists
> of any of my values.  It works fine as a separate let rec, but if I
> put it in the overall let rec of the main parser (with and) it won't
> generalize and gets tagged as string-only since that's the first way
> it's used.
>
> Can somebody explain why this is a problem?  Sorry for being dense.
>
> Thanks,
> Chris
>
>
> type t =
>     Int of int
>   | String of string
>
> (* this works: *)
> let rec parse_opt_comma_list parse list = parser
>     [< 'Genlex.Kwd ",";
>        a = parse ;
>        optlist = parse_opt_comma_list parse (a::list) >] -> optlist
>   | [< >] -> list
>
> let rec parse_values = parser
>     [< 'Genlex.String s;
>        optlist = parse_opt_comma_list (parser [< 'Genlex.String s >] -> s) [] >] ->
>          (String s) :: List.map (fun s -> String s) optlist
>   | [< 'Genlex.Int i;
>        optlist = parse_opt_comma_list (parser [< 'Genlex.Int i >] -> i) [] >] ->
>          (Int i) :: List.map (fun i -> Int i) optlist
>
> (* this doesn't: *)
> let rec parse_values = parser
>     [< 'Genlex.String s;
>        optlist = parse_opt_comma_list (parser [< 'Genlex.String s >] -> s) [] >] ->
>          (String s) :: List.map (fun s -> String s) optlist
>   | [< 'Genlex.Int i;
>        optlist = parse_opt_comma_list (parser [< 'Genlex.Int i >] -> i) [] >] ->
>          (Int i) :: List.map (fun i -> Int i) optlist
>
> and parse_opt_comma_list parse list = parser
>     [< 'Genlex.Kwd ",";
>        a = parse ;
>        optlist = parse_opt_comma_list parse (a::list) >] -> optlist
>   | [< >] -> 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
>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug 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: your mail

[Markus Mottl]

On Tue, 22 Jan 2002, Daniel de Rauglaudre wrote:
> You can create a file, "foo.ml" holding:
>     Topdirs.dir_directory "+contrib";;
> 
> compile it and add "foo.cmo" in your ocamlmktop command line. For Camlp4,
> it is not necessary, because it has beeen already added in the toplevel
> directory path in OCaml version 3.04.

Thanks for this trick! Maybe it should be also mentioned in the docs?

Regards,
Markus Mottl

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

Re: [Caml-list] Re: your mail

[Daniel de Rauglaudre]

Hi,

On Mon, Jan 21, 2002 at 11:43:36PM +0100, Markus Mottl wrote:

> This should probably be an FAQ: toplevels do not remember include-paths
> of libraries linked with them. This means that you have to explicitly
> tell your toplevel where to find the module interfaces (.cmi-files), e.g.:
> 
>   ocamlunx -I +camlp4 -I +contrib

You can create a file, "foo.ml" holding:
    Topdirs.dir_directory "+contrib";;

compile it and add "foo.cmo" in your ocamlmktop command line. For Camlp4,
it is not necessary, because it has beeen already added in the toplevel
directory path in OCaml version 3.04.

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

[Caml-list] Re: your mail

[Markus Mottl]

On Tue, 22 Jan 2002, cgillot@gruposbd.com wrote:
>   I don't know whether this is a ocaml problem or a pcre-ocaml
> problem, but the point is that although I manage to generate a 
> toplevel with pcre-ocaml linked by doing :
> 
> ocamlmktop -o ocamlunx -I +camlp4 -I +contrib unix.cma str.cma pcre.cma camlp4o.cma
> 
> When I try to do a :
> #open Pcre;;
> or to use a function with its full-qualified name a "Unbound module" message.

This should probably be an FAQ: toplevels do not remember include-paths
of libraries linked with them. This means that you have to explicitly
tell your toplevel where to find the module interfaces (.cmi-files), e.g.:

  ocamlunx -I +camlp4 -I +contrib

Only then can you reference modules in those libraries. Maybe this should
be mentioned in chapter 9.5 of the manual?

Regards,
Markus Mottl

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

[Caml-list] Re: your mail

[Brian Rogoff]

(Note: Please Pierre, come back, this list needs moderation!)  

The answer is in the INSTALL file at the top level of the source
distribution.

INSTALLATION INSTRUCTIONS
1- Configure the system. From the top directory, do:
...
-tkdefs <cpp flags>             (default: none)
-tklibs <flags and libraries>   (default: determined automatically)
...

Find out where your Tcl stuff is installed and configure with the correct
options. 

-- Brian

On Tue, 6 Mar 2001, rakesh malhotra wrote:

> hi:
> 	I get the following error when trying to install OCaml on a sun
> sparc station.
> 
> 	Please help.
> 
> thanks
> 
> rakesh
> 
> 
> Options for linking with X11: -cclib -lX11
> NDBM found (in /usr/include)
> Configuring LablTk...
> tcl.h not found.
> Configuration failed, LablTk will not be built.
> 
> ** Configuration summary **
> 
> Directories where Objective Caml will be installed:
>         binaries.................. /usr/local/bin
>         standard library.......... /usr/local/lib/ocaml
>         manual pages.............. /usr/local/man/man1 (with extension .1)
> Configuration for the bytecode compiler:
>         C compiler used........... gcc
>         options for compiling..... -fno-defer-pop -Wall -Wno-unused
>         options for linking.......  -lcurses -lnsl -lsocket -lm
> Configuration for the native-code compiler:
>         hardware architecture..... sparc
>         OS variant................ solaris
>         C compiler used........... gcc
>         options for compiling..... -Wall -Wno-unused
>         options for linking.......  -lcurses -lnsl -lsocket -lm
>         assembler ................ $(AS) 
>         preprocessed assembler ... gcc -c -DSYS_$(SYSTEM)
>         profiling with gprof ..... not supported
> Source-level replay debugger: supported
> Configuration for the external libraries:
>         libraries supported ...... unix str num dynlink bigarray threads
> graph dbm
> The "num" library:
>         target architecture ...... supersparc-solaris
> The "graph" library:
>         options for compiling .... 
>         options for linking ...... -cclib -lX11
> The "labltk" library: configuration failed
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr