caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>
To: fabrice@lefessant.net
Cc: Hal Daume III <hdaume@ISI.EDU>, Caml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] unboxing of unary datatypes
Date: Tue, 14 Jan 2003 12:19:01 +0100	[thread overview]
Message-ID: <3E23F225.3060302@univ-savoie.fr> (raw)
In-Reply-To: <15907.57089.759815.660410@lachesis.inria.fr>

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

Fabrice Le Fessant wrote:
>> I originally had a very calculation intensive program which used a data
>> type which looked like:
>> 
>> > type foo = Foo of float
>> 
>> I could just have easily used floats, but I wanted to ensure that I didn't
>> do anything stupid (like try to multiply a foo by a float), so I did this
>> boxing so the type-checker would help me out.
> 
> 
> In ocaml, there are no overloaded operations, not automatic
> conversions to integers, so that if you don't need to do that at
> all. The type system will always force you to use the operations on
> floats, or to convert them to foo before multiplying them by foo. 
> 
> 
>> But based on some non-scientific tests, it seems that this isn't the case,
>> and that the original foo type is actually represented using a
>> pointer-to-float.
>> 
>> I cannot imagine why this is the case (coming from a Haskell world, there
>> is a difference there between these two types due to laziness, but since
>> ocaml is strict, I figured this wouldn't be the case).
> 
> 
> If you want to keep the interface with C simple, you need an
> easy/efficient way to move ocaml values between caml functions and C
> functions. This is done by specifying the internal representation of
> ocaml values so that C functions know how to manipulate them. If you
> let the compiler optimize the representation of values, C functions
> won't be able to access ocaml values anymore (well, it will be more
> complicated, since you need to attach by some way a description of the
> representation of each value passed to a C function...).
>
> Of course, it could be done by some annotation, telling the compiler
> that the value will never be passed to a C function. But this would
> introduce useless complexity into the language.

Or let the compiler produce a C header describing the representation
of the data type, when it is optimized !

It would be nice if Data type with one unary constructor and many 
constant constructors could be optimized by using the fact that pointer
are always even (and non zero), so we can use the zero and/or the odd 
numbers to represent the constant
constructor.

This would optimize a lot the 'a option type.

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

-- 
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: Type: application/pgp-signature, Size: 252 bytes --]

      reply	other threads:[~2003-01-14 18:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-14  0:08 Hal Daume III
2003-01-14  4:38 ` Nicolas Cannasse
2003-01-14 11:17   ` Florian Hars
2003-01-14 15:15     ` Nicolas Cannasse
2003-01-14  9:57 ` Fabrice Le Fessant
2003-01-14 11:19   ` Christophe Raffalli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E23F225.3060302@univ-savoie.fr \
    --to=christophe.raffalli@univ-savoie.fr \
    --cc=caml-list@inria.fr \
    --cc=fabrice@lefessant.net \
    --cc=hdaume@ISI.EDU \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).