[Caml-list] Core Overlay

[Caml-list] Core Overlay

[Kenneth Adam Miller]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 2082 bytes --]

Re: [Caml-list] Core Overlay

[Francois Berenger]

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"

Re: [Caml-list] Core Overlay

[Ben Millwood]

[-- Attachment #1: Type: text/plain, Size: 3359 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4446 bytes --]

Re: [Caml-list] Core Overlay

[Kenneth Adam Miller]

[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5393 bytes --]

Re: [Caml-list] Core Overlay

[Yaron Minsky]

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