From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: David.Chemouil@enseeiht.fr
Cc: caml-list@inria.fr
Subject: Re: polymorphic variants (2) + magic
Date: Mon, 12 Jun 2000 17:27:54 +0900 [thread overview]
Message-ID: <20000612172754Q.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: Your message of "Fri, 09 Jun 2000 11:15:58 +0200" <3940B5CE.57FEE3E4@enseeiht.fr>
From: David Chemouil <David.Chemouil@enseeiht.fr>
Subject: polymorphic variants (2) + magic
Date: Fri, 09 Jun 2000 11:15:58 +0200
> Considering my two previous posts ("polymorphic variants" and
> "Obj.magic"), I'd like to show how I had to merge them to have my
> application work.
>
> Indeed, I don't know yet completely the type 'argument', but I already
> know some of its constructors. Then I use polymorphic constructors when
> I need them and, when I'm able to do it, I will generate the 'argument'
> type.
You don't necessarily have to use polymorphic variants for that.
In fact the goal of polymorphic variant is somewhat othogonal to your
problem.
With standard sums, you can write
type 'a message =
Server_message1
| Server_message2
| Server_message3
| Application_message of 'a
Then you can write all your server functions handling only server
messages, and returning application messages to the application.
Moreover, if your server is going to run as an indepedent program,
communicating with applications using input_value/output_value,
then you probably want to make application messages abstract.
types app_msg
type server_message = app_msg message
This way you are sure your server will not fiddle with application
messages. It can receive or send them, but not read their contents.
Polymorphic variants will only be useful if you have a more complex
hierarchy of messages, and want for instance to share some messages
(but not all) between different applications; but it will do nothing
for solving your first problem.
> The problem is that there are already functions which manipulate the
> 'argument' type. So, if I try to use them on an already known
> polymorphic constructor, it doesn't work, because the constructor is not
> known to belong to 'argument', as 'argument' isn't defined.
With the structure I suggest above, your functions will be polymorphic
in the type of application messages, so this problem does not occur.
> As the example shows, the only solution for me is to use Obj.magic. Then
> I'm sure everything will be well-typed. But is it completely correct to
> do like this?
Certainly not correct. You should _never_ use Obj.magic.
When you use it things are not well-typed, they are just untyped,
and you can say hello to segmentation faults.
This is only intended to do on the Caml side things that otherwise you
would have to do anyway on the C-side. So, basically the only case in
which you can use Obj.magic is when you have _yourself_ implemented a C
interface, and want to do some casts on C-values. Never use it on ML
values.
Jacques
---------------------------------------------------------------------------
Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp
<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
prev parent reply other threads:[~2000-06-12 14:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-09 9:15 David Chemouil
2000-06-09 8:57 ` Obj.magic David Chemouil
2000-06-12 4:15 ` polymorphic variants (2) + magic Ken Wakita
2000-06-12 16:20 ` Obj.magic Jean-Christophe Filliatre
2000-06-12 4:33 ` Obj.magic Daniel de Rauglaudre
2000-06-12 8:27 ` Jacques Garrigue [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=20000612172754Q.garrigue@kurims.kyoto-u.ac.jp \
--to=garrigue@kurims.kyoto-u.ac.jp \
--cc=David.Chemouil@enseeiht.fr \
--cc=caml-list@inria.fr \
/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