From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lukstafi@gmail.com>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by sympa.inria.fr (Postfix) with ESMTPS id 8AA197F2AA
	for <caml-list@sympa.inria.fr>; Wed, 19 Dec 2012 17:46:14 +0100 (CET)
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  lukstafi@gmail.com) identity=pra; client-ip=209.85.220.175;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="lukstafi@gmail.com";
  x-sender="lukstafi@gmail.com"; x-conformance=sidf_compatible
Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of
  lukstafi@gmail.com designates 209.85.220.175 as permitted
  sender) identity=mailfrom; client-ip=209.85.220.175;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="lukstafi@gmail.com";
  x-sender="lukstafi@gmail.com"; x-conformance=sidf_compatible;
  x-record-type="v=spf1"
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mail-vc0-f175.google.com) identity=helo;
  client-ip=209.85.220.175;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="lukstafi@gmail.com";
  x-sender="postmaster@mail-vc0-f175.google.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuwBAIvu0VDRVdyvm2dsb2JhbABEvX8IFg4BAQEBAQgJCwkUJ4IeAQEFQAEbHQEDDAYFCw0uIgERAQUBHAYTiAABAw+ZO4wzgnuFCgoZJw1ZiHYBBQyMQYRDA5YKjmgWKYQW
X-IronPort-AV: E=Sophos;i="4.84,318,1355094000"; 
   d="scan'208";a="186899509"
Received: from mail-vc0-f175.google.com ([209.85.220.175])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Dec 2012 17:46:13 +0100
Received: by mail-vc0-f175.google.com with SMTP id fy7so2548204vcb.34
        for <caml-list@inria.fr>; Wed, 19 Dec 2012 08:46:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        bh=0E0/qZzrqzUuFnu9V2aM0IgC3+ZhrJMvWWAmZc+7l/U=;
        b=tVWn/BeEl6Kudi0jFeZBoxO8UdAefy03IIlBcLGvIm3io+l719geCvoqsmXlLHC0gv
         j1fJPUJTaugtV+V15x6oZouPhB8vseoc+GPpixRQ7NDPjwZkxg6xIg1ik9Gn/jZyomT5
         tGUlOD/axR7RJezL42yTtdXzUr1BjJnw38+RoyG1j25LTmiC+HHCnoDw5CtBSw7m9BjG
         gY99eqDtFqDMdqXIozgPIUpMSwPBrFYdUJ0+u3xV3M4cSod2H89xLV80N7ecExVrxh/x
         89C7S8IGR0DWmtqH+HCf3EWClhEbUSdHrU2olv99VijffareAE4XNT8J47F3Z8TJX+TR
         17fQ==
Received: by 10.52.23.6 with SMTP id i6mr8428605vdf.100.1355935573210; Wed, 19
 Dec 2012 08:46:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.46.80 with HTTP; Wed, 19 Dec 2012 08:45:52 -0800 (PST)
In-Reply-To: <50d06c18.0f5cc20a.16d8.ffff8b8cSMTPIN_ADDED_BROKEN@mx.google.com>
References: <50d02b65.6c4cb40a.66ab.4256SMTPIN_ADDED_BROKEN@mx.google.com>
 <CAG3nF7XbzhxBniyswXE9nrbf9=yOXBum-3WD0a-dyy_EWC2oEw@mail.gmail.com> <50d06c18.0f5cc20a.16d8.ffff8b8cSMTPIN_ADDED_BROKEN@mx.google.com>
From: Lukasz Stafiniak <lukstafi@gmail.com>
Date: Wed, 19 Dec 2012 17:45:52 +0100
Message-ID: <CAJMfKEXE5O8Pi-r5QbmpHea80=Gnu8SnGfXQE+gZvZqWYMjHCg@mail.gmail.com>
To: Eric Jaeger <eric.jaeger@ssi.gouv.fr>
Cc: Caml <caml-list@inria.fr>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Caml-list] Function returning recursive lists

On Tue, Dec 18, 2012 at 2:13 PM, Eric Jaeger <eric.jaeger@ssi.gouv.fr> wrote:
> Thanks all for your answers. The consensus seems to be that it is not
> possible to define an OCaml function returning recursive lists (or more
> generally recursive values), unless using various forms of tricks such as
> lazyness or Obj. So on the one hand we have OCaml functions as results of
> computations which are not analyzable, and on the other hand recursive
> (immutable) values which are analyzable but can only be defined instead of
> being computed.

The restriction is understandable on semantic basis, e.g. you "want"
laziness when you have such recursion. But (1) it can be cumbersome:
call-by-value means I need to inline functions / cannot abstract some
behaviors into functions; (2) it can give unpleasant surprises, for
example when using a state monad hidden behind an abstract data type:
the system does not realize that I'm defining a function.