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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id DC52F7EEFA for ; Thu, 25 Jun 2015 09:55:32 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.13,675,1427752800"; d="scan'208";a="137749897" Received: from meleze.ens.fr (HELO [129.199.99.114]) ([129.199.99.114]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 25 Jun 2015 09:55:32 +0200 Message-ID: <558BB3F4.4050209@inria.fr> Date: Thu, 25 Jun 2015 09:55:32 +0200 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: caml-list@inria.fr References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Core Overlay Just an idea, maybe you can put 'open Core.Std' (I'm not sure that's anymore the correct way to use Core but ...) on top of each ml file of the project, then try to recompile it like that. I guess you will then have many compilation errors that will force you to fix code to use Core's version of everything. After that, very few non tail rec. functions should remain in the code base. On 06/24/2015 06:02 PM, Kenneth Adam Miller wrote: > I'm trying to upgrade a library that has a lot of existing code that > makes calls to List.map; the core overlay is really nice, and I'd like > to make use of a tail recursive implementation because that much is > pretty much imperative. > > I've refactored the code of the library to make sure that the compiler > identifies the list and the operation types being from Core.List, > recompiled, opam pinned the project. But I keep getting blowups. I've > executed the code in gdb, and gotten a backtrace with the stack overflow > and I can see that it's still going to List.map. > > So I'm thinking it has to be one of a few errors: > > I've fixed it, but it's linking against a different, older version of > the library. > * Problem with this is, the makefile generates ocamlfind calls, and > those resolve the package correctly. I've check the file dates, removed > the packages and readded them a multi-tude of times. Unless there's some > invisible /usr/local compiler selection over the opam stuff despite it > being specifically pointed there, I don't see how this could be. But I > could be wrong. > > I've fixed the library some, but it some how resolves to a Pervasives > type that's not tail recursive somewhere in the library that I missed. > * I still don't see how this could be. I'm looking in the gdb backtrace, > and I can see where it flows from my code into the library-the library. > I've tracked the naming convention down to the exact function definition > and checked via Emacs Merlin that it's the type it should be. > > > I've fixed the library correctly, but somehow a mismatch between > pervasives and Core definitions causes some fallback to the pervasives > via some kind of invisible typing rules or language specifics that I > don't know about. > * Maybe, but wouldn't the compiler complain if it expected a > Core.Std.List.t and got a list instead? -- Regards, Francois. "When in doubt, use more types"