[Caml-list] Why must types be always defined at the top level?

[Caml-list] Why must types be always defined at the top level?

[Richard Jones]

The subject says it all really.  Why do types need to be defined at
the top level of a module?  Why isn't it possible to define them in
some nested scope?

A practical example of where this is very useful is defining a
subroutine which uses a state machine.  I want to define the state
machine type close to the (nested) function which uses the type, not
somewhere near the top of the file.

Actual example:

type state_t = StartField
             | InUnquotedField
             | InQuotedField
             | InQuotedFieldAfterQuote

let load_rows f chan =
	(* ... *)
  let state = ref StartField in         (* Current state. *)
	(* ... *)
  let rec loop () =
    let c = input_char chan in
    if c != '\r' then (
      match !state with
          StartField ->
		(* ... *)
        | InUnquotedField ->            (* Reading chars to end of field. *)
		(* ... *)
        | InQuotedField ->              (* Reading chars to end of field. *)
		(* ... *)
        | InQuotedFieldAfterQuote ->
    ); (* end of match *)
    loop ()
	(* ... *)

In this example, it would be much more convenient to define the
start_t type within the load_rows function, since nothing outside this
function ever uses this state.

I realise of course that types might be returned from functions, but
surely the same thing happens when one module returns an abstract type
to another function?  Either this could be catered for in the same
way, or could be prevented.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MOD_CAML lets you run type-safe Objective CAML programs inside the Apache
webserver. http://www.merjis.com/developers/mod_caml/

-------------------
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] Why must types be always defined at the top level?

[Markus Mottl]

On Tue, 22 Jun 2004, Richard Jones wrote:
> The subject says it all really.  Why do types need to be defined at
> the top level of a module?  Why isn't it possible to define them in
> some nested scope?

But it is (using local modules):

  let f () =
    let module M = struct
      type t = Foo
    end in
    M.Foo = M.Foo

Note that you cannot return values such that the module name escapes
its scope.

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
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] Why must types be always defined at the top level?

[skaller]

On Wed, 2004-06-23 at 08:53, Markus Mottl wrote:
> On Tue, 22 Jun 2004, Richard Jones wrote:
> > The subject says it all really.  Why do types need to be defined at
> > the top level of a module?  Why isn't it possible to define them in
> > some nested scope?

>   let f () =
>     let module M = struct
>       type t = Foo
>     end in
>     M.Foo = M.Foo

But t is defined here 'at the top level of a module'.

> Note that you cannot return values such that the module name escapes
> its scope.

Which escapes me. Felix allows types to be defined
anywhere and also allows them to escape, it creates
no problem I'm aware of (except that you can't
name them without resorting to the typeof() operator).

I actually think there is some humour here:

Topic ---------------------Language X ------------ Language Y
Intermodule fun calls         Yes                       No
Intermodule type recursion    Yes                       No
Nest everything (excl funcs)  Yes                       No
Nest funcs                    No                        Yes
Full sep compil               Yes                       No
Platform indep code           No                        Yes

One of these languages is an FP, the other is 'a portable assembler'.
The portable assembler outperforms the FP on most FP like qualities,
but the FP code is actually portable .. [and like Bagley this
isn't a serious comparison :]

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Why must types be always defined at the top level?

[Andreas Rossberg]

skaller wrote:
> 
>>Note that you cannot return values such that the module name escapes
>>its scope.
> 
> Which escapes me. Felix allows types to be defined
> anywhere and also allows them to escape, it creates
> no problem I'm aware of (except that you can't
> name them without resorting to the typeof() operator).

I believe the presence of syntactic names for all generative types is 
essential for the theoretical underpinnings of OCaml's type and module 
system.

> Topic ---------------------Language X ------------ Language Y
> Intermodule fun calls         Yes                       No
> Intermodule type recursion    Yes                       No
> Nest everything (excl funcs)  Yes                       No
> Nest funcs                    No                        Yes
> Full sep compil               Yes                       No
> Platform indep code           No                        Yes

How did you arrive at that table? AFAICS, the right column contains too 
many No entries (intermodule function calls, full sep compilation), 
while the left contains too many Yes entries (nest everything, or rather 
compositionality is definitely not given for C/C++, full sep compilation 
neither - considering that you have to manually share some code in 
header files).

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

-------------------
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] Why must types be always defined at the top level?

[skaller]

On Wed, 2004-06-23 at 22:01, Andreas Rossberg wrote:

> I believe the presence of syntactic names for all generative types is 
> essential for the theoretical underpinnings of OCaml's type and module 
> system.

This may be so, but I still don't quite understand it.
In Felix generatives types all have fresh integers
assigned to them that act as fresh names: there's no 
separate compilation though. Does that have something
to do with it?

> > Topic ---------------------Language X ------------ Language Y
> > Intermodule fun calls         Yes                       No
> > Intermodule type recursion    Yes                       No
> > Nest everything (excl funcs)  Yes                       No
> > Nest funcs                    No                        Yes
> > Full sep compil               Yes                       No
> > Platform indep code           No                        Yes
> 
> How did you arrive at that table? 

With a sense of humour.. :)

> AFAICS, the right column contains too 
> many No entries (intermodule function calls, full sep compilation), 

