From ... From: Erik Naggum Subject: Re: Theory #51 (superior(?) programming languages) Date: 1997/01/23 Message-ID: <3063019639826071@naggum.no>#1/1 X-Deja-AN: 211700349 references: <5c7os1$plk@news-rocq.inria.fr> mail-copies-to: never organization: Naggum Software; +47 2295 0313; http://www.naggum.no newsgroups: comp.arch,comp.lang.lisp,comp.lang.scheme * Robert Harley | If you're lazy, use some other language that always checks even when you | know for a fact that overflow cannot occur, thereby increasing your code | size drastically and needlessly slowing down most arithmetic operations. this is interesting. do you have a suggestion for how I can have the software that fails for me (or that I can't trust) automatically rewritten into a language that does check for overflow, to take but one example? it is also interesting that you think it's either all or nothing and that overflow is extremely expensive. no wonder programmers like you don't want overflow detection! but I can only guess that your job security is better than your users' safety. as for speed, I'm using Allegro Common Lisp in two projects right now. the compiler has a switch `declared-fixnums-remains-fixnum' that gets true if speed > 2 and safety < 1 in the optimization settings. (those are the defaults; I can change the conditions under which it is true.) I can wrap a piece of code in (locally (declare (optimize (speed 3) (safety 0))) ...) and then I won't have overflow detection. I love _having_ that option, but it has yet to be used in real code. in any case, the code produced at these settings is as fast as C, or even faster, considering that a lot of other optimizations kick in that C can't do. (e.g., tail call merging.) #\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.