Hi,

You cannot have a circular recursi= ve definition

let rec ls =3D [1; 2; 3; ls; ] ;;

but you can have a "circular" list:

let rec ls =3D [1; 2; 3;] :: = ls ;;

it creates 40 items,

the first 38 are = [1; 2; 3;] and the 39 is

[1; 2; ...]; and the last [...].&n= bsp;

We cannot say it is a true 'circular' list, because

we don't return from the last element to the

first elemen= t. At any rate this will result

in an expression that is nested = too deep and

we won't be able to use it. The ellipsis [...] has<= /div>

the force of 'any' but it returns the same element

as b= efore, a list of lists. An example of a not

very useful circular = list in the literature

shows a continuous loop

let rec= process =3D 1 :: 2 :: 3 :: 4 :: 5 :: process;;

while true do

let process :: process =3D process in

printf "Handling process %d\n" process;

Unix.sleep = 2;

done ;;

From: Peter Frey <pjfrey@sympatico.ca>
= To: Eric Jaeger (ANSSI) &= lt;eric.jaeger@ssi.gouv.fr>
Cc= : caml-list@inria.fr
= Sent: Thursday, December 27, 2012 8:41 PM
Subject: Re: [Caml-list] Function returning = recursive lists

On Sat, 2012-12-22 at 11:53 +0100, Eric Jaeger (ANSSI) wrote:
> On 2= 1/12/2012 20:55, Peter Frey wrote:
> > It sometimes helps to read = read the various libraries.
> > For example, this thing is a varia= tion of Batteries.BatList.Append:
> >
> > module Cycle = =3D struct
> > type 'a mut_list =3D { hd: 'a; mutable= tl: 'a list }
> > external inj : 'a mut_list -> '= a list =3D "%identity"
> > external jni : 'a list -&g= t; 'a mut_list =3D "%identity"
> As far as I know, the use of "%ident= ity" is a trick which is similar to
> Obj, telling the compiler to d= o nothing. You would not be allowed to do
> that with standard, type= d OCaml identity. In this sense, it is not the
> sort of solution I'= m looking for.
>
> Regards, Eric

For what = it's worth: Obj.ml, contains the line:
...
external magic : 'a -> 'b =3D "%identity"<= br>...
That type allows anything, including 'unifying' any two types.(The compiler does not do nothing: it assigns the argument of type 'a tobe the result which is of type 'b and is perfectly willing to produce
= code that instantly causes a segmentation fault)

inj and its inverse= jni seem to have a type at least a bit more friendly
since they control= the usage of the individual fields.
As long as you trust Ocaml lists to= always have the layout above, this
seems a lot saver to me than type 'a= -> 'b.

You wanted, in effect, something like:
# let rec l =3D= [1;2;3;l];;
Error: This expression has type int list
&= nbsp; but an expression was expected of type int

The type 'a list i= s built into the system; it is not recursive and if
there was a way to f= orce it to be so (without hacks), the type system
would not be sound.

You know the following, of course:

# type 'a aRec =3D= {mutable hd: 'a; mutable tl:'a aRec};;
type 'a aRec =3D { mutable hd : = 'a; mutable tl : 'a aRec; }