Oh? Ocaml does not support forward calls of named functions
across compilation unit boundaries. C/C++ do. Ocaml does not
support arbitrary order of compilation. C/C++ do. I agree
it is not really right to call the C/C++ header file mechanism
true separate compilation though (since interfaces are recompiled
multiple times), but the fact is using the 'advertised' mechanism
you just don't have to worry about compilation order in C/C++.
You can 'chunk' your source as you see fit. In Ocaml you cant.
[Yet!]

> while the left contains too many Yes entries (nest everything, or rather 
> compositionality is definitely not given for C/C++, 

You are probably right. The table indicates this: working in 
C++ it is extremely annoying not having functions and their
scopes as first class .. such a relief to work with Ocaml.
But then suddenly things that 'just work' in C++ that you 
take as a 'given' turn out *not* to work in Ocaml.

Please note the table was not intended to be taken
seriously on a technical front. I have no doubt whatsoever
which language I prefer to work with :))

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Why must types be always defined at the top level?

[Andreas Rossberg]

skaller wrote:
> 
>>I believe the presence of syntactic names for all generative types is 
>>essential for the theoretical underpinnings of OCaml's type and module 
>>system.
> 
> This may be so, but I still don't quite understand it.
> In Felix generatives types all have fresh integers
> assigned to them that act as fresh names: there's no 
> separate compilation though. Does that have something
> to do with it?

Don't think so. That could be dealt with easily by a slightly more 
general stamping scheme.

However, a stamp based semantics is a purely operational approach and 
has no proper explanation in type theory. As a consequence, it does not 
scale well to more advanced module features (e.g. functors, particularly 
higher-order ones), and probably other corners of the type system.

And the lack of syntactic types makes communicating errors to the user 
harder...

> Oh? Ocaml does not support forward calls of named functions
> across compilation unit boundaries.

Granted, but then it said "intermodule fun calls", not "intermodule fun 
recursion" in your table.

> C++ it is extremely annoying not having functions and their
> scopes as first class .. such a relief to work with Ocaml.
> But then suddenly things that 'just work' in C++ that you 
> take as a 'given' turn out *not* to work in Ocaml.

It is not just nesting functions. Consider local namespaces, template 
namespaces, template typedefs, to name just a few illegal combinations. 
The ways in which the many constructions in C++ can be composed are 
restricted quite arbitrarily and often counter-intuitively.

> Please note the table was not intended to be taken
> seriously on a technical front.

That's understood. Still had to refute some of its more biased content. ;-)

Cheers,

	- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

-------------------
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] Why must types be always defined at the top level?

[skaller]

On Thu, 2004-06-24 at 02:28, Andreas Rossberg wrote:

> However, a stamp based semantics is a purely operational approach and 
> has no proper explanation in type theory. 

What has scoping got to do with it though?

In Felix there is a quirk where you can do this:

fun f():(1->t) * (t->0) = {
  type t = "int"; 
  fun a():t={ return 1; }
  fun b(x:t):0={ print_int x; }
}

The client of this function doesn't know the name 't',
and doesn't need to:

match f() with
| (?a, ?b) => { b(a()); }
endmatch;

There isn't anything in the binding algorithm
that would make this fail, and values of the
type can still be used.

Of course if a *value* nested in the function
escaped it would be a disaster. But a type is
always static, so you can just treat the function
scope as a module scope when it comes to types
I would have thought.

AFAICS 'type theory' is just another name for
basic category theory anyhow :)

> > Oh? Ocaml does not support forward calls of named functions
> > across compilation unit boundaries.
> 
> Granted, but then it said "intermodule fun calls", not "intermodule fun 
> recursion" in your table.

The issue isn't recursion per se: it's being able to call a function
defined in an arbitrary compilation unit. I should have said
inter-unit calls though.

> It is not just nesting functions. Consider local namespaces, template 
> namespaces, template typedefs, to name just a few illegal combinations. 

Yes, you're right.

> > Please note the table was not intended to be taken
> > seriously on a technical front.
> 
> That's understood. Still had to refute some of its more biased content. ;-)

There is a serious point there though. Ocaml is still quite quirky
in the same way as C++ is. I've run into quite a few annoyances,
like no local exceptions, cant mix recursive classes and types,
etc .. all have workarounds, but some are extremely ugly,
especially forward calling via reference hack. I just wouldn't
have expected that kind of problem in an FPL.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Why must types be always defined at the top level?

[skaller]

On Thu, 2004-06-24 at 06:21, skaller wrote:
> On Thu, 2004-06-24 at 02:28, Andreas Rossberg wrote:
> 
> > However, a stamp based semantics is a purely operational approach and 
> > has no proper explanation in type theory. 
> 
> What has scoping got to do with it though?
> 
> In Felix there is a quirk where you can do this:
> 
> fun f():(1->t) * (t->0) = {
>   type t = "int"; 
>   fun a():t={ return 1; }
>   fun b(x:t):0={ print_int x; }
> }

Woops .. i didn't mean to post this to caml list,
and there is a bug too .. forgot to return the nested
functions :)


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Why must types be always defined at the top level?

[John Hughes]

As I revise my course notes from SML/NJ to OCaml, I find myself asking
some design questions --- "Why did they do it THIS way?". I should
probably ask "Why is this way the right way to do it, regardless of 
the original motivation?," but let's assume the answers are the same. 

1. Why no eqtypes? The idea of having the type-checker verify that you
weren't doing equality testing on non-equality-testable types seemed 
like GOOD thing in SML, and I was surprised to see it gone. 

