caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Angelo Corsaro <angelo@icorsaro.net>
To: caml-list@inria.fr
Subject: [Caml-list] Recursive Types and -rectypes
Date: Fri, 13 Jul 2018 13:09:56 +0200	[thread overview]
Message-ID: <EDBE5195-32FB-4BFB-B803-07EAA91BBB92@icorsaro.net> (raw)

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

Dear All,

	I am looking for some advices and suggestions on the use of recursive types that  OCaml makes available through the -rectypes option. 

To give you some context we have built a simple Agent framework for Ocaml that provides primitives similar to those of Erlang — with the difference that at the present time we care only on using actors to control concurrency on the same process. As you can probably imagine the recursive type definition comes out from the actor message queue. The most straight forward definition would look like (removing some details to keep the essence):

type ‘msg actor_queue = ( ‘msg actor_queue option * ‘msg) some_queue_type 

This is a simplified version, but let’s say that the intuition is that we need to post on the receiving actor queue the message along to possibly the queue of the agent we may reply to. This gives rise to a recursive type definition which clearly would only be usable with the -rectypes option.

The traditional way of breaking things kind of recursive types is to use variant types recursion. Which is what I’ve done. Yet that comes at some cost w.r.t. the readability of the code. Thus the question, would you suggest using -rectypes to enable recursive data types? Use classes to represent this type, as they allow for recursive type definition? Or just stick with the variant type trick?

Thanks very much in advance for sharing your thoughts!

Ciao,
    Angelo

P.S. ‘msg is actually bound with some polymorphic variant to allow the actor to accept any user defined type as in Erlang. We also have a version that leverages functors to define the messages that may be exchanged between actors — if a strict control is required on the set of messages exchanged. 

—
“Simplicity is the ultimate sophistication." ~ Leonardo da Vinci


-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[-- Attachment #2: Type: text/html, Size: 3310 bytes --]

             reply	other threads:[~2018-07-13 11:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-13 11:09 Angelo Corsaro [this message]
2018-07-13 12:34 ` Gabriel Scherer
2018-07-14 14:34   ` Angelo Corsaro

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=EDBE5195-32FB-4BFB-B803-07EAA91BBB92@icorsaro.net \
    --to=angelo@icorsaro.net \
    --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;
as well as URLs for NNTP newsgroup(s).