patch applied (packages/regex-base):Make setupscriptcompileagain after recent Cabal changes

[Claus Reinke]

> You have to understand that the above command does two things: it compiles 
> Y.hs to Y.o, and then it links Y.o with libraries to form a binary.  In the 
> first stage, all exposed packages are available (because you didn't say 
> -hide-all-packages), so Data.Time from package time is in scope and you can 
> successfully import it.  At link time, all you have to do is make sure the 
> required packages are linked in, and you did that by explicitly linking 
> something (P) that depends on package time, so package time was linked in too.
> 
> I don't think there's anything really "wrong" here, that's just the way it 
> works when you don't use --make.

ah, thanks! somehow, i had been living under the misconception that,
to get at any non-base package's modules, i would have to use either 
--make or -package. as if -hide-all-packages -package base was the
default, in other words. instead, the distinction is exposed vs hidden, 
which makes sense. (*)

which means that my test setup was useless, other than supporting
link-time dependency recording. package dependencies are another
matter, since for building packages -hide-all-packages is the default,
and my setup did not, after all, re-export modules as intended.

one might still re-export modules under their original names, by 
using two packages. for the time example: a package P can depend
on base and time, importing Data.Time, exposing P.Data.Time; then,
a package Q can depend on base and P, importing P.Data.Time,
exposing Data.Time. with this alternate setup, 

    ghc -hide-all-packages -package base -package Q Y.hs

succeeds (this time hopefully for the right reasons?-).

if i recall correctly, the grafting/mounting/package-qualifier proposals
were attempting to formalise this linking of package modules into a
module hierarchy, in various ways. perhaps providing package 
qualifiers (with a way to disambiguate between package and module 
names) could be reconsidered, given that mounting of package 
modules in the hierarchy may then be achieved via intermediate 
packages like Q above?

(*) still, i find this two-things separation confusing, because the compiler
only "half-knows" about things (being able to compile without complaint, 
then fail in linking with confusing errors), and because -package serves 
two separate purposes (exposing packages, and enabling linking). i'd
rather keep the illusion that link objects are an internal representation
of source modules, and either both compile and link succeed, or both
fail, with a source-level error message.

claus