2. Why no "end" on "let" expressions, i.e., 

 let a = 3 and b = 2 in a + b;;

rather than 

 let a = 3 and b = 2 in a + b end; ?

3. Why semicolons for separating list items, so that 

  [2,3] is interpreted as [(2,3)] ? 

4. Why expose the hardware with float (and make it have equality
testing) rather than continue with "real" (which was not an eqtype, if
I recally correctly)? 

------------

I'm sure these were all good decisions, but I'd like to better
understand
them. 

-John Hughes

-------------------
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] Why must types be always defined at the top level?

[Andreas Rossberg]

John Hughes wrote:
> 
> 1. Why no eqtypes? The idea of having the type-checker verify that you
> weren't doing equality testing on non-equality-testable types seemed 
> like GOOD thing in SML, and I was surprised to see it gone. 

To cite Bob Harper: "Equality types are stupid and should have been 
dropped ages ago."

Unfortunately, nobody seems to have a satisfying alternative either.

	- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

-------------------
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] Why must types be always defined at the top level?

[Markus Mottl]

Andreas Rossberg schrieb am Donnerstag, den 24. Juni 2004:
> To cite Bob Harper: "Equality types are stupid and should have been 
> dropped ages ago."
> 
> Unfortunately, nobody seems to have a satisfying alternative either.

Well, you could use type classes as in Haskell, but this would interfere
with the philosophy of OCaml to have principal types for all expressions.

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
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] Why must types be always defined at the top level?

[Xavier Leroy]

> 1. Why no eqtypes? The idea of having the type-checker verify that you
> weren't doing equality testing on non-equality-testable types seemed 
> like GOOD thing in SML, and I was surprised to see it gone. 

Eqtypes have been hotly debated even among the SML designers.  My
feeling is that it's not worthwhile to have a special, hard-wired
mechanism in the type checker just for the sake of equality.  There is
a general need to have polymorphic operations that are 1- not defined on
all instantiations of their types, and 2- can be defined differently
on different instantiations.  Haskell type classes are an example of a
*general* mechanism that addresses this need; GCaml's "extentional
polymorphism" is another.  But SML's eqtypes are just not general at all.

> 2. Why no "end" on "let" expressions, i.e., 
> 
>  let a = 3 and b = 2 in a + b;;
> 
> rather than 
> 
>  let a = 3 and b = 2 in a + b end; ?

Ah, syntax...  Without entering in a debate on which syntax is "better",
let me just give an historical reason: there was no "end" on "let"
expressions in the original LCF ML, from which Le_ML, then the first
Caml, then Caml Light, then OCaml derive.  We don't like gratuitous
syntax changes :-)

> 3. Why semicolons for separating list items, so that 
> 
>   [2,3] is interpreted as [(2,3)] ? 

Why not?  Again, I guess this is historical.  Both SML and the various
Camls use two symbols "," and ";" to denote three different things
(tuples, lists and arrays, and sequence).  SML "overloads" the comma
to mean two of these things, Caml overloads the semicolon.

> 4. Why expose the hardware with float (and make it have equality
> testing) rather than continue with "real" (which was not an eqtype, if
> I recally correctly)? 

Unless a language offers exact-precision arithmetic on computable
reals, I strongly object to the use of the word "real" to refer to
what's merely floating-point numbers.  Floats aren't reals by any
stretch of the imagination, and the earlier the programmer realizes
this, the better.  

As to whether equality should be defined on floats, there are pros and
cons.  My standpoint is that it's eventually better to stick to
established standards (that is, IEEE float arithmetic) rather than try
to reinvent a wheel likely to be even squarer than these standards.
Prof. Kahan found it worthwhile to fully define equality over floats;
I'll abide by his wisdom.

- Xavier

-------------------
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] Why must types be always defined at the top level?

[John Hughes]

Thanks for the answers.  
> > 1. Why no eqtypes? 
> 
> Eqtypes have been hotly debated even among the SML designers. 
>  My feeling is that it's not worthwhile to have a special, 
> hard-wired mechanism in the type checker just for the sake of 
> equality.  

Agreed. One of our students, a year ago, after being told about
eqtypes, asked "is there something like 'numtype' too, so
that we can tell whether it's OK to do arithmetic?" (Recall
this was SML, where "+" is overloaded.) It was clear that
the idea *behind* eqtypes should be extended ... but the alternative,
of removing them entirely, is just as consistent, I suppose. 

> > 2. Why no "end" on "let" expressions, i.e.,
> [History]
> 
> > 3. Why semicolons for separating list items, so that
> > 
> >   [2,3] is interpreted as [(2,3)] ? 
> 
> [Why not?]

Fair enough. 
 
> > 4. Why expose the hardware with "float" ...
> 
> Unless a language offers exact-precision arithmetic on 
> computable reals, I strongly object to the use of the word 
> "real" to refer to what's merely floating-point numbers.  

This from someone who uses "int" to mean something other than
"integer"! :-)

> Floats aren't reals by any stretch of the imagination, and 
> the earlier the programmer realizes this, the better.  

Agreed. And deference to Bill Kahan is generally a good idea. 

---
I have one more question, though: 

5. Why can I no longer type-annotate things I've written, so that

let f x y z = (x = y) & (y = z)

defines a function applicable to ALL types? I actually *liked*
being able to say something like

let f x y z:int = (x = y) && (y = z)

