headers
Johann Spies | 1 Apr 2003 10:22
Picon
Picon
Favicon

Re: Belated thanks (was Re: OCaml popularity)

On Sat, Mar 29, 2003 at 10:59:06PM -0700, Matt Gushee wrote:
> 
> Also, I'm thinking it might be useful if I summarized that thread for
> posterity. There's lots of good stuff in there. Would people be
> interested in that?
> 

That would be helpful, thank you.

Johann
--

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

     "Therefore, if anyone is in Christ, he is a new   
      creation; the old has gone, the new has come."   
                      II Corinthians 5:17  

-------------------
To unsubscribe, mail caml-list-request <at> 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
Permalink | Reply | 0 comments |
headers
Xavier Leroy | 1 Apr 2003 10:19
Picon
Picon
Favicon

Re: Bug? Printf, %X and negative numbers

> Having looked at it a bit myself, the fix will probable be *ahem* 
> interesting.  Effectively, you have to stop using C's printf.  Either 
> that, or parse the format string a second (third?) time to see wether you 
> need to do a signed or unsigned int conversion.

It's no big deal, really.  (See the working sources on camlcvs.inria.fr.)
The formats are already parsed three(!) times:
  - once in Caml (module Printf)
  - once in C to determine the size of the buffer to hold the result
        (file byterun/ints.c)
  - once in the printf() C library function itself.
The way I fixed it, the signed/unsigned distinction is done in the
second parsing, although it could also be done during the first.

> Or, I suppose, we could 
> completely redesign Ocaml to use 32-bit ints and do something else to 
> differentiate ints from pointers :-).

If you can find a "something else" that is faster than systematically
boxing the 32-bit ints, you'll be hailed as the savior in compiler
circles :-)

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request <at> 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
(Continue reading)

Permalink | Reply | 12 comments |
headers
Damien Doligez | 1 Apr 2003 16:14
Picon
Picon
Favicon

Re: naming conflicts (was: camlimages vs. labltk)

On Sunday, March 30, 2003, at 12:38 PM, Sven Luther wrote:

> But then, maybe i am just being stupid and completely misunderstand the
> problem or something such, please enlighten me if this is the case.

Judging from your and Chris Hecker's mail, I think it's my fault for
not explaining clearly what I have in mind.  Let me try again.

First of all, let me say that I am looking for a complete solution
to the problem, not just a quick fix that works most of the time.
 From this point of view, there is no difference between modules
and libraries: if there are naming conflicts between modules, there
will also be conflicts between libraries.

I'll give two examples of what I think the problem is.

First example:
I am building a program D, which uses libraries B and C.  B uses
another library, A.  C also uses another library, A.  But these are
not the same A, so I have a name conflict.  I don't want to change
the source code of B or C (because I am not the author, and updating
to a new version is much harder if I use modified libraries).

So I need to rename the A used by B, and I need to tell B to use
A under this new name.  This is why I need to rename imports as
well as exports.

Second example (somewhat artificial):
I am doing comparative benchmarks of two versions of library A.
I'd like to wrap up everything into one O'Caml program, so I need
(Continue reading)

Permalink | Reply | 1 comment |
headers
Benjamin C. Pierce | 1 Apr 2003 17:05

Re: naming conflicts (was: camlimages vs. labltk)

> Now that I think about it, I think both problems could be solved
> by changing toplevel modules into functors (instead of modules with
> free variables).  Then we only need a small linking language to tell
> which export to use to satisfy each import.  With suitable defaults
> (an import is satisfied by the export of the same name), this could
> be made compatible with the current system.

Wouldn't this create all sorts of problems with coherence (requiring
sharing declarations to fix)?  

The big difference between a functor and a module with a free variable is
that if you have *two* modules and you see the same variable name
occuring in them, you can be sure that, at link time, these names will
get bound to the same module, so no need for sharing declarations.  If
you change to functors (naively, anyway), you lose this guarantee.

     - B

-------------------
To unsubscribe, mail caml-list-request <at> 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
Permalink | Reply | 0 comments |
headers
David Brown | 1 Apr 2003 18:09

Re: Bug? Printf, %X and negative numbers

On Tue, Apr 01, 2003 at 10:19:46AM +0200, Xavier Leroy wrote:

> > Or, I suppose, we could 
> > completely redesign Ocaml to use 32-bit ints and do something else to 
> > differentiate ints from pointers :-).
> 
> If you can find a "something else" that is faster than systematically
> boxing the 32-bit ints, you'll be hailed as the savior in compiler
> circles :-)

Easy, just convince everyone to start using 33 bit computers.

Dave

-------------------
To unsubscribe, mail caml-list-request <at> 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
Permalink | Reply | 0 comments |
headers
Tim Freeman | 1 Apr 2003 18:45

Re: Bug? Printf, %X and negative numbers

Somebody I don't know said:
> Or, I suppose, we could 
> completely redesign Ocaml to use 32-bit ints and do something else to 
> differentiate ints from pointers :-).

