This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Here we are:
> > > > I would like Guile to have decent support for numeric computation.
> > > > Most likely this means giving Guile good tools for communicating with
> > > > numeric code written in other languages, as RnRS Scheme is inherently
> > > > unsuitable for numeric work (too much polymorphism).
> > >
> > > While this is generally true, a smart compiler that does some type
> > > inference can do very well. I believe Stalin is the canonical example.
> > > It supposedly generates better code than good FORTRAN implementations
> > > from some problems, out of Scheme code written in a natural style.
> >
> > Are you *sure* you're talking about stock Scheme code, without special
> > declarations? If so, then I really want to see that paper. With
> > declarations, anything is possible.
>
> Yes, it's with stock scheme code & without declarations. Stalin does
> a lot of heavy duty optimizations, especially type inference. I don't
> know if there're associated papers, but there's a compiler. [...]
Notice that I was specifically talking about numeric computation,
which is a harder problem than type inference, because Scheme's
numeric operators convert so freely between representations.
Stalin's README seems to say that it only supports fixnums and
flonums. So, because Stalin implements such a limited section of the
Scheme numeric tower, the inexact/exact distinction I mentioned
before completely determines which numeric representation to use for a
given value.
I can't run Stalin on my UltraSPARC (64Mb) or my Linux box (32Mb),
because it runs out of memory compiling this program:
(define (fact n)
(if (<= n 1) 1
(* n (fact (- n 1)))))
(write (fact (read)))
(newline)
... so I can't actually say what code it generates, but I'll bet it
doesn't do anything particularly spectacular with this code. I'll bet
it does exactly what every other Scheme compiler with a type
inferencer does.
Don't get me wrong --- it sounds really cool, as if someone had
finally put together all the right optimizations in one package. My
point is that there's no magic going on here, and that the real
problem --- efficient compilation to a run-time that uses the full
numeric tower --- is still an unsolved problem, and for good reason.