so that it would be restricted to ints. (It frequently helped me to 
untangle cryptic error messages that ML produced, AND to document
my intent as I wrote code). I can still 
trick it into doing that, by something like

let f = function
  | (x,y,z) -> (x==y) && (y == z)
  | (a,b,_) -> (a-b) = 0;;

which will turn out to never invoke the second case, but still
restrict the 
type. But surely this is not more readable/maintainable code...(Yes, I
know
it has a slightly different signature, but I didn't have the heart to 
work around that just now). 

Thanks again for the informative answers. 

-John Hughes

-------------------
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] Why must types be always defined at the top level?

[David Brown]

On Thu, Jun 24, 2004 at 09:46:11PM +0200, John Hughes wrote:

> defines a function applicable to ALL types? I actually *liked*
> being able to say something like
> 
> let f x y z:int = (x = y) && (y = z)

You can, you just need parens:

  # let f x y (z:int) = (x = y) && (y = z)
  val f : int -> int -> int -> bool = <fun>

Dave

-------------------
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] Why must types be always defined at the top level?

[William D. Neumann]

On Thu, 24 Jun 2004, John Hughes wrote:

> This from someone who uses "int" to mean something other than
> "integer"! :-)

Ah, but "real" = "real", but "int" <> "integer".
/clutching at straws?

> 5. Why can I no longer type-annotate things I've written, so that
>
> let f x y z = (x = y) & (y = z)
>
> defines a function applicable to ALL types? I actually *liked*
> being able to say something like
>
> let f x y z:int = (x = y) && (y = z)
>
> so that it would be restricted to ints.

You can do this.  You just need to do:
# let f x y (z:int) = (x = y) & (y = z);;
val f : int -> int -> int -> bool = <fun>

What you have above is annotating f, not z.

William D. Neumann

---

"Well I could be a genius, if I just put my mind to it.
And I...I could do anything, if only I could get 'round to it.
Oh we were brought up on the space-race, now they expect you to clean toilets.
When you've seen how big the world is, how can you make do with this?
If you want me, I'll be sleeping in - sleeping in throughout these glory days."

	-- Jarvis Cocker

Think of XML as Lisp for COBOL programmers.

	-- Tony-A (some guy on /.)

-------------------
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] Why must types be always defined at the top level?

[Olivier Andrieu]

 William D. Neumann [Thu, 24 Jun 2004]:
 > On Thu, 24 Jun 2004, John Hughes wrote:
 > > 5. Why can I no longer type-annotate things I've written, so that
 > >
 > > let f x y z = (x = y) & (y = z)
 > >
 > > defines a function applicable to ALL types? I actually *liked*
 > > being able to say something like
 > >
 > > let f x y z:int = (x = y) && (y = z)
 > >
 > > so that it would be restricted to ints.
 > 
 > You can do this.  You just need to do:
 > # let f x y (z:int) = (x = y) & (y = z);;
 > val f : int -> int -> int -> bool = <fun>
 > 
 > What you have above is annotating f, not z.

Actually, it's annotating the return value of f (ie the right hand
side of the =). To annotate f, you have to use this syntax :

# let f x y z : bool = (x = y) & (y = z) ;;
val f : 'a -> 'a -> 'a -> bool = <fun>
# let f : int -> int -> int -> bool = fun x y z -> (x = y) & (y = z) ;;
val f : int -> int -> int -> bool = <fun>

-- 
   Olivier

-------------------
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] Why must types be always defined at the top level?

[Brian Hurt]

On Thu, 24 Jun 2004, John Hughes wrote:

> 
> 2. Why no "end" on "let" expressions, i.e., 
> 
>  let a = 3 and b = 2 in a + b;;
> 
> rather than 
> 
>  let a = 3 and b = 2 in a + b end; ?

Let doesn't need them- there are a lot of other places where Ocaml could 
use disambiguation.  Basically, I'm a beleiver that if there is a 
shift-reduce conflict in the obvious implementation of the grammar, there 
is a problem the programmer is going to trip over.

One big one- I wish if was ended with an endif or similiar.  How many 
times have you accidentally coded something like:

if x > 3 then
    printf "x = %d\n" x;
    x - 3
else
    x + 1

This is especially common when, like in my example, you're dropping in 
debug print statements.  Unfortunately, the semicolon at the end of the 
printf statement also ends the if statement.

> 
> 3. Why semicolons for separating list items, so that 
> 
>   [2,3] is interpreted as [(2,3)] ? 

How would I make a list of one element of type int * int?

> 
> 4. Why expose the hardware with float (and make it have equality
> testing) rather than continue with "real" (which was not an eqtype, if
> I recally correctly)? 

sqrt(2.);;

Mathematicians don't have a problem with dealing with an infinite number 
of decimal places.  Computers do.  You can hide some of the problems- at 
great cost in terms of performance and memory- but sooner or later you're 
going to deal with precision loss.

$ ocaml
        Objective Caml version 3.07

# 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1;;
- : float = 0.999999999999999889

Plus, all the comments I made about integers apply, and then some.  
Hardware based floating point is much faster than any software based 
floating point (even ignoring the infinities and nan problems).  Going to 
software base FP is easily 10x slower than hardware, possible (probably) 
more.  And doesn't really save you much of anything.

