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 79FDD7EF28 for ; Fri, 26 Jun 2015 18:57:31 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.112 as permitted sender) identity=mailfrom; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYAQB+g41VnHDIaSZbg2VfBoMYqw2QaoV4AoE1B0wBAQEBAQESAQEBAQEGFglPhCMBAQQSER0BASwLAQ8LCw0CAgkdAgIhARIBBQEKEgYTEhCHeAMSAwqsUj4xik9whGQBBYtNAwqFdAEBAQEBAQEBAQEBAQEBAQEBARQGCoEXiimCTYI5B4JogUOFXwqOIIRYhRmBYYE6Qo8jgz2CERIjgRUXhCVTgkgBAQE X-IPAS-Result: A0BYAQB+g41VnHDIaSZbg2VfBoMYqw2QaoV4AoE1B0wBAQEBAQESAQEBAQEGFglPhCMBAQQSER0BASwLAQ8LCw0CAgkdAgIhARIBBQEKEgYTEhCHeAMSAwqsUj4xik9whGQBBYtNAwqFdAEBAQEBAQEBAQEBAQEBAQEBARQGCoEXiimCTYI5B4JogUOFXwqOIIRYhRmBYYE6Qo8jgz2CERIjgRUXhCVTgkgBAQE X-IronPort-AV: E=Sophos;i="5.13,686,1427752800"; d="scan'208";a="138007032" Received: from mxout1.mail.janestreet.com ([38.105.200.112]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 26 Jun 2015 18:57:29 +0200 Received: from tot-qpr-mailcore2.delacy.com ([172.27.56.106] helo=tot-qpr-mailcore2) by mxout1.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Z8WwN-0004xQ-0C for caml-list@inria.fr; Fri, 26 Jun 2015 12:57:23 -0400 X-JS-Flow: external Received: by tot-qpr-mailcore2 with JS-mailcore (0.1) (envelope-from ) id BVjYRy-AAAH1G-d1; 2015-06-26 12:57:22.955283-04:00 Received: from mail-wi0-f175.google.com ([209.85.212.175]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1Z8WwM-00007R-Np for caml-list@inria.fr; Fri, 26 Jun 2015 12:57:22 -0400 Received: by wicnd19 with SMTP id nd19so50211325wic.1 for ; Fri, 26 Jun 2015 09:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=svthO57FSRrwV4AF7Gj9NXalqoGEUzHWbSihjAExkTE=; b=UpU+rS78VcZBLlCkvOHgSTLvZjypKjK4Eql3nkV+2CcywEk2tysTnhZaBpmGF4bXLC J6N2RGF0+tJNlzqejDLgRT+z4IaxFJfS9UPj4tZJeTSGi7DCiRKo8zxn3h9kdaL5NZv7 +EcWYY6JB+O4HRT38qu9eVfUXXERIUab1bXb4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=svthO57FSRrwV4AF7Gj9NXalqoGEUzHWbSihjAExkTE=; b=OBOPcvBCdWyXB7Ij3r/BOh7g5aCfJS0POx8qsG0bc+BpdM/OlYl90UoBPFquZ3wyS9 PsA76psNfEbT41nWahqG46ng+lYKHgQK+OG6HFDKEhIB+OrrVY/PBE0tbDKpUsIGW7bb PqdHcYReQByPZZ8KGFJft7jXaXF8/YpRM2dxvdk1gle0F1YnYjRYOcWcacf7LY1ExjZR VoDhtW9E0fC3lYAgaNXEThINa25fyS8MbO2woBerXIEnhXZzfi1ipne+3wyJF4enX+ZC xks5Yvc7n/jqmvctwqbeHMTGxpsWA5oWovFnffTDNWLJ4qN964BHSa/8laHGK6rG253h FcbQ== X-Gm-Message-State: ALoCoQml1TuN//AJq9g20u+KI0TPrjJ3iFovoE4n1F178d+CXpXYHd3twctNiQ8LUzJ1mkWMMEDgfz+qFB1zcWbzxhwgat79P5eO3KTDCAshFoGPzWe2Zhino5yxLB2P+Zdan3xYv/Yj X-Received: by 10.194.187.170 with SMTP id ft10mr4605110wjc.26.1435337842021; Fri, 26 Jun 2015 09:57:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.187.170 with SMTP id ft10mr4605101wjc.26.1435337841902; Fri, 26 Jun 2015 09:57:21 -0700 (PDT) Received: by 10.28.153.20 with HTTP; Fri, 26 Jun 2015 09:57:21 -0700 (PDT) In-Reply-To: References: <558BB3F4.4050209@inria.fr> Date: Fri, 26 Jun 2015 12:57:21 -0400 Message-ID: From:Yaron Minsky To:Kenneth Adam Miller Cc:Ben Millwood , Francois Berenger , caml users Content-Type: text/plain; charset=UTF-8 X-JS-Processed-by: mailcore Subject: Re: [Caml-list] Core Overlay If you compile with -short-paths, OCaml will start reporting all your list types as 'a list, rather than Core.Std.List.t. y On Fri, Jun 26, 2015 at 9:09 AM, Kenneth Adam Miller wrote: > I was reading compiler output and seeing that at times it would say things > like xyz Core.Std.list = xyz list; I thought that was likely the case, and > instances seemed interchangeable to the functions they get called on. But I > wondered if there were some catch, as in the Core.Std.List type actually > extends the pervasives list, or some subtlety that I missed. Thanks for that > tidbit of information :) > > I got the rest of it refactored, and the core related stuff compiles. Now > I'm just dealing with module interdependency issues. > > On Fri, Jun 26, 2015 at 2:34 AM, Ben Millwood > wrote: >> >> Core does not have its own list type, only its own list functions. ['a >> Core.Std.List.t] is equal to ['a list], and the compiler only tells you one >> or the other based on its heuristics for what would be most useful for you >> to hear (which can't be right every time). >> >> Opening Core.Std at the beginning of your program is still the recommended >> way to use Core, but you can also do something less invasive like just using >> Core.Std.List.map directly. You may also find it useful that Core's List.map >> takes a named argument ~f, whereas the standard List.map can't do that >> (although ListLabels.map can). >> >> On 25 June 2015 at 08:55, Francois Berenger >> wrote: >>> >>> 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" >>> >>> -- >>> Caml-list mailing list. Subscription management and archives: >>> https://sympa.inria.fr/sympa/arc/caml-list >>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>> Bug reports: http://caml.inria.fr/bin/caml-bugs >> >> >