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 8D4FC7FACB for ; Sat, 6 Sep 2014 23:57:34 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of martin.jambon@ens-lyon.org) identity=pra; client-ip=66.111.4.25; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible Received-SPF: Neutral (mail2-smtp-roc.national.inria.fr: domain of martin.jambon@ens-lyon.org does not assert whether or not 66.111.4.25 is permitted sender) identity=mailfrom; client-ip=66.111.4.25; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@out1-smtp.messagingengine.com) identity=helo; client-ip=66.111.4.25; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="postmaster@out1-smtp.messagingengine.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwBAPiCC1RCbwQZnGdsb2JhbABZhDeCfLRwmT8BgQAWEAEBAQEBBg0JCRQphAQBBSMPAQUIOAEBDwsYAgIFFgsCAgkDAgECAUUGDQEHAQGIPqZ8eIUIj3MBEQaBLI4hB4J5gVMBizmHDJFYGpFsTIJPAQEB X-IPAS-Result: AqwBAPiCC1RCbwQZnGdsb2JhbABZhDeCfLRwmT8BgQAWEAEBAQEBBg0JCRQphAQBBSMPAQUIOAEBDwsYAgIFFgsCAgkDAgECAUUGDQEHAQGIPqZ8eIUIj3MBEQaBLI4hB4J5gVMBizmHDJFYGpFsTIJPAQEB X-IronPort-AV: E=Sophos;i="5.04,479,1406584800"; d="scan'208";a="93341803" Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2014 23:57:13 +0200 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id 7D854208F7 for ; Sat, 6 Sep 2014 17:57:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Sat, 06 Sep 2014 17:57:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=EC9tcp3GYs2aIuipTOVRWO iUBgM=; b=hYFE9tEW8DUWxW13d3cAMIk5xyQnoWxcANLDKYsp5zoZn4FxfrH37B Vro4gDVM3ANELItLvUdQOiI69dD/4o6X6DpNOkI+0CZph+y/zm3gBRCWGAS26dD6 EoPA6sryKiWaPnTbGcklsHyuKkSShSogmAfQn9ulkE3Lpo0vuBMrQ= X-Sasl-enc: Bx7OB2L61nrTHYURb76uWQCDKQL5fS2hpmh2rsFildOo 1410040630 Received: from [192.168.2.7] (unknown [67.180.86.2]) by mail.messagingengine.com (Postfix) with ESMTPA id BEBCD680112; Sat, 6 Sep 2014 17:57:09 -0400 (EDT) Message-ID: <540B832F.7060407@ens-lyon.org> Date: Sat, 06 Sep 2014 14:57:03 -0700 From: Martin Jambon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?UTF-8?B?RGF2aWQgTUVOVFLDiQ==?= CC: caml-list@inria.fr References: <20140905215626.GB3416@annexia.org> <20140905221302.GE3099@annexia.org> <20140905221813.GC3416@annexia.org> <540A3B85.6010609@ens-lyon.org> <540AA0DB.1040202@ens-lyon.org> <540B5B9A.9040207@ens-lyon.org> <540B6F39.20608@linux-france.org> In-Reply-To: <540B6F39.20608@linux-france.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] segfault in simple program with 4.02 native On Sat 06 Sep 2014 01:31:53 PM PDT, David MENTRÉ wrote: > Hello Martin, > > [ Disclaimer: I know nothing about atdgen. ] > > 2014-09-06 21:08, Martin Jambon: >> I must say there's a strange feeling about creating more type >> definitions while breaking the type system. > > Apparently, such tricks are used for speed reasons. Why not provide > two ways to generate code: one safe using only regular OCaml and one > using Obj tricks. That way, your users could check in case they have > an issue and fall-back to safer code until a proper fix is found. > > Nonetheless, I still do think that having correct code is more > important that having fast one, whatever is the speed ratio between > the two. I like the idea. I'm a bit concerned about maintainability and continuous testing, though, since this would effectively split the user base between those using the safe option and those using the fast option.