headers
Juergen Pfitzenmaier | 1 Feb 2001 04:13
Picon

make and large projects

Dear ocaml users,
the following is loosly connected with the discussion a few days ago on
structuring large projects and the use of make in this list.

2 years ago I evaluated several tools  that claim to replace make. Two of
them  seemed the most promising: cook and cons; but I wasn't content with
them.  So I considered writing my own.  But then my interests shifted and
the people I was working with at that time didn't seem too interested and
so the project died.
I still have some of the papers from that project and I believe that a group
of 3-4 could write a good replacement for make in reasonable time.

Q: So what is missing ?
A: Programmers with experience in building large, complex projects who 
   want to change the way projects are build. I need someone to talk to
   to clarify my ideas.

You will say these people are easy to find. I have met many programmers
complaining about make but the pain was not deep enough to make them
really think about alternatives.
If someone wants to discuss make replacements please write to me.

-- pfitzen
Permalink | Reply | 0 comments |
headers
Juergen Pfitzenmaier | 1 Feb 2001 01:37
Picon

# and polymorphic variants

Dear ocaml users,
consider the following example:

type t1 = [ `A of int ];;
type t2 = [ `B of string ];;
type t = [ `A of int | `B of string ];;

let f1 (`A (x : int)) =
	print_int x
and f2 (`B (x : string)) =
	print_string x
and f (x : t) =
	match x with
	| #t1 -> f1 x      (* this is not allowed !! *)
	| #t2 -> f2 x;;

The compiler can't constrain the type t of x to t1/t2 in the call to f1/f2.
And an coercion like in
    ...
	match x with
	| #t1 -> f1 (x :> t1)
    ...
is not allowed. So I see only one solution:
    ...
	match x with
	| #t1 -> f1 (Obj.magic(x) :> t1)   (* I don't like magic *)
    ...
But I would like to see something clean like giving a name to the # pattern
    ...
	match x with
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andreas Rossberg | 1 Feb 2001 10:58
Picon

Re: NaN Test in OCaml

Christian Lindig wrote:
> 
> George Russell <ger <at> informatik.uni-bremen.de> has suggested on
> comp.lang.ml the following test to find out whether a float is NaN:
> 
>         x is not a NaN <=> (x = x)
> 
> Doing this leads to interesting results with OCaml 3.0:
> 
>     # let nan x = not (x = x);;
>     val nan : 'a -> bool = <fun>
>     # nan (1.0 /. 0.0);;
>     - : bool = false            (* correct *)
>     # nan (0.0 /. 0.0);;
>     - : bool = false            (* should be true *)
> 
> The following definition of nan uses a type annotation and has a
> different result:
> 
>     # let nan (x:float) = not (x = x);;
>     val nan : float -> bool = <fun>
>     # nan (0.0 /. 0.0);;
>     - : bool = true             (* correct *)
>     # nan (1.0 /. 0.0);;
>     - : bool = false            (* correct *)

Right, because the first example uses polymorphic equality which is
purely structural. The second uses proper floating point comparison.

Actually, what we have here, is a subtle kind of overloading. Subtle in
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Mentre | 1 Feb 2001 10:19
Picon
Picon
Favicon

Re: NaN Test in OCaml

Hi Christian,

I'm far from being at the level of Caml implementors but:

Christian Lindig <lindig <at> eecs.harvard.edu> writes:

>     # let nan x = not (x = x);;
>     val nan : 'a -> bool = <fun>
                ^^ here you have a polymorphic equality test
>     # nan (1.0 /. 0.0);;
>     - : bool = false            (* correct *)
>     # nan (0.0 /. 0.0);;
>     - : bool = false            (* should be true *)
> 
> The following definition of nan uses a type annotation and has a
> different result:
> 
>     # let nan (x:float) = not (x = x);;
>     val nan : float -> bool = <fun>
                ^^^^^ here we know that we have floats
>     # nan (0.0 /. 0.0);;
>     - : bool = true             (* correct *)
>     # nan (1.0 /. 0.0);;
>     - : bool = false            (* correct *)
> 
> Is this a bug or a feature? Anyway, I guess this again shows the subtleties
> of equality.

I would say a feature. As Xavier said in his mail[1], if the compiler
knows that in *every case* we have a float, it generates a float
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michel Mauny | 1 Feb 2001 17:34
Picon
Picon
Favicon

Re: Consortium Caml

[ This is a slightly edited version of my reply to David McClain, that
  I forgot to Cc: to the list. ]

David,

David McClain wrote/écrivait (Jan 31 2001, 09:50AM -0700):

> I have read the consortium agreement, and I fail to understand the
> difference between options A and B, aside from expense. You state at several
> places in the agreement that choice of support option does not imply any
> specific rights or advantages. So why would anyone care to follow option B?

I understand your concern, and I have to admit that this isn't simple
to explain. Experience will tell us wether those two options should be
merged into one (saying "at least 2 KEuros") or not.

You are right in saying that there is no formal difference between
options A and B. Actually, what has to be understood is that being a
member of the Caml Consortium has two meanings:

  - being a member of a (identified) users group (with meetings, and
    where members may compare their needs). A kind of "first circle"
    around implementors, providing a minimal financial support to
    INRIA in order to have a sexier web site, to organize meetings, and
    (maybe, depending on the number of members) to have some more
    developments done. This corresponds to option A.

    If there are enough "A members", then that's fine: we should be
    able to have all this done. For instance, if we have 25 or 30
    A-members, we could hire an engineer for doing the extra
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrzej M. Ostruszka | 1 Feb 2001 10:50
Picon
Picon

Re: # and polymorphic variants

On Thu, Feb 01 (2001), Juergen Pfitzenmaier wrote:
> and f (x : t) =
> 	match x with
> 	| #t1 -> f1 x      (* this is not allowed !! *)
> 	| #t2 -> f2 x;;
> 
> The compiler can't constrain the type t of x to t1/t2 in the call to f1/f2.

What about alias patterns? The following seems to work:

type t1 = [ `A of int ]
type t2 = [ `B of string ]
type t = [ `A of int | `B of string ]

let f1 (`A x) = print_int x
and f2 (`B x) = print_string x
and f (x : t) = match x with
        | #t1 as a -> f1 a
        | #t2 as b -> f2 b
						Best regards
--

-- 
    ____   _  ___
   /  | \_/ |/ _ \		Andrzej Marek Ostruszka
  / _ |     | (_) | Instytut Fizyki, Uniwersytet Jagiellonski (Cracow)
 /_/ L|_|V|_|\___/	(PGP <-- finger ostruszk <at> order.if.uj.edu.pl)
Permalink | Reply | 0 comments |
headers
Laurent Reveillere | 1 Feb 2001 11:58
Picon
Picon

Can not compile with ocamlopt when using str lib.

I have the following error message when trying to produce native code

ocamlopt -a -o faultmisc.cmxa  str.cmxa faultmisc.cmx
/opt/prog/ocaml-3.00/lib/ocaml/str.cmxa
is not a compilation unit description.

Any idea?

--

-- 
Laurent
Permalink | Reply | 0 comments |
headers
Damien Doligez | 1 Feb 2001 14:31
Picon
Picon
Favicon

sondage / opinon poll

Hello,

I'm thinking of making a small change to the Gc module in the standard
library in order to get rid of the overflow problems with the
allocation counters.

In the current version of O'Caml, the GC returns its statistics as
values of type int, but some of these values can easily go over 1G,
leading to overflow and useless statistics (except on 64-bit machines).

The plan is to change these values to float, affording 53 bits of
precision instead of the current 31 (or 63 on 64-bit machines).  The
values affected would be:
- the fields minor_words, promoted_words, major_words in the stat record,
- all three fields of the result of the counters function,
- the result type of allocated_bytes.

Now the question is, do we just change these, or do we need to keep
the current version of the functions for backward compatibility, and
add new functions with the new types ?

If you use these functions, please drop me a note saying whether you
would be greatly inconvenienced by an incompatible change in their
types.

-- Damien
Permalink | Reply | 0 comments |
headers
Xavier Leroy | 1 Feb 2001 14:57
Picon
Picon
Favicon

Re: Floating point array computations

> In sample code form the ICFP 200 contest I found:
> type v = float array
> is array a build in type?

Yes, it is.

> The functions main1 .. main4 below do the same but take different time for it
> (compiled with ocamlopt). I expected main2 to be the fastest but main3 is 
> fastest. main3 300 300 1000 takes on my PC (450 Mhz PI, 520 MB RAM) 
> 26 sec, this is about twice the time of C++ and about the same as Java.
> Can somone tell me why main3 is faster than main2 (36 sec) although
> main3 makes function calls to step?

Here are two possible explanations.  First, with modern processors,
minor variations in code placement (i.e. insert or delete unused code)
can result in performance improvements or degradations by as much as 20%,
due to cache effects, alignment constraints on instruction fetches,
and what not.  (Predicting accurately the performance of a processor
such as the PIII is extremely hard; a few Intel engineers are rumored
to be able to do it :-)

Second, on a register-poor architecture such as the IA32, spilling and
reloading (moving values between registers and stack locations)
happens often and has a significant performance impact.  Since OCaml
follows a callee-save model, function calls act as natural spill hint,
forcing all live registers to be spilled to the stack before the call,
then reloaded on demand after the call.

In your "main3" test, the function "step" runs in exactly the 7
available registers, thus the call to "step" causes a nearly perfect
(Continue reading)

Permalink | Reply | 0 comments |
headers
Xavier Leroy | 1 Feb 2001 15:22
Picon
Picon
Favicon

Re: ocamlyacc/ocamllex problems

> I am writing a parser that uses Parsing.rhs_start and Parsing.rhs_end in
> a rule.  The problem is the following,
> 
> 1) If I use a simple rule in the lexer that matches a token all is fine.
> ex:
>     |   "'" ['0' '1' '*' '.']+ "'"  { ... }
> 
> 2) If I use an automata in the lexer for matching the same token, the
> results of Parsing.rhs_start and Parsing.rhs_end are wrong.
> ex:	
>     | "'"  { ... bits lexbuf ... }
> and bits = parse
>     | '\'' { ... }
>     | ['0' '1' '.' '*' ] { ... }
>     | eof  { ... }
>     | _    { ... }
>
> I am not sure to undertand the reasons of my problem?

For terminal symbols (tokens), the locations returned by
Parsing.rhs_start and Parsing.rhs_end are those returned by
Lexing.lexeme_start and Lexing.lexeme_end.  However, these two
functions track the location of the *last* regular expression matched by
the ocamllex-generated automaton.  (This location is stored and
updated in place in the "lexbuf" argument.)

So, if your lexing rule recursively calls other lexing rules (as in
case 2 above), the locations reported correspond to the part of the
token that was last matched by a regular expression (i.e. the last
"bit" of the token in your example 2).
(Continue reading)

Permalink | Reply | 0 comments |

Gmane