Re: [Caml-list] Core Overlay

[Yaron Minsky <yminsky@janestreet.com>]

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
<kennethadammiller@gmail.com> 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 <bmillwood@janestreet.com>
> 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 <francois.berenger@inria.fr>
>> 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
>>
>>
>