This is just pointing up, to me, why there is a difference between a 
teaching language and a production language.  As something looking at 
using Ocaml as a production language, I am opposed to even adding overflow 
detection on ints- in the few, minor places I need it, I'll either use 
larger integers, or I'll add in explicit checks myself.  But don't slow 
down even a little the vast majority of my integer operations.  This goes 
at least double for my floating point operations.

For a teaching language, I'd definately include integer overflow detection 
at the least, and would seriously consider making integers arbitrary 
precision.  I'd also strongly consider making floats software, but not so 
that I could increase precision, but so that I could decrease precision- 
numerical instability is a lot easier to demonstrate if you only have four 
digits of precision, and not 15.  But, then again, performance isn't a 
concern with a production language.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
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

Re: [Caml-list] Why must types be always defined at the top level?

[Brian Hurt]

On Thu, 24 Jun 2004, Xavier Leroy wrote:

> There is a general need to have polymorphic operations that are 1- not
> defined on all instantiations of their types, and 2- can be defined
> differently on different instantiations.  Haskell type classes are an
> example of a *general* mechanism that addresses this need; GCaml's
> "extentional polymorphism" is another.

Ocaml modules are another way to implement this.  Wether it's a "good" way 
or not is open to debate.

> As to whether equality should be defined on floats, there are pros and
> cons.  My standpoint is that it's eventually better to stick to
> established standards (that is, IEEE float arithmetic) rather than try
> to reinvent a wheel likely to be even squarer than these standards.
> Prof. Kahan found it worthwhile to fully define equality over floats;
> I'll abide by his wisdom.

There are legitimate reasons to want floating point equality.  It's 
generally not what you want, but I had an example of needing it in Ocaml 
just the other day.

Basically, I was writting a root finding algorithm by range subdivision.  
Given a function f and a range [a,b] where sign(f(a)) != sign(f(b)),
find the root in that range, the x such that a <= x <= b, and f(x) = 0 (or 
as close as can come).  The function I ended up with was this:

let root_find f a b =
    let rec loop a b fa_is_neg =
        let c = (a +. b) /. 2. in
        if (c = a) || (c = b) then (* note the floating point equality *)
            (* We've bottomed out- pick a or b depending upon if
               f(a) or f(b) is closer to 0. *)
            if (abs_float (f a)) > (abs_float (f b)) then
                a
            else
                b
        else
            let fc_is_neg = ((f c) < 0.) in
            if (fa_is_neg == fc_is_neg) then
                loop c b fc_is_neg
            else
                loop a c fa_is_neg
    in
    loop a b ((f a) < 0.)
;;

Basically, I run the algorithm out until the distance between a and b is 
1ulp, then stop.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
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

RE: [Caml-list] Why must types be always defined at the top level?

[Brian Hurt]

On Thu, 24 Jun 2004, John Hughes wrote:

> I have one more question, though: 
> 
> 5. Why can I no longer type-annotate things I've written, so that
> 
> let f x y z = (x = y) & (y = z)
> 
> defines a function applicable to ALL types? I actually *liked*
> being able to say something like
> 
> let f x y z:int = (x = y) && (y = z)

This annotates that f returns an int.  You need to use parens to make the 
:int bind to z and not to f.  This works:

# let f x y (z:int) = (x = y) && (y = z);;
val f : int -> int -> int -> bool = <fun>
#

This is another one of those shift-reduce conflicts that annoy me.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
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

Re: [Caml-list] Why must types be always defined at the top level?

[Yaron Minsky]

On Thu, 24 Jun 2004 19:45:53 +0200, Xavier Leroy <xavier.leroy@inria.fr> wrote:

> As to whether equality should be defined on floats, there are pros and
> cons.  My standpoint is that it's eventually better to stick to
> established standards (that is, IEEE float arithmetic) rather than try
> to reinvent a wheel likely to be even squarer than these standards.
> Prof. Kahan found it worthwhile to fully define equality over floats;
> I'll abide by his wisdom.

For what it's worth, I've found equality types for floats to be VERY
useful.  That's because I do a lot of data munging which involves
moving data (including floats) around from place to place, and so all
I'm relying on is the fact that when you copy a float from one place
to another, then the resulting float is equal to the original.

The only thing that kills me in this context is nan, which turns out
not to be equal to anything.  I've already spent too much time on the
list complaining about that, however...

y

-------------------
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] Why must types be always defined at the top level?

[skaller]

On Fri, 2004-06-25 at 05:46, John Hughes wrote:
> Thanks for the answers.  
> > > 1. Why no eqtypes? 
> > 
> > Eqtypes have been hotly debated even among the SML designers. 

Hmm .. but interesting Ocaml has a slot to marshal
abstract types .. and to finalise them .. but not
to compare them. Bignums in particular don't work
with polymorphic compare or hash, which means you can't
for example use them as keys to a hashtable .. as I just
discovered again :(

Any thoughts on a way to fix that?

My hashtable keys are terms which might contain
integers which happen to be represented by big ints,
so just using a custom hashtable won't work.

In this case, I'd be more than happy to just
hash the term's address (this would be heaps
faster than the recursive polymorphic comparison)

Is there a way to use an address as a comparable
but otherwise opaque value?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] Why must types be always defined at the top level?

[Basile Starynkevitch [local]]

On Fri, Jun 25, 2004 at 08:20:26PM +1000, skaller wrote:
> On Fri, 2004-06-25 at 05:46, John Hughes wrote:
> > Thanks for the answers.  
> > > > 1. Why no eqtypes? 
> > > 
> > > Eqtypes have been hotly debated even among the SML designers. 

