From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lambda.q.q@gmail.com>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by sympa.inria.fr (Postfix) with ESMTPS id F26447F1C9
	for <caml-list@sympa.inria.fr>; Mon, 12 Nov 2012 07:30:07 +0100 (CET)
Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  lambda.q.q@gmail.com) identity=pra; client-ip=209.85.217.182;
  receiver=mail4-smtp-sop.national.inria.fr;
  envelope-from="lambda.q.q@gmail.com";
  x-sender="lambda.q.q@gmail.com";
  x-conformance=sidf_compatible
Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of
  lambda.q.q@gmail.com designates 209.85.217.182 as permitted
  sender) identity=mailfrom; client-ip=209.85.217.182;
  receiver=mail4-smtp-sop.national.inria.fr;
  envelope-from="lambda.q.q@gmail.com";
  x-sender="lambda.q.q@gmail.com";
  x-conformance=sidf_compatible; x-record-type="v=spf1"
Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mail-lb0-f182.google.com) identity=helo;
  client-ip=209.85.217.182;
  receiver=mail4-smtp-sop.national.inria.fr;
  envelope-from="lambda.q.q@gmail.com";
  x-sender="postmaster@mail-lb0-f182.google.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtoBAK2WoFDRVdm2m2dsb2JhbABEw04IIwEBAQEBCAkLCRQngh4BAQQBJxMGATgBAwwBBQUhJQ8BBCABBQE1G4ddAwkGBJ0XjyqEICcNiU4BBQyMJIMIgycDiFSJdoMyjmI/gViCPg
X-IronPort-AV: E=Sophos;i="4.80,759,1344204000"; 
   d="scan'208";a="162105456"
Received: from mail-lb0-f182.google.com ([209.85.217.182])
  by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 12 Nov 2012 07:30:07 +0100
Received: by mail-lb0-f182.google.com with SMTP id gg13so1169428lbb.27
        for <caml-list@inria.fr>; Sun, 11 Nov 2012 22:30:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=sender:from:to:cc:subject:references:date:in-reply-to:message-id
         :user-agent:mime-version:content-type;
        bh=0V7x5HUiEfjtGM76UA2tZiMJ6cRjF6131NXb2/BXYPg=;
        b=mQrzyP/jpIOv73r5P/rNExK+Yxh3qKhmhuRQn74eqnEQAAh6xxQb/sEfSBnYXmpsbd
         y7MKcTTLu/T13jxyKJuWPu+g4P9qJSwLVn8VlwsYLK48JtFODFMDHt4KqNTBlwY+prpb
         3f85LVFGQpAgOD2cLRRqyPGIPDw7NyBcLyHJNF56uSn03L6y/xE9IJ8sWtvzRbulMEqm
         UF5LbiDioKpgDtmnEPW/hIkk8NkwhPBCzWCJs3Tfl7uqXiR6eselSoOKw5DaiNWCgVfQ
         gPrpQUtLiA7PdYzrh+gRzab045A5pPmENvp0UvumMgR2v64uNsA0CueUC71MtwK0zY2V
         YvPg==
Received: by 10.112.36.42 with SMTP id n10mr7530003lbj.42.1352701806130;
        Sun, 11 Nov 2012 22:30:06 -0800 (PST)
Received: from golf.niidar.ru.niidar.ru ([178.177.199.212])
        by mx.google.com with ESMTPS id sj3sm2044980lab.2.2012.11.11.22.30.04
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sun, 11 Nov 2012 22:30:04 -0800 (PST)
Sender: Ivan Gotovchits <lambda.q.q@gmail.com>
From: Ivan Gotovchits <ivg@ieee.org>
To: oleg@okmij.org
Cc: Didier.Cassirame@gmail.com,  caml-list@inria.fr
References: <20121106114823.63702.qmail@www1.g3.pair.com>
Date: Mon, 12 Nov 2012 10:29:53 +0400
In-Reply-To: <20121106114823.63702.qmail@www1.g3.pair.com> (oleg@okmij.org's
	message of "6 Nov 2012 11:48:23 -0000")
Message-ID: <87wqxrtjtq.fsf@golf.niidar.ru>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Caml-list] Re: Higher order functors over tuples


oleg@okmij.org writes:
> That seems to be the right problem for existentials -- which exist in
> OCaml under the name of objects. Methods are the interface and fields
> are private data. Of course we can get by with mere records -- but if
> we have objects anyway we might as well use them.

Yes, but objects suffer from two slight problems: lower performance due
to dynamic method dispatching and some issues with type system. Well,
not an issues really, but I think that you understood me. Though it
seems that this problems do not outweight the power of object system,
that was gracefully demonstrated by you.

In my real application I do shifted to objects. Though I still define
modules and then use functors as factories, producing objects of the
particular types. I'm not sure that this dual solution worths, but I
feel myself more comfortable with modules, rather than objects.

And, by the way, I've met the following signatures many times in
different frameworks written in different languages (matlab functional
objects, GnuRadio blocks, to name a few):

>>    module type Generator =
>>    sig
>>      type t
>>      type r
>>      val create: unit  -> t
>>      val result: t -> r option
>>      val step:   t -> t option
>>    end

extended with Transformer and Consumer:

  module type Consumer = 
  sig 
    type t
    type d
    val push: d -> t -> t
    val step: t -> t option
  end

  module type Transformer =
  sig
    type t
    type d
    type r
    val push: d -> t -> t
    val step: t -> t option
    val result: t -> r option
    (* or include Transformer and Consumer in ocaml 3.12+ *)        
  end

Haven't you seen this pattern in functional programming? May be it can
be expressed in a more natural way using FP idioms?


-- 
         (__) 
         (oo) 
   /------\/ 
  / |    ||   
 *  /\---/\ 
    ~~   ~~   
...."Have you mooed today?"...