Version française
Home     About     Download     Resources     Contact us    
Browse thread
polymorphic variants (2) + magic
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: polymorphic variants (2) + magic
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>