From: Kenneth Adam Miller <kennethadammiller@gmail.com>
To: caml users <caml-list@inria.fr>
Subject: [Caml-list] Core Overlay
Date: Wed, 24 Jun 2015 12:02:44 -0400 [thread overview]
Message-ID: <CAK7rcp9N=cWu1=QBoke+aykZrf6-j_WEYMJ0Wb8Fw21POxpicg@mail.gmail.com> (raw)
[-- 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 --]
next reply other threads:[~2015-06-24 16:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-24 16:02 Kenneth Adam Miller [this message]
2015-06-25 7:55 ` Francois Berenger
2015-06-26 6:34 ` Ben Millwood
2015-06-26 13:09 ` Kenneth Adam Miller
2015-06-26 16:57 ` Yaron Minsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK7rcp9N=cWu1=QBoke+aykZrf6-j_WEYMJ0Wb8Fw21POxpicg@mail.gmail.com' \
--to=kennethadammiller@gmail.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox