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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id ADC6E7EE99 for ; Wed, 22 Jan 2014 22:26:07 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=pra; client-ip=84.93.230.250; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=mailfrom; client-ip=84.93.230.250; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@avasout05.plus.net) identity=helo; client-ip=84.93.230.250; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="postmaster@avasout05.plus.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkBAKk24FJUXeb6nGdsb2JhbABbg0SpN3qSA4ETFg4BAQEBAQYNCQkUKIIlAQEBBAgCHRM0FwEDAgkRBAEBAQ0aBxkjCQEJCAIEARILBQKHXwMVCb4aA4VgF44rAQFWBoQyBI8mhRaFGJQTgXE X-IPAS-Result: AtkBAKk24FJUXeb6nGdsb2JhbABbg0SpN3qSA4ETFg4BAQEBAQYNCQkUKIIlAQEBBAgCHRM0FwEDAgkRBAEBAQ0aBxkjCQEJCAIEARILBQKHXwMVCb4aA4VgF44rAQFWBoQyBI8mhRaFGJQTgXE X-IronPort-AV: E=Sophos;i="4.95,702,1384297200"; d="scan'208";a="54423274" Received: from avasout05.plus.net ([84.93.230.250]) by mail2-smtp-roc.national.inria.fr with ESMTP; 22 Jan 2014 22:26:07 +0100 Received: from XPS ([91.125.112.34]) by avasout05 with smtp id H9S41n0050kazHn019S6LR; Wed, 22 Jan 2014 21:26:06 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Db0u9JdW c=1 sm=1 tr=0 a=DvnplZMz9B0OTucJM+SM4w==:117 a=DvnplZMz9B0OTucJM+SM4w==:17 a=0Bzu9jTXAAAA:8 a=XCxr5DcLagoA:10 a=Xub9RBUEA-sA:10 a=Kvk-SOs2Z7YA:10 a=kj9zAlcOel0A:10 a=r2vSxAw-AAAA:8 a=BR64nyZ84HQA:10 a=ZOzjf2MOAAAA:8 a=CjxXgO3LAAAA:8 a=uCU_ut-Mvvec_P5HZa4A:9 a=CjuIK1q_8ugA:10 X-AUTH: jdh302:2500 Reply-To: From: "Jon Harrop" To: "'Goswin von Brederlow'" , References: <20140120101654.GI26447@frosties> In-Reply-To: <20140120101654.GI26447@frosties> Date: Wed, 22 Jan 2014 21:26:09 -0000 Organization: Flying Frog Consultancy Ltd. Message-ID: <08bc01cf17b8$9263d070$b72b7150$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHI4li4v5YdVc3QG7JLKEaISEVTZQITm23GAs0uvsGadqOMYA== Content-Language: en-gb Subject: RE: [Caml-list] How much optimized is the 'a option type ? Goswin wrote: > In F#, with nil pointer, that will be a problem. But I guess nobody ever has 'a option option types there I believe the representation of Some None in F# is a heap allocated block containing a NULL pointer. Cheers, Jon. -----Original Message----- From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On Behalf Of Goswin von Brederlow Sent: 20 January 2014 10:17 To: caml-list@inria.fr Subject: Re: [Caml-list] How much optimized is the 'a option type ? On Fri, Jan 17, 2014 at 12:23:32PM +0100, Jonathan Kimmitt wrote: > In my humble opinion the main purpose of Some _ | None is to avoid the > requirement for a nil pointer in OCaml. If an external function wants > to return nil in order to indicate, for example that a certain > resource is not available, it can return None instead and this > prevents dereferencing a nil pointer in OCaml because the None cannot > be dereferenced. If you compare this behaviour with the inferior clone > F# written by Microsoft, you can see that one of the things they added > to the language was a nil pointer, thus abandoning all type safety > immediately and all because they did not want to change their .NET > runtime system for C# etc. They also have the notion of initialising a > typed object to in an invalid default, which is another obvious > disaster area. Oh and did I mention operators like +/- etc are overloaded so you cannot infer function types without adding type annotations. > The final insult is to make indentation significant in the syntax so > that if you post a program to a list which does not respect whitespace > (for example using a well-known Microsoft mail client), it completely > destroys the meaning of the program. > > I'm sure the authors of F# have their reasons for making all these > changes, and I'm not one to stand in the way of progress, and I don't > set out to offend anybody, but I think they got it wrong ... You could use the following representaion for 'a option: None -> NULL pointer Some x -> value x (meaning pointer for complex types, tagged integer eles) This looks fine at first and typesafe. A pointer can never be NULL, same for a tagged integer. BUT None -> NULL Some None -> NULL Some Some x -> value x You could no longer have 'a option option types. In F#, with nil pointer, that will be a problem. But I guess nobody ever has 'a option option types there. MfG Goswin -- 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