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 c5ff346549e7 (Postfix) with ESMTPS id 566C45D5 for ; Sun, 24 Jan 2021 16:07:45 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.79,371,1602540000"; d="scan'208";a="488748865" Received: from prod-listesu18.inria.fr (HELO sympa.inria.fr) ([128.93.162.160]) by mail2-relais-roc.national.inria.fr with ESMTP; 24 Jan 2021 17:07:43 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id DEFEDE00C7; Sun, 24 Jan 2021 17:07:43 +0100 (CET) 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 B5CB9E00C9 for ; Sun, 24 Jan 2021 17:07:41 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=oliver@first.in-berlin.de; spf=None smtp.mailfrom=oliver@first.in-berlin.de; spf=None smtp.helo=postmaster@einhorn-mail-out.in-berlin.de IronPort-PHdr: =?us-ascii?q?9a23=3A/YzDRxIAlrPHZJHN19mcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgeLf3xwZ3uMQTl6Ol3ixeRBMOHsqMC0bOd4/yoGTRZp8rY7zZaKN0EfiRGoP?= =?us-ascii?q?1epxYnDs+BBB+zB9/RRAt+Iv5/UkR49WqwK0lfFZW2TVTTpnqv8WxaQU2nZkJ6?= =?us-ascii?q?KevvB4Hdkdm82fys9J3PeQVIgye2ba9vIBmsogjdq80bjZF8JqosxRfEoXRFcP?= =?us-ascii?q?lSyW90OF6fhRnx6tqy8ZJ57yhcp/ct/NNcXKvneKg1UaZWByk8PWAv483ruxjD?= =?us-ascii?q?TQ+R6XYZT24bjBlGDRXb4R/jRpv+vTf0ueR72CmBIM35Vqs0Vii476dqUxDnli?= =?us-ascii?q?EKPCMk/W7Ni8xwiKVboA+9pxF63oXZbp2ZOOZ4c6jAe94RWGhPUdtLVyFZDI2y?= =?us-ascii?q?b5UBAfcCM+ZWoIbyu0YBohmlCAmwGO/i0CNEimPq0aA41ekqDAHI3BYnH9ILqH?= =?us-ascii?q?natdH1NKYMUe+r1qnD0CjOYOlQ2Tjg9ofIdg0qrPaLXbJ0cMrR11cgFxneg1We?= =?us-ascii?q?qIzlJSiV1vgXv2ia6epsTPmghHA9qwF1ozivwN0ghZTXiY8MzF3P6Cp2zpovK9?= =?us-ascii?q?KiVE57fcCrEIFWtyyCK4Z4TN0vT3x0tCg117ALpJC1cTQFxpopyRDRZOKKfpWH?= =?us-ascii?q?7BzjSOqfLjV1iW5ldb6imRq/80qtx+n8WMWo31hHqixImcTPuHAVzxHf9NWLR/?= =?us-ascii?q?ln8ku83TuC1Rrf5+JYLUwui6bXNpgsyaMqmJUJq0TMBCr2lV32jKCIckUk/fCl?= =?us-ascii?q?5PrmYrXgpp+cMJV0igfnPqQrgMO/AOA4PhEJX2iG5eSwzrzj/UvgTLpRkPI2iK?= =?us-ascii?q?3ZsJHcJcgBu6G2HRdZ0ocl6xmhEzeryMoUkWQFIV5fZR6Ki4rkN0vNLfzkF/uz?= =?us-ascii?q?nUmgnC9ux//cP73hBpvNLmLEkLfkZbt97EpcyAstzd9B/ZJZEb8BIPPpWk/qqN?= =?us-ascii?q?zUFB45Mwqtz+n8Ftp9zIceWWOJAqODLazdr0eE5vgzLOmUeI8VpDH9JuA56PH0?= =?us-ascii?q?iH85nUYRfa2o3ZsMdHC1Be9mIkWcYXr0mNgNC2YKvgwkTOzrklKOSzBTZ2zhF5?= =?us-ascii?q?47szoyDYbjCYbYWqishqaA1WG1BM54fGdDX3eIEGnlbc2uUvEAZSbadshlkyIJ?= =?us-ascii?q?T5CvSpU6yVevskrwxqBjL+yS9iBO5sGr78R8++CGzUJ6zjdzFcnIizjQHVExpX?= =?us-ascii?q?sBQnoN5I46oUF5zQzag6V5hfxfD9oW4vpIVkI9KIKazuo/Ad3oXgPHONuEGg7/?= =?us-ascii?q?E4eWRAopR9d0+OcgJkN0GtGslBfGhXL4Db4PjKDNBZpx+K/G23n3YcpwmS6fiP?= =?us-ascii?q?sRymI+S84KDlWIw7Zl/lKLVYDIiV6F0aesMK4RxirM8iGPwDjWsQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAAAWmg1glxVQxdligQmDRYICATIvh?= =?us-ascii?q?ECJBIY8ghcDnEELAQMBCwEBLwQBAYRKAoF4Ah0GBjQTAhABAQUBAQECAQMDBAE?= =?us-ascii?q?TAQEBAQEBAQEJFgaGHYI4IoMaAQQBI1sLCxoCJgICVxmDJoJWAw4ks0CBMoVZg?= =?us-ascii?q?kQiTYFEgQ4qjT4mG4IAgUeCNS4+hQuCTIJgBIM3CUMrRFAZAYEVAo8nqQCBb4E?= =?us-ascii?q?SgR2aQw8igSORcY9ksTGEQwIKBxaBbYF6MxoIHBQ7gmlQGQ2NRXaOMEADMDcCB?= =?us-ascii?q?goBAQMJjBUBAQ?= X-IPAS-Result: =?us-ascii?q?A0DWAAAWmg1glxVQxdligQmDRYICATIvhECJBIY8ghcDnEE?= =?us-ascii?q?LAQMBCwEBLwQBAYRKAoF4Ah0GBjQTAhABAQUBAQECAQMDBAETAQEBAQEBAQEJF?= =?us-ascii?q?gaGHYI4IoMaAQQBI1sLCxoCJgICVxmDJoJWAw4ks0CBMoVZgkQiTYFEgQ4qjT4?= =?us-ascii?q?mG4IAgUeCNS4+hQuCTIJgBIM3CUMrRFAZAYEVAo8nqQCBb4ESgR2aQw8igSORc?= =?us-ascii?q?Y9ksTGEQwIKBxaBbYF6MxoIHBQ7gmlQGQ2NRXaOMEADMDcCBgoBAQMJjBUBAQ?= X-IronPort-AV: E=Sophos;i="5.79,371,1602540000"; d="scan'208";a="488748838" X-MGA-submission: =?us-ascii?q?MDFoloLnycli+byqRQsdVWR/SFs0/cmnSTL+St?= =?us-ascii?q?fQtaNo6rKKYGf05jh+HREnxfZ0S94VVA1nVby8pkYsowG4yHBhY6ohsa?= =?us-ascii?q?rUJPiueFOXXg5Guqom+JjbAIDxui/wt1FOPX8B/fnxpdI5N6OhnAIgF3?= =?us-ascii?q?cIVao3kqJGXeqQOnZgU7Gq6Q=3D=3D?= Received: from einhorn-mail-out.in-berlin.de ([217.197.80.21]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2021 17:07:40 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from authenticated.user (localhost [127.0.0.1]) by einhorn.in-berlin.de with ESMTPSA id 10OG7eCJ021402 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Sun, 24 Jan 2021 17:07:40 +0100 Date: Sun, 24 Jan 2021 17:07:29 +0100 From: Oliver Bandel To: caml-list@inria.fr Message-ID: <20210124160729.iybuih6mmaquulcw@first.in-berlin.de> References: <41485ac7-50cf-08fe-4206-b9f863c4d2f5@web.de> <20210124143420.443qexv5dvgtqpbm@first.in-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Caml-list] Detecting missed checks for error indications in ML code Reply-To: Oliver Bandel X-Loop: caml-list@inria.fr X-Sequence: 18381 Errors-To: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: Quoting Markus Elfring (snt: 2021-01-24 16:52 +0100 CET) (rcv: 2021-01-24 16:52 +0100 CET): > > But OCaml isn't just only a functional language. > > It's also a typed language. And the type system can help you at this point. > > You can use the option-type for indicating missing data. > > I am looking more for possibilities to avoid missed checks for return values > from some function calls. I'm not sure what your problem is, which you want to solve. Do you want to improve your programming (aka "coding") style? Or do you have to deal with some code written by other people and you fear that it's not using the type system to avoid the problem of unclear (in the sense of "real value" vs. "error indicating value") return values? Do you have encountered realworld problems or are you asking just in advance to avoid such problems in the future without having encountered them so far? > > > >> I got the impression that corresponding error checks can occasionally be missing. > >> How do you think about to detect such cases by advanced source code analysis? > > > > No need to thest these kind of problems, as long as you use the type > > system to help you as mentioned above. > > Can it still happen then to overlook desirable checking of provided data? If you encode the possible states of your return value as types, then you have the advantage that when you match on the type, that the compiler warns you about that (but if you ignore these warings, you can get a runtime error with a non-matched value). Also matching with the underscore can yield to unexpected results, if used carelessly (or to avoid the compiler warnings, instead of writing the correct match). But it often makes sense - just think about the cases. > > > > Since a while OCaml also offers a result-type, which you can use. > > Do any programming interfaces need still to work without this special data type? ? Don't understand your question. > > > > It might be better than the option type in more general cases. > > And if predefined types don't offer what you are looking for, > > just define your own type. > > Customised types can be constructed only for new programming interfaces. So write your own interface... > Would you like to offer any companion functions for safer API variants? ? Do you have questions on OCaml, or do you want us to write your code? Ciao, Oliver