> Hmm .. but interesting Ocaml has a slot to marshal abstract types
> .. and to finalise them .. but not to compare them. Bignums in
> particular don't work with polymorphic compare or hash, which means
> you can't for example use them as keys to a hashtable .. as I just
> discovered again :(

(there is no slot in custom data to support Ocaml values inside them
neither)


> Any thoughts on a way to fix that?

> My hashtable keys are terms which might contain integers which
> happen to be represented by big ints, so just using a custom
> hashtable won't work.

The latest Ocaml CVS has probably some "better" bignums - but I don't
know the details.


> In this case, I'd be more than happy to just hash the term's address
> (this would be heaps faster than the recursive polymorphic
> comparison)

This certainly won't work: addresses (even of opaque types) may move,
because on some occasions (minor GC, compactions) the Ocaml runtime
system (actually the garbage collector part) moves Ocaml values, so
their addresses is changed. To grant your wish (which I actually share
with you) would require to add into the runtime system some kind of
new tag for associative tables, and in several parts of the GC (those
scanning, copying or moving values) additional code to handle it.

IMHO hashtables of (polymorphic) mutable values don't work, even when
using physical identity (==) as the equality test, because their
hashes (which is not based upon the address) changes with tehir
content.

Probably encapsulating such values (or just your bignums) inside
object should work, since objects have immutable identities and
hashcodes.


> Is there a way to use an address as a comparable
> but otherwise opaque value?

No, see above. But try to encapsulate them in objects (at least for
the hash table) might help. Of course, you might need to "hash-cons"
or cache the containing object...

-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - (temporarily)
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
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] Why must types be always defined at the top level?

[skaller]

On Fri, 2004-06-25 at 21:07, Basile Starynkevitch [local] wrote:

> (there is no slot in custom data to support Ocaml values inside them
> neither)

Then how does Marshal work on them?

> Probably encapsulating such values (or just your bignums) inside
> object should work, since objects have immutable identities and
> hashcodes.

Ah. That's a thought. Thanks! I'll try that.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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

[Caml-list] Thread and kernel 2.6 pb still there in CVS

[Christophe Raffalli]

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


I tried to submit a change in vouillon's entry in the bug tracking 
system (classed as not a bug because can not reproduce), but as I am not 
sure it worked, So I also post this here

In the latest CVS of ocaml there is still the periodic call Thread.yield 
(through a sigalarm) in thread_posix.ml

This implies that a threaded OCaml program ON A LINUX KERNEL 2.6 (at 
least 2.6.3 on Mandrake 10, but probaby all 2.6) gets very little CPU 
when another process is running (the usual figure is 10% CPU for the 
threaded OCaml program against 90% for another program)

Could you do something before the next release, because GlSurf is really 
not working on my linux boxes without this change.

--

By the way, why does OCaml needs that  periodic call Thread.yield ?

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[Caml-list] Re: Thread and kernel 2.6 pb still there in CVS

[Marco Maggesi]

On 2004-06-25, Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr> wrote:
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enigAA0A01B71AF5B0A0E7B1B37F
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 8bit
>
>
> I tried to submit a change in vouillon's entry in the bug tracking 
> system (classed as not a bug because can not reproduce), but as I am not 
> sure it worked, So I also post this here
>
> In the latest CVS of ocaml there is still the periodic call Thread.yield 
> (through a sigalarm) in thread_posix.ml
>
> This implies that a threaded OCaml program ON A LINUX KERNEL 2.6 (at 
> least 2.6.3 on Mandrake 10, but probaby all 2.6) gets very little CPU 
> when another process is running (the usual figure is 10% CPU for the 
> threaded OCaml program against 90% for another program)
>
> Could you do something before the next release, because GlSurf is really 
> not working on my linux boxes without this change.
>
> --
>
> By the way, why does OCaml needs that  periodic call Thread.yield ?




Ah, so this should be also the answer to this bug in Coq

  http://coq.inria.fr/bin/coq-bugs/open?id=729

  -- M

-------------------
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: Thread and kernel 2.6 pb still there in CVS

[Markus Mottl]

On Fri, 25 Jun 2004, Marco Maggesi wrote:
> Ah, so this should be also the answer to this bug in Coq
> 
>   http://coq.inria.fr/bin/coq-bugs/open?id=729

And while we are at it, I'm currently also having problems with native
threads and OCaml on Linux: sometimes processes get stuck for no apparent
reason.  VM-threads seem to work flawlessly for me.  Same problem?

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
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] Why must types be always defined at the top level?

[Dave Berry]

At 00:23 25/06/2004, Brian Hurt wrote:
>On Thu, 24 Jun 2004, Xavier Leroy wrote:
> > As to whether equality should be defined on floats, there are pros and
> > cons.  My standpoint is that it's eventually better to stick to
> > established standards (that is, IEEE float arithmetic) rather than try
> > to reinvent a wheel likely to be even squarer than these standards.
> > Prof. Kahan found it worthwhile to fully define equality over floats;
> > I'll abide by his wisdom.
>
>There are legitimate reasons to want floating point equality.  It's
>generally not what you want, but I had an example of needing it in Ocaml
>just the other day.

