[GHC] #9832: Get rid of PERL dependency of `ghc-split`

[GHC]

#9832: Get rid of PERL dependency of `ghc-split`
-------------------------------------+-------------------------------------
        Reporter:  hvr               |                   Owner:  Phyx-
            Type:  task              |                  Status:  new
        Priority:  high              |               Milestone:  7.12.1
       Component:  Driver            |                 Version:
      Resolution:                    |                Keywords:  perl
Operating System:  Windows           |            Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by Phyx-):

 I'm not quite sure the problem being solved here is either, but I don't
 think it's binary size. since the perl distribution (looking at GHC
 7.10.1) comes down to a `perl.exe` and a `perl56.dll` which together with
 the perl `GHC-split` file comes to a smaller since than the Haskell `GHC-
 split`.

 My assumption has been that the problem being addressed is to lower the
 amount of "other" languages used by the compiler/tools.

 The actual implementation isn't that big, what ended up being big is the
 fact that I needed to use a perl regular expression library unless I
 rewrite it to using something else, like parsec maybe...

 Two things could be done:

 First I could instead of having the `pcre` source inlined I could depend
 on the availability of `libpcre` being available on the build platform.
 This would remove the 30,000 lines of C but introduce an extra dependency.

 Secondly I can strip the `pcre` Haskell bindings down to the bare
 essentials that I actually use. This would be a very small subset of the
 current code. But would also mean that if you want to extend this and need
 any features I didn't need before from the lib the code would have to be
 re-introduced.

 Also when doing this I found a few lines of dead code and functions that I
 could never get the compiler to generate code to enter. Which makes me
 wonder if those parts are still needed to begin with.

 But in general, I agree, this may be more trouble then it's worth.
 Especially if the original goal was to reduce binary size.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9832#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler