From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6A02E7EE4B for ; Fri, 11 Oct 2013 08:11:46 +0200 (CEST) Received-SPF: None (mail2-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=mail2-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-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=mail2-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 (mail2-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=mail2-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: AqsBAEmWV1KGoCGhnGdsb2JhbABZgz+De6s+kmKBOw4BAQEBAQgLCQkUKIIlAQEEASMEETYKEQsYAgIFBBIIAwICCQMCAQIBDyQBERMGAgEBDgcBh1oDCQYMqB6ITwMKiWuBKYsxgnSCaoE5A4k6jGKBaYEvhQmGFIhp X-IPAS-Result: AqsBAEmWV1KGoCGhnGdsb2JhbABZgz+De6s+kmKBOw4BAQEBAQgLCQkUKIIlAQEEASMEETYKEQsYAgIFBBIIAwICCQMCAQIBDyQBERMGAgEBDgcBh1oDCQYMqB6ITwMKiWuBKYsxgnSCaoE5A4k6jGKBaYEvhQmGFIhp X-IronPort-AV: E=Sophos;i="4.90,1078,1371074400"; d="scan'208";a="36519206" Received: from postman1.riken.jp (HELO postman.riken.jp) ([134.160.33.161]) by mail2-smtp-roc.national.inria.fr with ESMTP; 11 Oct 2013 08:11:27 +0200 Received: from postman.riken.jp (postman1.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id F0F012588001 for ; Fri, 11 Oct 2013 15:11:25 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id B1BA032A0085 for ; Fri, 11 Oct 2013 15:11:25 +0900 (JST) Message-ID: <5257964B.5020508@riken.jp> Date: Fri, 11 Oct 2013 15:10:19 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: caml-list@inria.fr References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.11.55414 Subject: Re: [Caml-list] Pattern matching on refs On 10/11/2013 01:49 PM, Arnaud Spiwack wrote: > If you need queues with random access, and do not need highly tuned > performances, may I suggest you having a look at Okasaki's /Purely > functional datastructures/. There are several OCaml implementations available. I know this one (and have seen others here and there also): https://bitbucket.org/mmottl/pure-fun > It has a handful of these, which do not > involve assignment (they use laziness annotation, though, for good > amortized performances). It would make your life better. The book > version has a little more than the thesis, by the way. > > > On 10 October 2013 21:46, Yotam Barnoy > wrote: > > D'oh! I always forget about mutable fields somehow. Refs just take > over in my mind and I end up putting them everywhere I need > mutability. Shows how little I actually use mutability in ocaml. > > And the reason for the linked lists is that I need a > (low-performance) queue/stack with random access. And the reason for > implementing a doubly-linked list myself is that my advisor is > against using any library that's not part of the ocaml distribution. > > Sorry for the disturbance folks. Move along! > > -Yotam > > > On Thu, Oct 10, 2013 at 3:42 PM, David Allsopp > > wrote: > > Yotam Barnoy wrote: > > I recently found out how ugly it is to pattern-match on a ref, > > using {contents=...}. This should be extremely easy to fix in > > the parser. Can it please be put into the next version of ocaml? > > I imagine there are those who might suggest that the ugliness of > pattern matching on refs is part of the discouragement against > using them! > > > match x with > > | ref y -> ... > > I'm guessing that you're really pattern matching with refs > inside tuples or something which makes using !x impractical? > That said, if you've ended with up (foo, bar, baz) where at > least one of those is a reference, why not consider using > records with mutable fields? > > While writing this, Yotam Barnoy wrote: > > It wouldn't solve the problem, because in reality > > I'm matching something like this piece of code > > implementing a doubly-linked list: > > > > type 'a cell = { data : 'a; > > next : 'a link ref; > > last : 'a link ref; > > } > > Completely ignoring why you might be implementing linked lists > in a list-processing language (I'm sure there's a good reason!), > why not have > > type 'a cell = {data: 'a; > next: mutable 'a link; > last: mutable 'link} > > ? > > The parser change you propose is probably not trivial - for a > start, "ref" is part of the Pervasives module, not part of the > grammar, and [ref] itself can be redefined (try [let ref x = x] > in the toplevel). Putting something into the grammar to allow > pattern matching on ref like this would at best be a grim hack. > > > David > > -- > 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 > > > -- Best regards, Francois Berenger.