# let rec a =3D {hd=3D1; tl=3Da};; =
val a : int aRec =3D
{hd =3D 1;=
tl =3D
{hd =3D 1;
tl =3D
= {hd =3D 1;
tl =3D
&= nbsp; {hd =3D 1;
tl =3D
The problem with docycle is not its coding style but that it produces in<= br>fact a cyclic list, which is not very useful: Almost all functions, such=
as List.rev are undefined.

Peter

-- =
Caml-list mailing list. Subscription management and archives:
= ht= tps://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

= --303371348-562022172-1356687451=:79354-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 CE95B7EE94 for ; Fri, 28 Dec 2012 13:21:37 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of philippe.wang.lists@gmail.com) identity=pra; client-ip=209.85.212.176; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="philippe.wang.lists@gmail.com"; x-sender="philippe.wang.lists@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of philippe.wang.lists@gmail.com designates 209.85.212.176 as permitted sender) identity=mailfrom; client-ip=209.85.212.176; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="philippe.wang.lists@gmail.com"; x-sender="philippe.wang.lists@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-wi0-f176.google.com) identity=helo; client-ip=209.85.212.176; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="philippe.wang.lists@gmail.com"; x-sender="postmaster@mail-wi0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcKAH+N3VDRVdSwk2dsb2JhbAA8CasTg0yPAAgWDgEBAQEJCQsJFAQjgh4BAQQBJxkBLQsBAwELAQUFCwMDBAEBAQ0hIhIBBQEKCggGExIJh2YDCQYMmRGPLoR4JwMKiGsBBQyLYWoFDQQFhCgDjVSGZoFSgRyKG4MxFimBV4I/gWQIFw X-IronPort-AV: E=Sophos;i="4.84,369,1355094000"; d="scan'208";a="187802365" Received: from mail-wi0-f176.google.com ([209.85.212.176]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Dec 2012 13:21:37 +0100 Received: by mail-wi0-f176.google.com with SMTP id hm6so8209805wib.3 for ; Fri, 28 Dec 2012 04:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BS4wVrPJ2EBONxJc8g0L+v0HxlIrMQzI3vH9VB8hIsI=; b=GDeTh9nTOAMjIX7HWYZ0R8hmxKDH8ejtNaC74jo0iGCExmiZ0TuWacMAYXqqqTOfMy mE3mkVPjEVXGQa9ebTtnqjMP8vULLi2ZsJXgX40wpzDlRPzVYP0mOzFIHN9m5SnQ2kIN qpye2D0HsqIvSnI8fYpwYke25nM2tb46szKHTyhULr/lVDcpDPKLlUqM90W5kEYZMvgl HVzmr0yw9N80j6PjGnLbDN17l/oVChE5bWVIIG8kypMvw5h+8GeV10xH6zYQF/sOrFY1 jKg5eu5kyVFYyVbZW1q/vLe77aD5KsRs5L5+M9Ts4wF5aVOoVcF9eVkzp6ydKDteWv3k 3jxQ== MIME-Version: 1.0 Received: by 10.180.99.72 with SMTP id eo8mr45148431wib.34.1356697296878; Fri, 28 Dec 2012 04:21:36 -0800 (PST) Sender: philippe.wang.lists@gmail.com Received: by 10.216.16.82 with HTTP; Fri, 28 Dec 2012 04:21:36 -0800 (PST) In-Reply-To: <1356687451.79354.YahooMailNeo@web163402.mail.gq1.yahoo.com> References: <50D59147.3000201@ssi.gouv.fr> <1356687451.79354.YahooMailNeo@web163402.mail.gq1.yahoo.com> Date: Fri, 28 Dec 2012 13:21:36 +0100 X-Google-Sender-Auth: QMIzWAEV3B7WBB9xsMtUQNeUtqE Message-ID: From: Philippe Wang To: Arkady Andrukonis Cc: "caml-list@inria.fr" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Function returning recursive lists > let rec ls = [1; 2; 3;] :: ls ;; > it creates 40 items, > the first 38 are [1; 2; 3;] and the 39 is > [1; 2; ...]; and the last [...]. Actually, no, it does *not* create 40 items at all: the printer make no difference between circular data and big data. If one creates a list with 1000 elements, only the first X elements are displayed by "ocaml top-level interactive loop". (X depends on the size of the printed data) If the 39th is "[1; 2; ...]", it's only because the printer has reached the limit at "2" and won't go further to "see" that there's only a "3" remaining in that list. (Reminder: computers are particularly dumb, they only do (exactly) what we tell them to do.) let rec ls = [1; 2; 3;] :: ls ;; allocates [1; 2; 3;] and then a circular block (b) containing two elements: 1. a pointer to that list ([1; 2; 3;]) and 2. a pointer to itself (b). Try this: Array.to_list (Array.make 1000 42);; And maybe try this: List.length (Array.to_list (Array.make 1000 42));; Cheers, Philippe Wang On Fri, Dec 28, 2012 at 10:37 AM, Arkady Andrukonis wrote: > Hi, > > You cannot have a circular recursive definition > let rec ls = [1; 2; 3; ls; ] ;; > but you can have a "circular" list: > let rec ls = [1; 2; 3;] :: ls ;; > it creates 40 items, > the first 38 are [1; 2; 3;] and the 39 is > [1; 2; ...]; and the last [...]. > We cannot say it is a true 'circular' list, because > we don't return from the last element to the > first element. At any rate this will result > in an expression that is nested too deep and > we won't be able to use it. The ellipsis [...] has > the force of 'any' but it returns the same element > as before, a list of lists. An example of a not > very useful circular list in the literature > shows a continuous loop > let rec process = 1 :: 2 :: 3 :: 4 :: 5 :: process;; > while true do > let process :: process = process in > printf "Handling process %d\n" process; > Unix.sleep 2; > done ;; > ________________________________ > From: Peter Frey > To: Eric Jaeger (ANSSI) > Cc: caml-list@inria.fr > Sent: Thursday, December 27, 2012 8:41 PM > Subject: Re: [Caml-list] Function returning recursive lists > > On Sat, 2012-12-22 at 11:53 +0100, Eric Jaeger (ANSSI) wrote: >> On 21/12/2012 20:55, Peter Frey wrote: >> > It sometimes helps to read read the various libraries. >> > For example, this thing is a variation of Batteries.BatList.Append: >> > >> > module Cycle = struct >> > type 'a mut_list = { hd: 'a; mutable tl: 'a list } >> > external inj : 'a mut_list -> 'a list = "%identity" >> > external jni : 'a list -> 'a mut_list = "%identity" >> As far as I know, the use of "%identity" is a trick which is similar to >> Obj, telling the compiler to do nothing. You would not be allowed to do >> that with standard, typed OCaml identity. In this sense, it is not the >> sort of solution I'm looking for. >> >> Regards, Eric > > For what it's worth: Obj.ml, contains the line: > ... > external magic : 'a -> 'b = "%identity" > ... > That type allows anything, including 'unifying' any two types. > (The compiler does not do nothing: it assigns the argument of type 'a to > be the result which is of type 'b and is perfectly willing to produce > code that instantly causes a segmentation fault) > > inj and its inverse jni seem to have a type at least a bit more friendly > since they control the usage of the individual fields. > As long as you trust Ocaml lists to always have the layout above, this > seems a lot saver to me than type 'a -> 'b. > > You wanted, in effect, something like: > # let rec l = [1;2;3;l];; > Error: This expression has type int list > but an expression was expected of type int > > The type 'a list is built into the system; it is not recursive and if > there was a way to force it to be so (without hacks), the type system > would not be sound. > > You know the following, of course: > > # type 'a aRec = {mutable hd: 'a; mutable tl:'a aRec};; > type 'a aRec = { mutable hd : 'a; mutable tl : 'a aRec; } > > # let rec a = {hd=1; tl=a};; > val a : int aRec = > {hd = 1; > tl = > {hd = 1; > tl = > {hd = 1; > tl = > {hd = 1; > tl = > > The problem with docycle is not its coding style but that it produces in > fact a cyclic list, which is not very useful: Almost all functions, such > as List.rev are undefined. > > > Peter > > > > > > -- > 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 > > -- Philippe Wang mail@philippewang.info From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 2009A7EE94 for ; Fri, 28 Dec 2012 13:30:34 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of philippe.wang.lists@gmail.com) identity=pra; client-ip=209.85.212.170; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="philippe.wang.lists@gmail.com"; x-sender="philippe.wang.lists@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of philippe.wang.lists@gmail.com designates 209.85.212.170 as permitted sender) identity=mailfrom; client-ip=209.85.212.170; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="philippe.wang.lists@gmail.com"; x-sender="philippe.wang.lists@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-wi0-f170.google.com) identity=helo; client-ip=209.85.212.170; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="philippe.wang.lists@gmail.com"; x-sender="postmaster@mail-wi0-f170.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIKAKaQ3VDRVdSqk2dsb2JhbABFrl+PAAgWDgEBAQEJCQsJFAQjgh4BAQQBQAE4AQMBCwEFBQsDOCISAQUBHAYTiAEDCQaZIY8uhHgnDYhrAQUMjEsbhCgDjVSIOI5oFimBV4I/gWw X-IronPort-AV: E=Sophos;i="4.84,369,1355094000"; d="scan'208";a="166954013" Received: from mail-wi0-f170.google.com ([209.85.212.170]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Dec 2012 13:30:04 +0100 Received: by mail-wi0-f170.google.com with SMTP id hq7so5086405wib.5 for ; Fri, 28 Dec 2012 04:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=I3NOxJT9i2aphb+bBGqAW1L1yJgeagpEhp9TpRpjvkk=; b=BEO7hwvBFikmlTTKadwiyccp6g6JZ/xadXHdeiyLncG/4SGY+J7wydw5uCx666y+Sp opI1r8tErYlHvak7875jSNo5fa4IJyfc2AqPJDMhmp4MV2ojdWrjlCLWx1XzHYOmpzqH IljwWP3HM/NQ5A0z6bHOjCdAZsLe/2rQYfZPgBR4ukO3YUsQ5yP0CYy5EYGza+DVAXZz iFtdsYutUPaTa95P0hVYLX2udXBKvPF8R6MlapSr23aYNavlSczJsdJaMPj3JF+g51ED k0Bjv3NqyXoBtg+xrsn3RqRkSiv64E+gMndO8h7zTCa7WNOnkYjShczy1snxKIsqSf4r gd8A== MIME-Version: 1.0 Received: by 10.180.75.208 with SMTP id e16mr52630594wiw.3.1356697803563; Fri, 28 Dec 2012 04:30:03 -0800 (PST) Sender: philippe.wang.lists@gmail.com Received: by 10.216.16.82 with HTTP; Fri, 28 Dec 2012 04:30:03 -0800 (PST) In-Reply-To: References: <50D59147.3000201@ssi.gouv.fr> Date: Fri, 28 Dec 2012 13:30:03 +0100 X-Google-Sender-Auth: p93B1IRhuip12yIbgxmzNhvTFNY Message-ID: From: Philippe Wang To: Peter Frey Cc: "Eric Jaeger (ANSSI)" , OCaml Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Function returning recursive lists On Fri, Dec 28, 2012 at 2:41 AM, Peter Frey wrote: > The problem with docycle is not its coding style but that it produces in > fact a cyclic list, which is not very useful: Almost all functions, such > as List.rev are undefined. >From my point of view, this coding style is fundamentally *wrong*: - it makes assumptions on the internal data representation, - and it prevents the compiler from making any optimisation from the fact that elements of built-in lists are immutable (and if the compilers makes some optimisations from that fact, then it's not only the style but the program that is wrong). Cheers, -- Philippe Wang mail@philippewang.info From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 D69277EE94 for ; Fri, 28 Dec 2012 16:22:25 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of didier.cassirame@gmail.com) identity=pra; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="didier.cassirame@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of didier.cassirame@gmail.com designates 209.85.214.182 as permitted sender) identity=mailfrom; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="didier.cassirame@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-ob0-f182.google.com) identity=helo; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="postmaster@mail-ob0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnABAK643VDRVda2jWdsb2JhbABFhjqkWJJLCBYOAQEBAQkJCwkSBiOCHgEBBSMdARsSCwEDDAYFCwMKAgIJHQICIgERAQUBChIGExKHbgEDDwyZLItkT4J7hE4KGScDClmIEgEFDIEWizUbgxWBEwOWDIEcjUwWKYQWgWw X-IronPort-AV: E=Sophos;i="4.84,370,1355094000"; d="scan'208";a="166963228" Received: from mail-ob0-f182.google.com ([209.85.214.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Dec 2012 16:22:24 +0100 Received: by mail-ob0-f182.google.com with SMTP id 16so9720483obc.27 for ; Fri, 28 Dec 2012 07:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DMsubi7Ml/M8pGLsHFtcT9NUcSWL5Nhu6ZEv9KllcLQ=; b=xzq644ZH3Onh57tvFHmIrGWZNYRguKe8nrI1rltt+nGauCl6hmvfB+X2WFQJFBnDvR Awjb7xpybNsobAUmiVsj898FNxpRWWYczb4Jm62+PdP/DgZwOVt8wL4C9ySERiwm1/aP Qu1Y3LMtj7uycZW9Wo+w6bFD72TZhJjRtxDMtnutLDPHaEZyz6fjhwNqtsqtrrMlOKOD Q8jw8DgSsqVpAnefK3cljV3Q2562ddN0IbJL15SUuR/1fzmXZRw75C3w67g1Lc4F6nOG IflS1hHZXZ9wzIoYz4O0LaMQecL1nnYyJ5teZeu4hdEOiEbCw1fPEBFVzEMXeMjgqrDp kRaQ== MIME-Version: 1.0 Received: by 10.60.32.33 with SMTP id f1mr16208793oei.122.1356708143657; Fri, 28 Dec 2012 07:22:23 -0800 (PST) Received: by 10.60.165.8 with HTTP; Fri, 28 Dec 2012 07:22:23 -0800 (PST) In-Reply-To: References: <50D59147.3000201@ssi.gouv.fr>

Date: Fri, 28 Dec 2012 16:22:23 +0100 Message-ID: From: Didier Cassirame To: Philippe Wang Cc: Peter Frey , "Eric Jaeger (ANSSI)" , OCaml Mailing List Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Function returning recursive lists Hi all, Regarding the original question, wouldn't it be easier to implement it as a stream? didier 2012/12/28, Philippe Wang : > On Fri, Dec 28, 2012 at 2:41 AM, Peter Frey wrote: > >> The problem with docycle is not its coding style but that it produces in >> fact a cyclic list, which is not very useful: Almost all functions, such >> as List.rev are undefined. > > From my point of view, this coding style is fundamentally *wrong*: > - it makes assumptions on the internal data representation, > - and it prevents the compiler from making any optimisation from the > fact that elements of built-in lists are immutable (and if the > compilers makes some optimisations from that fact, then it's not only > the style but the program that is wrong). > > Cheers, > > -- > Philippe Wang > mail@philippewang.info > > -- > 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 721F07EE94 for ; Fri, 4 Jan 2013 01:45:44 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.161; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.161 as permitted sender) identity=mailfrom; client-ip=134.160.33.161; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.161 as permitted sender) identity=helo; client-ip=134.160.33.161; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8CAAsl5lCGoCGhkWdsb2JhbABFhjqkSJJkDgEBAQEUEhQngh4BAQQBIxU2CgYLCxgCAgUEEgsCAgkDAgECATMSEwYCAQEOh28DCQYMpxeIVwOGbYEiizUbf4IWgRMDiGCNLIEchE+NYIFi X-IronPort-AV: E=Sophos;i="4.84,406,1355094000"; d="scan'208";a="188399997" Received: from postman1.riken.jp (HELO postman.riken.jp) ([134.160.33.161]) by mail1-smtp-roc.national.inria.fr with ESMTP; 04 Jan 2013 01:45:42 +0100 Received: from postman.riken.jp (postman1.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id 3599032C01E4 for ; Fri, 4 Jan 2013 09:45:39 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id 65B4632A0047 for ; Fri, 4 Jan 2013 09:45:38 +0900 (JST) Message-ID: <50E62632.4060208@riken.jp> Date: Fri, 04 Jan 2013 09:45:38 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <50D59147.3000201@ssi.gouv.fr>

In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.4.3325 Subject: Re: [Caml-list] Function returning recursive lists On 12/29/2012 12:22 AM, Didier Cassirame wrote: > Hi all, > > Regarding the original question, wouldn't it be easier to implement it > as a stream? It smells as someone needs a stream or a lazy list indeed. Happy new year! ;) > didier > > 2012/12/28, Philippe Wang : >> On Fri, Dec 28, 2012 at 2:41 AM, Peter Frey wrote: >> >>> The problem with docycle is not its coding style but that it produces in >>> fact a cyclic list, which is not very useful: Almost all functions, such >>> as List.rev are undefined. >> >> From my point of view, this coding style is fundamentally *wrong*: >> - it makes assumptions on the internal data representation, >> - and it prevents the compiler from making any optimisation from the >> fact that elements of built-in lists are immutable (and if the >> compilers makes some optimisations from that fact, then it's not only >> the style but the program that is wrong). >> >> Cheers, >> >> -- >> Philippe Wang >> mail@philippewang.info >> >> -- >> 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 >> >