caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* unboxing options
@ 2005-05-06  3:22 Charles Martin
  2005-05-10 18:19 ` [Caml-list] " Christophe Raffalli
  0 siblings, 1 reply; 4+ messages in thread
From: Charles Martin @ 2005-05-06  3:22 UTC (permalink / raw)
  To: caml-list

This is reviving a thread from last summer, but I
recently became interested in the problem:

Damien Doligez <damien.doli...@inria.fr> wrote in
message news:<fa.eok2n4f.141k5pt@ifi.uio.no>...
> Finally, Jacques was not quite right in asserting
that most options
> are short-lived.  This is only true if you don't use
"option" in your
> main long-lived data structure.  Most seasoned OCaml
programmers know
> it, and sometimes it leads to rather contorted data
structures.

How easy would it be to add an 'optional' keyword for
record types? For example:

    type 'a foo = { one : 'a option; mutable two : 'a
option }

would become:

    type 'a foo = { optional one : 'a; optional
mutable two : 'a }

Where the latter would unbox the options in the
representation. The
usage would be the same:

    let foo = { one = Some 0; two = None }
    match foo.one with None -> ... | Some x -> ...
    foo.two <- None
    foo.two <- Some x

This 'solves' the 'option option' problem by
supporting exactly one level of unboxing for records.
My guess is that this would take care of most of the
long-term data structure needs.

Charles



		
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Caml-list] unboxing options
  2005-05-06  3:22 unboxing options Charles Martin
@ 2005-05-10 18:19 ` Christophe Raffalli
  2005-05-11 17:18   ` Mike Hamburg
  0 siblings, 1 reply; 4+ messages in thread
From: Christophe Raffalli @ 2005-05-10 18:19 UTC (permalink / raw)
  To: Charles Martin; +Cc: caml-list

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


>     type 'a foo = { one : 'a option; mutable two : 'a
> option }
>
> would become:
>
>     type 'a foo = { optional one : 'a; optional
> mutable two : 'a }
>

You could also unbox any data type whose size is know at compile time in
a record if an "unboxed" keyword is present ... and remove the nasty bit
of the compiler handling float in record.

{ unboxed float x; unboxed muatable float y }

You could imagine doing the same for array with a type ('a, 'b) array
where 'a is the type of the content and 'b is either `Boxed or `Unboxed
(using polymorphic variant)

but you still need a test for polymorphic function on array which need
to know if the array is unboxed and if yes what is the size of each
array cell.

I guess the code for this is not much more complex that the actual code
for float optimization, and is more general.



--
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. The public key is
stored on www.keyserver.net
---------------------------------------------

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Caml-list] unboxing options
  2005-05-10 18:19 ` [Caml-list] " Christophe Raffalli
@ 2005-05-11 17:18   ` Mike Hamburg
  2005-05-11 18:50     ` Christophe Raffalli
  0 siblings, 1 reply; 4+ messages in thread
From: Mike Hamburg @ 2005-05-11 17:18 UTC (permalink / raw)
  To: Christophe Raffalli; +Cc: caml-list, Charles Martin

Why should we need an "unboxed" keyword?  Is there any reason why the 
user should want things to be boxed?  (Perhaps for interfacing with C?) 
  It seems to me that since a pure OCaml program would just be 
specifying unboxed everywhere it could, the compiler could try to just 
unbox everything it can.  Assuming, that is, that changing the float 
unboxing code to unbox other stuff is actually fairly easy.

Mike

On May 10, 2005, at 2:19 PM, Christophe Raffalli wrote:

>
>>     type 'a foo = { one : 'a option; mutable two : 'a
>> option }
>>
>> would become:
>>
>>     type 'a foo = { optional one : 'a; optional
>> mutable two : 'a }
>>
>
> You could also unbox any data type whose size is know at compile time 
> in
> a record if an "unboxed" keyword is present ... and remove the nasty 
> bit
> of the compiler handling float in record.
>
> { unboxed float x; unboxed muatable float y }
>
> You could imagine doing the same for array with a type ('a, 'b) array
> where 'a is the type of the content and 'b is either `Boxed or `Unboxed
> (using polymorphic variant)
>
> but you still need a test for polymorphic function on array which need
> to know if the array is unboxed and if yes what is the size of each
> array cell.
>
> I guess the code for this is not much more complex that the actual code
> for float optimization, and is more general.
>
>
>
> --
> 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. The public key is
> stored on www.keyserver.net
> ---------------------------------------------


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Caml-list] unboxing options
  2005-05-11 17:18   ` Mike Hamburg
@ 2005-05-11 18:50     ` Christophe Raffalli
  0 siblings, 0 replies; 4+ messages in thread
From: Christophe Raffalli @ 2005-05-11 18:50 UTC (permalink / raw)
  To: Mike Hamburg; +Cc: caml-list, Charles Martin

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

Mike Hamburg wrote:
> Why should we need an "unboxed" keyword?  Is there any reason why the
> user should want things to be boxed?

Yes many reason:

- Unboxing of data structure prevent sharing of data structure and
therefore:
   1 it may increase the memory usage
   2 it changes the semantics in presence of mutable data or ==
   3 it cost time to get the data out of the structure (needs copying)

So in fact, you only want unboxing for small object that have little
chance to be shared.

You could correct 2 and 3 if you allow pointer in the middle of the data
structure, but this is a nightmare for GC and runtime ...


--
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. The public key is
stored on www.keyserver.net
---------------------------------------------

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-05-11 18:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-06  3:22 unboxing options Charles Martin
2005-05-10 18:19 ` [Caml-list] " Christophe Raffalli
2005-05-11 17:18   ` Mike Hamburg
2005-05-11 18:50     ` Christophe Raffalli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).