Optimisation of unpackCString#

[Don Stewart]

ndmitchell:
> Hi
> 
> > what is general purpose stuff.  I don't think there is anything wrong with magic for primitive
> > types, but if there is a useful general-purpose mechanism trying to get out, let's liberate it.
> 
> I think the tension comes from representing String's as CString's, not
> actual lists of Char and (:). If the simple representation was used,
> then things like case on a known constructor would deal with a lot of
> these cases. However, for String, its probably too expensive in terms
> of compile time and compile memory to keep the unpacked
> representation.
> 
> > But I'd like a clear spec first.
> 
> PROPOSAL 1: Add the following rules to the simplifier:
> 
> > case unpackCString# "" of  ==> case [] of
> > case unpackCString# "xyz" of ==> case (C# 'x': unpackCString# "yz") of
> 
> Pros: Doesn't introduce any new API or other long-term maintenance
> issues. A necessity for certain optimisations.
> 
> Cons: Makes the simplifier slightly more complex - but I hope not by much!

And it doesn't work for my case -- I'd really want length as a compile
time constant.

Could you elaborate on what kind of rules you think we could write with
the ability to get the head?

> PROPOSAL 2: Add some primitives and hard-coded simplifications:
> 
> (I'm giving an example with length#, but I imagine head#, tail#, null#
> and some others would also be handy)
> 
> Add the following in GHC.<somewhere>
> 
> length# :: CString -> Int
> {-# RULE "length/string" forall xs . length (unpackCString xs) = length# xs #-}

xs :: Addr# here actually. 

The rule I'd like to write is:

    "pack/packAddress" pack (unpackCString addr) = ByteString (length# xs) 0 addr

> 
> Add the rules to the simplifier:
> 
> length# "string" = <the result>
> 
> Pros: length "haskell" becomes a compile-time constant. Very useful
> for the ByteString people. Makes RULES and CString interact better,
> with better optimisation possibilities.
> 
> Cons: Requires defining a small API and maintaining it. Requires more
> work to the simplifier, but still should be fairly self-contained.
> Cries out for a generalisation (but I don't think there is a good
> one).
> 
> SUMMARY:
> 
> I think Proposal 1 is a really good idea, with a little effort and a
> lot of return. I think Proposal 2 is more effort than proposal 1, with
> probably less return - but may still be worth it. I think Don will
> really want Proposal 2.
> 
> Thanks
> 
> Neil