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 CE8157F6C4 for ; Mon, 20 Jan 2014 11:16:55 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcCALf23FLU4w8EnGdsb2JhbABZugeFT4ENFg4BAQEBAQYNCQkUKIIlAQEBBCcTTwsYCSUPBSiIJAEYvSIfhg4Xji4BAVYWhCIElDyDZYYxEo8EgXA X-IPAS-Result: ArcCALf23FLU4w8EnGdsb2JhbABZugeFT4ENFg4BAQEBAQYNCQkUKIIlAQEBBCcTTwsYCSUPBSiIJAEYvSIfhg4Xji4BAVYWhCIElDyDZYYxEo8EgXA X-IronPort-AV: E=Sophos;i="4.95,689,1384297200"; d="scan'208";a="53982595" Received: from mout.web.de ([212.227.15.4]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 20 Jan 2014 11:16:55 +0100 Received: from frosties.localnet ([37.49.32.119]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0MPowc-1W1K1U33PG-004xod for ; Mon, 20 Jan 2014 11:16:54 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1W5BuY-0007Jj-7c for caml-list@inria.fr; Mon, 20 Jan 2014 11:16:54 +0100 Date: Mon, 20 Jan 2014 11:16:54 +0100 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20140120101654.GI26447@frosties> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:s2howoin1c7QMLA1LkB1pdWG6o08jXmka9Od4kFWTpmeA1/+99A I2E4eCV4mDQ0J16QE1CafSeSAG7NFlbTTiOViyxRI8p09A1LCJy+xMUJ+Mzo8PazEqR2Vn6 aCxruhq5uZ41qpImCYc82KR8pxKDAp5B/3DAVQQHUlNzw+treb1C/aSW/Q+aO1s6lP4/hi8 H2YV0MocpIuqCi3szxk8w== 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