>> http://lists.motion-twin.com/pipermail/neko/2006-May/000931.html > > Yes, but that's Isaac's biased view of what happened.
It seems the only place i've found were he tries to explain why the Felix isn't in the Shootout. His (official) reason seems that the language doesn't have the neccessary user base... His other place, where he humors the Felix, shows the same: http://osdir.com/ml/lang.shootout.general/2004-11/msg00148.html he calls the language obscure. That leads me to quote a phrase from G.K.Chesterton which i were recently translating: "But there is something psychologically Christian about the idea of seeking for the opinion of the obscure rather than taking the obvious course of accepting the opinion of the prominent." I would encorage everybody to Ctrl+F the phrase and read the enclosing paragraphs to better understand what he meant: http://www.ewtn.com/library/theology/orthodox.htm This being the only argument against excluding Felix from Shootout, apart from it being inconvenient to have an obscure laguage thrashing the tests, we can safely redo the test on the Felix site. And, BTW, your evaluation, i think, is interesting enough to be mentioned in the BLOG! ; ) > I can't get the Haskell version of the code to compile .. not a > Haskell programmer ;( > > You're welcome to contribute -- all you need is willingness and a > sourceforge account :) I seem to have both, if not the time (bad management on my part). I don't thinkg the Sourceforge have GHC. 8<-------------------------->8 [EMAIL PROTECTED] ~]$ ghc -bash2: ghc: command not found [EMAIL PROTECTED] ~]$ find /home/groups/f/fe/felix/ | grep ghc | wc -l 0 8<-------------------------->8 Do you have the GHC installed? > First, Felix doesn't support exception handling: only the run time > system (or user C++ libraries) can throw exceptions .. with one > caveat -- Felix throws continuations sometimes to unwind the machine > stack before continuing on to unwind the spaghetti stack. > Other than that .. any error or C++ exception just aborts the > thread (which is a problem .. it should abort the program :) When maintaining real systems, error management is crucial. The programmer needs to know, where the error occured. If you have a function which reads from a file descriptor, the information that error occured in that function is useless - there is so many places in your program and in your libraries where the file descriptors are used. It is essential to know who called this function. I don't mind if this information is placed somewhere in the runtime (instrumentation?) with the help of the programmer, like GHC profiler, where you can place "points of interest" manually, but it should have the stack-like semantics, e.g. named closures, that, when entered to, occurs in the stack trace, and when exited from, no longer occurs in the stack trace... Given the "named closures" the Felix compiler could record the file-line number information in there, without the help from the different debugging information formats, DWARF etc, so that's a plus. ------------------------------------------------------------------------- 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
