Как проще всего разбить большой файл на Haskell с большим количеством импорта (многие из которых соответствуют требованиям) на файлы меньшего размера? - PullRequest
0 голосов
/ 01 декабря 2018

У меня есть большой файл на Haskell (около 3000 строк) со многими импортами (около 150).Я пытаюсь разбить его на более мелкие файлы, чтобы, среди прочего, улучшить параллелизм сборки и, следовательно, сократить время сборки.

  1. Самый простой и наивный способ сделать это может бытьдублировать весь заголовок импорта среди всех новых разбитых файлов.Все бы работало, за исключением того, что было бы много повторений в этих (возможно, 5-10) новых файлах, и нагрузка на обслуживание значительно ухудшилась бы, т.е. когда нужно было изменить один из импортов, это происходит сейчасв 10 местах вместо одного.

  2. Более сложный вариант - создать файл CommonImports.hs, в который я импортирую все необходимое, а затем повторно экспортировать ala module CommonImports (module X) where import Foo as X.Это будет работать по большей части, за исключением того, что существует около 50 импортных товаров, которые квалифицированы.Насколько я знаю, в настоящее время нет способа реэкспортировать / реимпортировать, сохранив первоначальные квалификации.Это можно сделать с помощью большого количества рефакторинга, где я удаляю все квалификации и разрешаю любые конфликты имен.

  3. Существует 3-й вариант: использовать функцию препроцессора C #include.Я уже использовал это раньше, и это работает, даже сохраняя квалифицированный импорт как есть.Но есть некоторые неудачные замечания: ghci и, следовательно, ghcid не замечают, когда изменяется файл #include d.Я попытался преодолеть это с небольшой помощью TH:

    import qualified  Language.Haskell.TH.Syntax as TH
    
    #include "./relative/../path/to/File.cpp.hs"
    $(TH.addDependentFile "/absolute/path/to/File.cpp.hs" >> pure [])
    

    Безрезультатно.Оказывается, это отсутствующая функция в GHCi: https://ghc.haskell.org/trac/ghc/ticket/4900#comment:81

    GHCid занимает центральное место в моем рабочем процессе, поэтому это прискорбно.

Я пропустил какие-либо другие подходычто некоторые из вас могут использовать?Может быть, те, которые имеют меньшие недостатки или различные компромиссы?

1 Ответ

0 голосов
/ 01 декабря 2018

Некоторые идеи, как мы могли бы справиться с такими ситуациями, как это:

  1. Может быть, пойти с опцией CPP.Перезагрузка не сработает, и это может привести к разочарованию и путанице в будущем, но, похоже, это лучший доступный для нас вариант, который мы на самом деле можем использовать в настоящее время.Отсутствие повторения и дублирования 150 нечетных строк в 10 файлах, меньшая нагрузка на обслуживание.GHCi (d) можно перезапустить вручную, что, как мы надеемся, приведет к изменению файла #include.Придирчиво, но, возможно, это также работает, чтобы вручную запомнить touch файл импорта после изменения файла #include d.

  2. Может быть Нетрудно объединить патч в выпуске # 4900если у нас все в порядке, поддержка hs-boot отсутствует.Я полностью согласен с этим, так как это выглядит как строго аддитивное улучшение, не отказываясь ни от чего.

  3. Одним из возможных долгосрочных решений этой проблемы будет поддержка GHC импорта уже квалифицированных материалови, возможно, поддерживая переквалификацию.Например, Foo.hs импортирует квалифицированную продукцию, а затем реэкспортирует Bar.func1.Когда я import Foo, у меня есть Bar.func1 в наличии.Если бы я import qualified Foo as F, тогда я мог бы иметь F.Bar.func1 в наличии.Может быть интересно выдвинуть это как предложение GHC.Эта особенность может сделать вариант № 2 в вопросе явно лучшим, изначально поддерживаемым выбором.

Любые другие идеи?

...