Custom Query

Reported by JohnD, 3 years ago.

Traditionally, a build system consists of shell scripts and make files. I want to replace the shell scripts and make files with Haskell source code. To do this a Haskell function library that provides the same sort of functionality that shell scripts and make files already provide will be needed.

Since all Haskell computer programmers are familiar with Haskell I do not see how the transition would pose a problem provided that Haskell source code is capable of being competitive with shell scripts. I believe it can be. The goal is to make the build process fast and robust.

I hope to gut the present build system and replace it with something entirely new. The change will be global and will effect everyone. What I intend to do will be innovative. It will be an octopus of sorts in that it is going to effect everything.

Reported by LouisWasserman, 4 years ago.

Data.Sequence is meant as a general-purpose implementation of finite sequences. The range of methods it offers, however, is considerably more constrained than Data.List, even allowing for the constraint that sequences are finite.

The following methods cannot be efficiently implemented based on currently exported methods from Data.Sequence.

• zipWith and its variants. Note: it suffices to define zipWith alone.
• replicate. (This can be implemented in O(log n) time with node sharing.)

The following methods are relatively simple extensions of already-exported methods. It may be more appropriate to allow library users to reimplement them themselves.

• scanl, scanr, and variants. This is relatively straightforward using methods borrowed from the Traversable instance.
• tails and inits. tails is equivalent to scanr (<|) empty; inits is similar.
• takeWhile, dropWhile, span, break (and perhaps from-the-end variations). Finding a breakpoint index can be done as efficiently on lists as on sequences; find the appropriate breakpoint index after converting to a list and use splitAt.
• unfoldr and iterate, though the latter would require a finite number of iterations to perform.
• partition. I can conceive of a slightly more efficient implementation than the trivial one, but the gains may be minimal.