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 >> > >