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 CDAAF7FACB for ; Sat, 6 Sep 2014 22:32:13 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of dmentre@linux-france.org) identity=pra; client-ip=94.23.39.64; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dmentre@linux-france.org"; x-sender="dmentre@linux-france.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of dmentre@linux-france.org) identity=mailfrom; client-ip=94.23.39.64; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dmentre@linux-france.org"; x-sender="dmentre@linux-france.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@tempura.bentobako.org) identity=helo; client-ip=94.23.39.64; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dmentre@linux-france.org"; x-sender="postmaster@tempura.bentobako.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFANJuC1ReFydA/2dsb2JhbABZgw2EJssLgx8BgQAWd4QEAQUjFVELGgIFIQICDwIOOBMIAQGIQqgRlHwBF4EsjigWgmOBUwEEkUOScI1rg2ODOQEBAQ X-IPAS-Result: AgsFANJuC1ReFydA/2dsb2JhbABZgw2EJssLgx8BgQAWd4QEAQUjFVELGgIFIQICDwIOOBMIAQGIQqgRlHwBF4EsjigWgmOBUwEEkUOScI1rg2ODOQEBAQ X-IronPort-AV: E=Sophos;i="5.04,479,1406584800"; d="scan'208";a="93337764" Received: from tempura.bentobako.org ([94.23.39.64]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 06 Sep 2014 22:31:54 +0200 Received: from [192.168.0.18] (85-171-113-17.rev.numericable.fr [85.171.113.17]) by tempura.bentobako.org (Postfix) with ESMTPSA id 9E0511699 for ; Sat, 6 Sep 2014 22:31:53 +0200 (CEST) Message-ID: <540B6F39.20608@linux-france.org> Date: Sat, 06 Sep 2014 22:31:53 +0200 From: =?UTF-8?B?RGF2aWQgTUVOVFLDiQ==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: 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> In-Reply-To: <540B5B9A.9040207@ens-lyon.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] segfault in simple program with 4.02 native 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. Best regards, david