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 59B9A7F706 for ; Sat, 18 Jan 2014 02:18:20 +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.244; 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.244; 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@avasout03.plus.net) identity=helo; client-ip=84.93.230.244; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="postmaster@avasout03.plus.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugCAIjV2VJUXeb0lWdsb2JhbABZg0OpF3qRbIEMFg4BAQEBBw0JCRIqgiUBAQEDAQgCMDQQBwEDAgkRBAEBAQ0aBxkjCQEJCAIEARILBQKHXwMJDAm+KQOFYBeOLgEBVgaCKYIJBI8lhRaFF5QTgXE X-IPAS-Result: AugCAIjV2VJUXeb0lWdsb2JhbABZg0OpF3qRbIEMFg4BAQEBBw0JCRIqgiUBAQEDAQgCMDQQBwEDAgkRBAEBAQ0aBxkjCQEJCAIEARILBQKHXwMJDAm+KQOFYBeOLgEBVgaCKYIJBI8lhRaFF5QTgXE X-IronPort-AV: E=Sophos;i="4.95,677,1384297200"; d="scan'208";a="53789258" Received: from avasout03.plus.net ([84.93.230.244]) by mail2-smtp-roc.national.inria.fr with ESMTP; 18 Jan 2014 02:18:19 +0100 Received: from XPS ([91.125.229.6]) by avasout03 with smtp id FDJH1n00608vflX01DJKHX; Sat, 18 Jan 2014 01:18:19 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=VqIaXYGn c=1 sm=1 tr=0 a=YNNwqyIk8JSiwARLj6s6Lw==:117 a=YNNwqyIk8JSiwARLj6s6Lw==: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=9UulTLQRC9-Du-6xHuEA:9 a=CjuIK1q_8ugA:10 X-AUTH: jdh302:2500 Reply-To: From: "Jon Harrop" To: "'Jonathan Kimmitt'" , References: In-Reply-To: Date: Sat, 18 Jan 2014 01:18:20 -0000 Organization: Flying Frog Consultancy Ltd. Message-ID: <02d801cf13eb$2d53e970$87fbbc50$@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: AQITm23GUPanAma4/sJij0gkqtCZn5oAlzWQ Content-Language: en-gb Subject: RE: [Caml-list] How much optimized is the 'a option type ? Jonathan Kimmitt wrote: > 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. F# has a very good FFI to C#. In particular, it is memory safe. F# has null because it is required for interop with C#. Idiomatic F# code does not use null. Compare with OCaml's memory-unsafe FFI to C... > They also have the notion of initialising a typed object to in an invalid default, > which is another obvious disaster area. When you dequeue an element from a mutable queue that is represented internally as an over-sized array you need to null-out the removed element or you leak everything reachable from that value that would otherwise be unreachable. F# uses Unchecked.defaultof<_> to create a default value of any type (even a value type). The Queue module in the OCaml stdlib uses "Obj.magic None" which works because OCaml doesn't have value types. > Oh and did I mention operators like +/- etc are overloaded so you cannot > infer function types without adding type annotations. In F# the same arithmetic operators work transparently on the byte, sbyte, uint16, int16, uint32, int32, uint64, int64, float, float32, BigInteger and BigRational types as well as decimal, DateTime, vectors, matrices and user-defined types. OCaml has + for int, +. for float and +/ for big rationals and no other numeric types. Imagine what would happen if OCaml supported just the full complement of numeric types, let alone the others? You'd need 15 different operators just to support the numeric types I listed... > 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 agree. :-) Cheers, Jon. -----Original Message----- From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On Behalf Of Jonathan Kimmitt Sent: 17 January 2014 11:24 To: caml-list@inria.fr Subject: Re: [Caml-list] How much optimized is the 'a option type ? 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 ... -- 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