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

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

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

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

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

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

Спасибо,

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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