Am Sonntag, 8. Januar 2006 15:45 schrieben Sie:
> Daniel Fischer wrote:
> > Cool. So let's see if I got it.
> > If I have
> >
> > n <- readIO
> > ...
> > mapM_ (func n) list
> > ...
> >
> > in my programme, the runtime system will/might build object code for
> > func n that is then used instead of using the general code for func and
> > supplying both arguments to that?
> >
> > That'd be wow, triple wow!
> > And run-time compilation is a fitting name for that.
>> Well, it's possible to do that. But I don't know of any Haskell
> implementation that does. Sure, you might get a little bit of
> that if func is defined suitably, like
> func 0 = foo
> func 1 = bar
> func n = baz
> Implementations that have the "full laziness" property will handle
> one argument at a time to a function, and may do some work with just
> one argument to func. But it's nothing like having real run-time code
> generation.
>> -- Lennart
So back to square one.
What then _is_ run-time compilation?
Bulat said that in
n <- readIO
flip mapM [1 .. 100] $ \x -> print (x^n)
the programme could insert (if, e.g. the value read is 2) the concrete faster
algorithm for x^n. Isn't that some sort of run-time code generation?
And a) how far might one expect that sort of thing done,
b) how could one cajole the system to do that.
Last, reverting to the search/replace example, if I have the general algorithm
and also declare the function
work :: String -> String
work = searchReplace "pattern" "substitution",
the compiler would produce specialised object code for that, or wouldn't it?
Cheers,
Daniel