skaller wrote:
> On Mon, 2006-12-18 at 02:49 -0800, Erick Tryzelaar wrote:
>> Hi everyone,
>>
>> I finally got around to implementing my port of the tiny lisp
>> implementation from here:
>>
>> http://www.defmacro.org/ramblings/lisp-in-haskell.html
>>
>> It's pretty fun. While it doesn't actually parse syntax yet,
>
> 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 :)
>> A couple comments. First off, it takes a surprisingly long time to
>> compile this code.
>
> Felix compiler or C++ compiler?
>
>> On my mac it takes
>> about 9 seconds to compile and run.
>
> Some of the optimisation routine are less than optimal.
> However my experience is most of the time is spent in lookup.
>
> The file
>
> flxg_stats.txt
>
> keeps track time spent per compiler phase.
flxg_stats.txt:
parse=0.008257
desugar=0.027707
build=0.053617
bind=0.710162
opt=0.426281
inst=0.103947
gen=0.181311
tot=1.511282
Oddly enough, it's gcc. Today it's running in about 6 seconds. flxg is
taking 2.270 seconds, and gcc is using 3.914 for the compile and 0.375
for the link. Looks like felix generates a ton of code for this:
43 projects/lisp/eval.flx
24 projects/lisp/expr.flx
29 projects/lisp/functions.flx
41 projects/lisp/lisp.flx
60 projects/lisp/show.flx
3077 projects/lisp/lisp.cpp
1828 projects/lisp/lisp.hpp
5102 total
I wonder if there's anything that can be done to reduce / precompile.
>> Second, I got hit by the classic "if you don't use the output of a
>> function it can get optimized away" bug/feature.
>
> In what way? The code should be type checked whether or not
> it is used, it simply isn't instantiated if it isn't used:
> the optimiser optimises it away.
>
> In theory, there's no way you can tell, so why is it a problem?
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.
>> Third, typeclasses rule. I really like the show typeclass, and I can't
>> wait to add it to the standard library, once we resolve some of the
>> surrounding issues.
>
> What is there to wait for? Even if I don't like your changes
> I can always change them more, revert them, or discuss it,
> but I can't do any of those thing *until* you commit :)
Thats true :) I wasn't going to include it until all the bugs were
shaken out, but I suppose integrating it would do that a bit faster.
>> Forth, hitting compiler exceptions really can make things difficult.
>
> You mean bugs in the compiler? Or you mean bugs in the error
> reporting? Some errors are very well reported, some are not.
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.
Oh and one last one: the #import / #include of interdependent code.
There any way that we could implicitly put in import guards? 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?
-e
-------------------------------------------------------------------------
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
