Смешивание OCaml и C: стоит ли боли?

Question

Передо мной стоит задача создания нового компонента для интеграции в большую существующую кодовую базу языка C.Компонент, по сути, является своего рода компилятором, и он будет достаточно сложным, чтобы я хотел написать его в OCaml (по причинам, аналогичным приведенным здесь ).Я знаю, что взаимодействие с OCaml-C возможно (согласно руководству и этому учебнику ), но оно выглядит несколько болезненным.

Что я хотел бы знатьпытались ли другие здесь предпринять крупномасштабную интеграцию кода OCaml и C, каковы были некоторые неожиданные ошибки, которые они нашли, и решили ли они в конце дня, что им было бы лучше просто написать новый код на C.

Заметьте, я не пытаюсь начать дискуссию о преимуществах функционального и императивного программирования: скажем так, мы предполагаем, что OCaml оказался подходящим инструментом для работы.иметь в виду, и потенциальная трудность в интеграции является единственной проблемой.У меня также нет возможности переписать оставшуюся часть кода.

Чтобы немного подробнее рассказать о задаче: компонент, который мне нужно реализовать, представляет собой определенный вид оптимизатора запросов, который включает в себя некоторые исследовательские идеи.Моя группа в Калифорнийском университете в Дэвисе работает и будет интегрирована в PostgreSQL, чтобы мы могли проводить эксперименты.(Оптимизатор запросов - это, по сути, компилятор.) Компонент будет вызываться из кода C, функционировать в основном независимо, но будет выполнять определенное количество вызовов других компонентов PostgreSQL для извлечения таких вещей, как информация системного каталога, и будет создавать сложныйСтруктура данных C (представляющая физический план запросов) в качестве выходных данных.

Извиняюсь за несколько открытый вопрос, но я надеюсь, что сообщество сможет избавить меня от небольшой проблемы:)

Спасибо,

TJ

Answer 1

Отличный вопрос. Вы должны использовать лучший инструмент для работы.

Если на самом деле ваши намерения состоят в том, чтобы использовать лучший инструмент для работы (и вы уверены, что lexx и yacc будут проблемой), тогда у меня есть чем поделиться с вами; вообще не больно звонить в ocaml из c, и наоборот. Большую часть времени я писал ocaml для вызова C, но несколько написал иначе. В основном это были функции отладки, которые не возвращают результат. Хотя обратные и четвертые призывы действительно касаются упаковки и распаковки типа ocaml value на стороне C. Этот урок, который вы упоминаете, охватывает все это, и очень хорошо.

Я против высказываний Рона Сэвиджа о том, что вы должны быть знатоком языка. Я помню, как начинал с того места, где я работаю, и в течение нескольких месяцев, не зная, что такое «функтор», был в состоянии вызвать C и написал тысячу строк C для числовых рецептов и абстрактных типов данных, и произошли некоторые ошибки. (не с распаковкой типов, а с сборкой мусора абстрактных типов данных), но это было совсем не плохо. Большая часть внутренних циклов в проекте написана на языке C с использованием SSE, внешних библиотек (lapack), более узких оптимизированных циклов и некоторых встроенных сборок, оптимизированных вручную.

Я думаю, что вам может потребоваться опыт разработки большого проекта и разграничения функциональных и обязательных разделов. Я бы действительно оценил, сколько ocaml вы будете писать, и какие значения вы хотите передать C - я говорю это, потому что я бы боялся рекомендовать кому-то передать рекурсивную структуру данных из ocaml to C, на самом деле, было бы много распаковок кортежей, их содержимого и, следовательно, много возможностей для путаницы и ошибок.

Answer 2

Взаимодействие - это ахиллесова пята автономных реализаций статически типизированных языков, особенно тех, у которых нет JIT-компиляции, такой как OCaml.Мой собственный опыт использования OCaml более 5 лет заключается в том, что единственные надежные привязки - это простые API-интерфейсы, которые выполняют немногим больше, чем передают большие массивы, например, LAPACK.Даже несколько более сложные привязки, такие как FFTW, заняли годы, чтобы стабилизироваться, а другие, такие как OpenGL и GLU, остаются нерешенной проблемой.В частности, я обнаружил серьезные ошибки в коде связывания, написанном двумя авторами компилятора OCaml.Если они не могут сделать это правильно, то у нас мало надежды ...

Однако, еще не все потеряно.Решение состоит в том, чтобы просто использовать более слабые привязки.Вместо того, чтобы обрабатывать совместимость на уровне C с низкоуровневым небезопасным интерфейсом, используйте высокоуровневый интерфейс, такой как XML-RPC, с передачей строк или даже через сокеты.Это гораздо проще сделать правильно и, как вы говорите, позволит вам использовать огромные практические преимущества, предлагаемые OCaml для этого приложения.

Answer 3

Я написал довольно сложную гибридную программу OCaml-C. Я был разочарован тем, что я нашел неадекватной документацией, и я потратил слишком много времени на решение проблем сбора мусора. Тем не менее, результирующая программа работала и была быстрой.

Я думаю, что есть место для интеграции OCaml-C, но убедитесь, что оно того стоит. Может быть проще, чтобы программы взаимодействовали через сокет (при условии, что такие операции ввода-вывода не снизят желаемую производительность). Также было бы более разумно просто написать все это на языке C.

Answer 4

Мое эмпирическое правило - придерживаться языка / модели / стиля, используемых в существующей кодовой базе, чтобы будущие разработчики обслуживания унаследовали согласованный и понятный набор кода приложения.

Единственный способ, которым яможет оправдать что-то похожее на то, что вы предлагаете, если бы:

1. Вы являетесь экспертом в OCaml и новичком в C (так что вы будете в 20 раз продуктивнее)
2. У вас естьуспешно интегрировал его с библиотекой C раньше (по-видимому, нет)

Если вы знакомы с C больше, чем с OCaml, вы просто потеряли любой «теоретический» выигрыш от OCaml, который проще использовать, когданаписание компилятора - плюс, кажется, хотя вокруг вас будет больше знакомых с C, чем OCaml.

Это мой «сварливый старый кодер» 2 цента (который раньше стоил всего лишь копейки!).