FWIW, the SML Basis does define an equality operation on IEEE floats.  But 
IEEE equality is not structural equality and so IEEE floats are not 
equality types.  IMO this is a good thing because anyone using equality on 
IEEE floats must understand the difference between IEEE equality and 
structural equality.  It is also a good thing that SML floats are not 
equality types because it encourages people to think twice before using 
equality on floats.  Sometimes you do want equality; often you don't.

I am not trying to criticise Ocaml here, just to clarify the position in SML.

Dave.

-------------------
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] Thread and kernel 2.6 pb still there in CVS

[Xavier Leroy]

> I tried to submit a change in vouillon's entry in the bug tracking 
> system (classed as not a bug because can not reproduce), but as I am not 
> sure it worked, So I also post this here

You should be grateful to Olivier Andrieu, who actually cared to
submit a bug report along with useful info on 2.6 kernels.

> In the latest CVS of ocaml there is still the periodic call Thread.yield 
> (through a sigalarm) in thread_posix.ml

Yes, and that is necessary to get preemptive scheduling.  Without this
periodic Thread.yield, a thread that performs no I/O and no
inter-thread communications would prevent all other Caml threads from
running at all.

> This implies that a threaded OCaml program ON A LINUX KERNEL 2.6 (at 
> least 2.6.3 on Mandrake 10, but probaby all 2.6) gets very little CPU 
> when another process is running (the usual figure is 10% CPU for the 
> threaded OCaml program against 90% for another program)

Thread.yield does three things:
   - release the global Caml mutex, giving other Caml threads a chance
     to grab it and run;
   - call sched_yield() to suggest the kernel scheduler that now is
     a good time to schedule another thread;
   - re-acquire the global Caml mutex before returning to the caller.

The 2.6 Linux kernels changed the behavior of sched_yield() in a way
that causes the unfairness you observed.  Other threaded applications
are affected, including Open Office (!).  My belief is that it's
really a bug in 2.6 kernels and that the new behavior of sched_yield(),
while technically conformant to the POSIX specs, lowers the quality of
implementation quite a lot.

(I seem to remember from my LinuxThreads development days that this
isn't the first time the kernel developers broke sched_yield(), then
realized their error.)

The question I'm currently investigating is whether the call to
sched_yield() can be omitted, as it's just a scheduling hint.  Initial
experiments suggested that this would hurt fairness (in Caml thread
scheduling) quite a lot on all platforms other than Linux 2.6.
More careful experiments that I'm currently conducting suggest that it
might not be so bad.  One can also play games where sched_yield()
isn't called if there are no other Caml threads waiting for the global
Caml mutex.

In summary, a solution will eventually be found, but please be
patient, and submit a bug report next time.

- Xavier Leroy

-------------------
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] Thread and kernel 2.6 pb still there in CVS

[Benjamin Geer]

Xavier Leroy wrote:
> The question I'm currently investigating is whether the call to
> sched_yield() can be omitted

Ingo Molnar has suggested calling nanosleep() or sem_timedwait(sem, 
abs_timeout) instead:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0312.2/1127.html

Ben

-------------------
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] Thread and kernel 2.6 pb still there in CVS

[Christophe Raffalli]

Xavier Leroy wrote:
>>I tried to submit a change in vouillon's entry in the bug tracking 
>>system (classed as not a bug because can not reproduce), but as I am not 
>>sure it worked, So I also post this here
> 
> 
> You should be grateful to Olivier Andrieu, who actually cared to
> submit a bug report along with useful info on 2.6 kernels.
> 

Sorry, but I thought continuing an entry in the bug tracking was better 
than adding one (but I was unable tu actually make a comment in that 
entry !)


> The question I'm currently investigating is whether the call to
> sched_yield() can be omitted, as it's just a scheduling hint.  Initial
> experiments suggested that this would hurt fairness (in Caml thread
> scheduling) quite a lot on all platforms other than Linux 2.6.
> More careful experiments that I'm currently conducting suggest that it
> might not be so bad.  One can also play games where sched_yield()
> isn't called if there are no other Caml threads waiting for the global
> Caml mutex.

Someone (I do not remember who) suggested a call to select in place of 
sched_yield.

My thought about semantics in that
- a system call saying schedule just now or later (like the semantics of 
sched_yield in 2.4) only lower the percentage of CPU a thread get, 
except if you manage to have your thread "in phase" (I do not know if 
this is proper english) with the scheduler.

Then to lower your % of CPU you should use renice (but I do not know if 
the semantics of renice is per thread or per processus).

However a system call saying "I do not not need CPU for a while" could 
be usefull ... but it should have another name not to break existing 
program ... and should have an (optional ?) argument saying how long is 
this while.

So I think the 2.6 developper are right, but should have created a new 
system call. and let sched yield unchanged.

Any one can feel free to forward my post to a kernel developpers list :-)

> In summary, a solution will eventually be found, but please be
> patient, and submit a bug report next time.
> 
> - Xavier Leroy

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

-------------------
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] Thread and kernel 2.6 pb still there in CVS

[Christophe Raffalli]

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


The latest 3.08 CVS solves the problem (for GlSurf at least).
When I have the too Glsurf thread (on computing, one for drawing GL (I 
keep pressing a key to rotate the surface) and I launched povray from 
Glsurf for a rendering, then I get one third of cpu each which is perfect)

Just a last question:

Now I saw that for "non broken" sched_yield, the call is still present.

Are you sure that releasing the mutex is not enough to tell the 
scheduler it may be a good time to give some cpu to another caml thread 
blocked on the same mutex ?

But I am sure you tested that too and this is why the call is still 
there when possible ;-)

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] Thread and kernel 2.6 pb still there in CVS

[Xavier Leroy]

> Just a last question:
> Now I saw that for "non broken" sched_yield, the call is still present.
> Are you sure that releasing the mutex is not enough to tell the 
> scheduler it may be a good time to give some cpu to another caml thread 
> blocked on the same mutex ?

In general, when there's code in the Caml implementation, it's for a
good reason.

> But I am sure you tested that too and this is why the call is still 
> there when possible ;-)

Yes, I tested.  Spent more than one day setting up and refining a test
harness, then running it on a variety of Linux and non-Linux systems.
Had to install a Fedora Core 2 somewhere to assess the damage done in
kernel 2.6.  In the meantime, read a bunch of condescending mailing
list posts along the lines of "if you're using sched_yield(), you must
be doing busy-waiting and that's wrong".  (Guess what?  I'm not doing
busy waiting!)  The conclusions are clear: sched_yield() does improve
fairness and has no significant costs in the situation corresponding to
Caml threads (contention on a master lock); and the Linux 2.6
developers managed to make sched_yield() useless for this purpose.

If the above sounds mildly irritated, that's because I am.

- Xavier Leroy

-------------------
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] Thread and kernel 2.6 pb still there in CVS

[Alex Baretta]

Xavier Leroy wrote:

> If the above sounds mildly irritated, that's because I am.
> 
> - Xavier Leroy


Xavier is not the only irritated with the o(1) scheduler: see the 
following link from HP.

http://www.hpl.hp.com/research/linux/kernel/o1-openmp.php

Alex

-------------------
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] Thread and kernel 2.6 pb still there in CVS

[Christophe Raffalli]

I did again some testing, with a Caml program with 2 thread, one doing 
only float computation for a long time with no allocation. The nanosleep 
suggestion seems much better than the actual version doing nothing:

This gives the following code in systhreads/posix.c:

/* Allow re-scheduling */

value caml_thread_yield(value unit)        /* ML */
{
  struct timespec timer = { 0, 1 };

   enter_blocking_section();
   nanosleep (&timer, NULL);
   /* sched_yield();*/
   leave_blocking_section();
   return Val_unit;
}


-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

-------------------
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] Thread and kernel 2.6 pb still there in CVS

[Xavier Leroy]

> I did again some testing, with a Caml program with 2 thread, one doing 
> only float computation for a long time with no allocation. The nanosleep 
> suggestion seems much better than the actual version doing nothing:

I tried the nanosleep() trick on a different workload (several
compute-bound threads).  Scheduling was less fair than with the "do
nothing" implementation.

- Xavier Leroy

-------------------
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] Thread and kernel 2.6 pb still there in CVS

[Donald Wakefield]

On Mon, 28 Jun 2004 17:08:05 +0200, Xavier Leroy <xavier.leroy@inria.fr> wrote:
> 
> The 2.6 Linux kernels changed the behavior of sched_yield() in a way
> that causes the unfairness you observed.  Other threaded applications
> are affected, including Open Office (!).  My belief is that it's
> really a bug in 2.6 kernels and that the new behavior of sched_yield(),
> while technically conformant to the POSIX specs, lowers the quality of
> implementation quite a lot.
> 
> (I seem to remember from my LinuxThreads development days that this
> isn't the first time the kernel developers broke sched_yield(), then
> realized their error.)

I know this comes a bit late in this 'thread', but there's been
discussion on Slashdot on a new scheduler framework called Bossa. I
posted a quote from Xavier's discussion of sched_yield, and another
poster replied. In brief:

"...OpenOffice.org and Ocaml have to wait too long for their next CPU
quantum, but that's because they are CPU bound tasks and it's their
own fault.

"The bug was in past versions of Linux where, although it was
pre-emptive, sched_yield was allowed some power - it should have been
ignored in user-space and the scheduler decided what gets CPU and
when. Depending on that bug is also a bug and the mis-users deserve
everything they get."

The full reply can be read at:

  <http://slashdot.org/comments.pl?sid=113880&cid=9655540>

-- 
 Don Wakefield
don.wakefield@gmail.com

-------------------
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] Thread and kernel 2.6 pb still there in CVS

[Damien Doligez]

On Jul 10, 2004, at 01:21, Donald Wakefield wrote:

> I know this comes a bit late in this 'thread', but there's been
> discussion on Slashdot on a new scheduler framework called Bossa. I
> posted a quote from Xavier's discussion of sched_yield, and another
> poster replied. In brief:

I read that post and I don't think it makes any sense at all.

> "...OpenOffice.org and Ocaml have to wait too long for their next CPU
> quantum, but that's because they are CPU bound tasks and it's their
> own fault.

In other words, a CPU-bound task should not expect to get CPU time.
Duh.

> "The bug was in past versions of Linux where, although it was
> pre-emptive, sched_yield was allowed some power - it should have been
> ignored in user-space and the scheduler decided what gets CPU and
> when. Depending on that bug is also a bug and the mis-users deserve
> everything they get."

This implies that the new scheduler is just as buggy as the old one,
since it doesn't ignore sched_yield either.

The real problem, IMO, is that there are two "yield" primitives
needed: one for yielding to another thread, and one for yielding
to another process.  They (basically) changed sched_yield from
one to the other, but the right solution would be to provide both.

-- Damien

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