darcs patch: Fix the GHC.Base.inline builtin rule
brian at brianweb.net
Fri Apr 27 16:45:17 EDT 2007
On Mon, Apr 23, 2007 at 08:07:07AM +0100, Simon Peyton-Jones wrote:
> How are you using 'inline'?
I was trying to get the various unpackCString# rules to work with
strings with non-ascii characters (the desugarer turns them into
unpackCStringUtf8# which doesn't have the foldr/build rules). I wanted
to do something like:
unpackFoldrCString = ... normal foldr with utf8 decoder ...
unpackCString addr = inline (unpackFoldrCString addr (:) )
unpackCStringAppend addr rest = inline (unpackFoldrCString addr (:) rest)
and get the compiler to write the utf8 decoder 3 times for me.
This almost worked except I couldn't get the interaction between the
inline rule and the unpack rules right. I kept winding up with
unpackCString addr = unpackCString addr (because of the
unpackFoldrCString# addr (:)  = unpackCString# rule). I eventually
settled on a simpler way of doing it not involving inline.
> Do you have an example that exposes whether it works? We'd like to
> add a regression test.
I though about writing a test case but couldn't come up with anything
that would actually break if it didn't work. I suppose you might be
able to come up with some kind of rewrite rule that would only fire if
the right two pieces of code same together, which would only happen if
inline worked. Seems like that would depend on too many other parts of
the compiler working right to be a good test case though.
> hunk ./compiler/prelude/PrelRules.lhs 517
> -match_inline (e:_)
> +match_inline [Type _,e]|
> There can be extra arguments. Consider
> inline f_ty f a b c
Ah. I was assuming (but didn't actually check) the simplifier would
only ever pass the number of args specified in the rule arity to the
rule function. Thanks for the clarificataion.
More information about the Cvs-ghc