(no subject)

[Nikolaj Bjorner]

[-- Attachment #1: Type: text/plain, Size: 3060 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6062 bytes --]

[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

[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

[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

[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