[Haskell-cafe] Minimizing cascading rebuilds

[Theodore Lief Gannon]

(sorry for duplicate, failed to reply to list)

Haskell is going to be unwieldy if you try to code in a non-functional
style! Your data, however static, should be passed as an argument to
functions that need it. In this case, "as an argument" should probably be
read as "with the Reader monad."

If you want to avoid loading via IO, you can still put your data set in a
separate package. It will depend on packageA to define the data type, but
nothing but your final executable has to depend on it -- in fact, it can
probably live in the executable's source tree. Put all of your logic that
depends on that data (directly or indirectly) in a Reader, and invoke it at
the top level.

Once you've got that down, it's very much worth reading up on transformers
and mtl. I'd also suggest looking at the Rio[1] prelude (currently not
quite to a stable release, but will be inside the month) which is built
around encouraging current best practices. Once you know the tools, this
style becomes convenient, extremely versatile, and helps avoid unnecessary
dependencies all over the place.

[1] https://github.com/commercialhaskell/rio

On Wed, Mar 28, 2018, 10:11 PM ☂Josh Chia (謝任中) <joshchia at gmail.com> wrote:

> Hi,
>
> In my project, I have multiple packages. One of the packages, packageA, is
> very fundamental and depended on directly and indirectly by almost all the
> other packages. It has functions that use some hard-coded data (a
> ByteString top-level variable) also defined within packageA.
>
> This hard-coded data is appended regularly, causing packageA to be rebuilt
> and thus almost all the other packages to be rebuilt, and building takes a
> painfully long time. I know I can move this hard-coded data to a file
> that's read at run-time, but that means one more item to plumb in at
> run-time (where to find the file), and IO (preventing the functions from
> being pure), so I would like to keep it hard-coded.
>
> Is there an elegant way to prevent or minimize the cascading rebuild of
> the dependent packages just because the hard-coded data in packageA changed?
>
> For analogy, in C or C++, source code gets compiled to .o files, one for
> each .cpp source file. Multiple .o files get linked into executables. So,
> unless the interface (.hpp files) also change, an implementation (.cpp
> file) change does not cause dependents to be recompiled to get new .o
> files, although dependent executables get relinked. I'm not familiar with
> the compilation and linking logic in GHC so maybe it has additional
> complications.
>
> BTW, I'm using stack, in case it makes any difference to the nature of the
> problem.
>
> Josh
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180329/1a7c6ef0/attachment.html>