From: skaller <skaller@users.sourceforge.net>
To: Nathaniel Gray <n8gray@gmail.com>
Cc: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>,
caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Single-case union types as strong typedefs
Date: 24 Oct 2004 15:18:47 +1000 [thread overview]
Message-ID: <1098595127.7584.219.camel@pelican.wigram> (raw)
In-Reply-To: <aee06c9e0410231424f261f2c@mail.gmail.com>
On Sun, 2004-10-24 at 07:24, Nathaniel Gray wrote:
> On Sat, 23 Oct 2004 12:31:39 +0900 (JST), Jacques Garrigue
> <garrigue@kurims.kyoto-u.ac.jp> wrote:
>
> > Unlucky!
> > With your example, there is no extra boxing involved.
> > I.e. (1,3) and Rpos(1,3) and Apos(1,3) all share the same physical
> > representation (a block with 2 fields).
> > The problem you describe only occurs when your single constructor has
> > only one argument.
>
> Really?? You're kidding. That's kind of cool but kind of strange --
> why does it only optimize for composite types?
For two arguments, it's a pointer to a pair on the heap.
For one, its a pointer to a one element tuple on the heap.
This case might be optimised by replacing the pointer
with the value stored in that single field, but it isn't.
That's what Jacques meant -- there's no issue of optimising
the composite case, so there is 'no problem' then,
the problem 'only occurs when .. has only one argument'
because that's the only time you might get rid of the
extra level of indirection.
Note this would only be possible for the single constructor
with one argument, because the tag field (for the variant case)
stored on the heap is lost too, but it isn't needed
for the single constructor case. It isn't needed for
the composite argument case either .. but a heap
block is needed for the tuple, so the tag field is there anyhow.
--
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
next prev parent reply other threads:[~2004-10-24 5:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-23 1:49 Nathaniel Gray
2004-10-23 3:31 ` Jacques Garrigue
2004-10-23 3:39 ` David Brown
2004-10-23 5:00 ` skaller
2004-10-23 21:49 ` Nathaniel Gray
2004-10-23 21:24 ` Nathaniel Gray
2004-10-23 21:33 ` Nathaniel Gray
2004-10-24 3:00 ` John Prevost
2004-10-24 5:18 ` skaller [this message]
2004-10-24 22:52 ` Nathaniel Gray
2004-10-25 13:21 ` Damien Doligez
2004-10-25 14:25 ` Jacques Carette
2004-10-26 14:07 ` Damien Doligez
2004-10-26 15:05 ` Jacques Carette
2004-10-26 17:34 ` skaller
2004-10-26 20:02 ` [Caml-list] Combined compilation and linking Jon Harrop
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=1098595127.7584.219.camel@pelican.wigram \
--to=skaller@users.sourceforge.net \
--cc=caml-list@inria.fr \
--cc=garrigue@kurims.kyoto-u.ac.jp \
--cc=n8gray@gmail.com \
/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