Then Xavier said:
>If you can find a "something else" that is faster than systematically
>boxing the 32-bit ints, you'll be hailed as the savior in compiler
>circles :-)

I'm guessing that the standard solution to doing full-word ints with a
garbage collector is to generate some code for each data structure
that plugs into the garbage collector and knows what fields are ints
and what fields are pointers.  That's the way the gcc compiler did it
as of 3.0.1 or so.  (In that case the code was manually generated.)

I don't know if this would be faster than OCAML's approach.  You'd pay
for more code in your cache, and for an indirect goto for each block
that is garbage collected (unless you managed to garbage collect them
in batches of blocks of identical type, or you organized things so in
the absence of polymorphism it was a subroutine call instead of an
indirect goto.  You could maybe even inline the subroutine call
sometimes.  Hmm.).  You'd benefit because you don't have to do the bit
twiddling that's done for every arithmetic operation now, and because
it should be faster to decide not to follow the non-pointers during
garbage collection.  Straight-line code is often faster than branching
for modern architectures.

Surely this has been discussed before, although perhaps not on this
mailing list.  Can someone point to a paper that analyzes the various
(Continue reading)

Permalink | Reply | 9 comments |
headers
Alessandro Baretta | 1 Apr 2003 19:34

Typing problem with polymorphic variants

This just baffles me.

 > Values do not match:
 >   val feature :
 >     [> `Clear | `Length of int | `Pitch of int
 >               | `Width of 'a] -> string
 > is not included in
 >   val feature : [> `Clear] -> string

Why are "match-anything" functions of the kind of

let f = function
   | `Foo -> "foo"
   | `Bar -> "bar"
   | _ -> "?"

incompatible with signatures like

val f : [> `Foo ] -> string
?

There clearly is no case when a value of type [> `Foo] will 
not be acceptable for f. So why does the type checker reject 
this?

Alex

-------------------
To unsubscribe, mail caml-list-request <at> inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ville-Pertti Keinonen | 1 Apr 2003 20:34

Re: Bug? Printf, %X and negative numbers

>> Or, I suppose, we could
>> completely redesign Ocaml to use 32-bit ints and do something else to
>> differentiate ints from pointers :-).
>
> If you can find a "something else" that is faster than systematically
> boxing the 32-bit ints, you'll be hailed as the savior in compiler
> circles :-)

I'm probably missing something because I don't see how this should be 
*that* difficult.  There are language implementations that use 
untagged, at-least-sometimes-unboxed native integers and have garbage 
collection, and I don't believe they perform horribly.

Representation of mixed data and stack frames can be done using various 
combinations of conservative garbage collection, layout descriptors and 
selective boxing.  This is a matter of choosing a set of compromises.  
Most such solutions would probably have slightly higher garbage 
collection and memory overhead than OCaml currently does, but I 
wouldn't expect all of the possible approaches to perform worse than 
boxing all integers (with the obvious exception of cases where integers 
are hardly used).

Generic code could be optimized by generating specialized versions of 
the code for the unboxed/untagged types in cases where the aren't more 
than, say, two or three unknown types.  Unused versions can be 
eliminated at link time.  This could also be done more efficiently and 
completely by changing the compilation model a bit more.

Even with the current tagged integers, specialized versions of generics 
would significantly increase performance in some cases.  Currently
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ville-Pertti Keinonen | 1 Apr 2003 20:38

Re: Typing problem with polymorphic variants


On Tuesday, Apr 1, 2003, at 20:34 Europe/Helsinki, Alessandro Baretta 
wrote:

> This just baffles me.
>
> > Values do not match:
> >   val feature :
> >     [> `Clear | `Length of int | `Pitch of int
> >               | `Width of 'a] -> string
> > is not included in
> >   val feature : [> `Clear] -> string

Consider what would happen if you tried to pass a `Length of float, 
which is acceptable according to the latter signature.

-------------------
To unsubscribe, mail caml-list-request <at> 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
Permalink | Reply | 1 comment |
headers
David Brown | 1 Apr 2003 20:44

Re: Typing problem with polymorphic variants

On Tue, Apr 01, 2003 at 07:34:24PM +0200, Alessandro Baretta wrote:

> Why are "match-anything" functions of the kind of
> 
> let f = function
>   | `Foo -> "foo"
>   | `Bar -> "bar"
>   | _ -> "?"
> 
> incompatible with signatures like
> 
> val f : [> `Foo ] -> string
> ?
> 
> There clearly is no case when a value of type [> `Foo] will 
> not be acceptable for f. So why does the type checker reject 
> this?

I would apply the same question to the object system: why can a
signature not hide methods of a class.

Does making the signature more restrictive somehow hurt the type system?

e.g.:

  class foo : object method baz : int end =
    object
      method baz = 5
      method bar = 2
    end
(Continue reading)

Permalink | Reply | 1 comment |

Gmane