On Mon, 2006-12-18 at 10:33 -0800, Erick Tryzelaar wrote:
> skaller wrote:
> > A parser should be fun to write .. and quite easy using the GLR parsing
> > feature .. although lisp is rather trivial to parse .. and I guess
> > you would probably use lisp to parse lisp .. :)
> >
>
> Hmm, that would be interesting :)
Well Lisp usually does parse Lisp .. since Lisp is fairly brain
damaged it needs Lisp to be a simple language .. which it is :)
> parse=0.008257
> desugar=0.027707
Above two use *.par files as caches .. so tend to be fast.
> build=0.053617
> bind=0.710162
That's lookup phase .. uses 60-70% of compile time.
> opt=0.426281
That's heavier than normal. The optimiser is grossly inefficient,
but it never seems to matter.
Note that MLton whole program analyser takes about 40 hours ..
on a FAST machine .. to compile MLton. So I think Felix is still OK :)
> Oddly enough, it's gcc.
This is not odd. Gcc is a dog. What do you expect from an Open
Source project? Optimisation is particularly slow.
However gcc 4.x does produce half way reasonable code.
It does do data flow analysis now, which is more than
Felix does. However some of the optimisations are quadratic.
This would affect large routines .. Felix can make large
main routines.
I guess one could try to use gcc without optimisation,
or with just -O1 instead of -O2, that might speed up
building test codes .. this should work with the
bash script I think (but have a look).
> I wonder if there's anything that can be done to reduce / precompile.
For gcc? Yes probably if you have 4.x with precompiled header support,
it may help to load the C++ standard library precompiled .. assuming
that isn't done by default.
> Heh, well, because I was cheating. I put a "print" in the code and it
> never got ran. There any way to detect if a function has side effects,
> and print out a warning/error if it does? I can see how this would be
> basically impossible, but we could at least check if any procs are
> getting called.
It is possible to catch some cases, but that would defeat your cheats :)
You could try using a generator, but that still will NOT work if the
result is unused.. you would have to use ignore():
ignore(f()));
Ignore is a C proc which does nothing but the compiler is too
dumb to know that so the argument is always evaluated.
> Yeah, compiler bugs. Some day I'll see if I can put together a way of
> identifying errors like msvc does it. It's way handy to find google for
> it. That might be enough framework to make it easy to insert more error
> handling code.
It is also mandatory to have a tabulated catalog for localisation.
(EG French or Chinese error messages).
>
> Oh and one last one: the #import / #include of interdependent code.
> There any way that we could implicitly put in import guards?
It used to have them. The problem was it didn't work right.
> Then we can
> use the same loading mechanism, but the compiler will do the guarding
> for us. Would there ever be a reason to import a file multiple times?
Yes. Felix has scoping rules, include doesn't propagate macros.
EG you need #import <flx.flxh> in every file.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
