From ... From: Erik Naggum Subject: Re: What Lisp needs to beat Java, etc. Date: 2000/11/28 Message-ID: <3184422543911010@naggum.net>#1/1 X-Deja-AN: 698772333 References: mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 975435422 3445 195.0.192.66 (28 Nov 2000 18:17:02 GMT) Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Mime-Version: 1.0 NNTP-Posting-Date: 28 Nov 2000 18:17:02 GMT Newsgroups: comp.lang.lisp * "Frank A. Adrian" | Here are a few things that might make my programing life easier... : | (b) Standardize an FFI to code written in ANSI C. This is most probably a mistaken expression of the real desire. What you most probably want is a portable means of arriving at definitions in Common Lisp that reflect the nature of the C definitions, not to be able to "port" your hand-written definitions. Portability should not be done at the source code level, as that may entail implementation- specific properties that are very hard to duplicate elsewhere, such as varying needs to accomodate complex declarations. Rather, conforming Common Lisp code should read ANSI C code and extract the definitions from it and produce implementation-specific Foreign Function Interface code. This code can be arbitrarily hairy to reflect the what the Lisp and C worlds need to interact, including automatic type conversions and whatever else is necessary to talk to ANSI C. (Other languages should not be too hard to add to this, once the C substrate is there.) | (f) Create a portable interchange format that's lower level and more | compact than source code, but can be efficiently translated at load | time into machine code - portable FASL's, if you will. Once upon a time, the SGML world wanted a binary interchange format that would enable much less character-by-character parsing, i.e., that maintained significant parsing state in the interchange format itself. This standardization project was canned after several years of not getting anywhere. However, I would nominate ASN.1 as the language that best suits your needs. Instead of having to parse symbols and strings and such character by character, you could efficiently store the length of the object and just map the data right into memory. ASN.1 even has bignum support, although integers are known to be slow to parse in BER due to the use of a "continuation" bit in the values. | (h) Get rid of some of the cruft in the language - do we really need | all of the CxxxxxR functions? Do we really need first through tenth, | or would just telling people to use nth suffice? [...] Please, don't waste your time on wondering whether we need these. They're there, and they don't do any harm at all being there. All of this, which you call a "personal rant", is fairly random in my view. | But in any case, if the standard is to be changed, it should be | changed to make the language a better Common Lisp, not just aligned | to the latest fad of the hour. I think much of the slow progress in standards circles (at least in the most responsible standards cirlces) is intended to discourage the short-time view in a very strong, very painful way, so those who want fads of the hour will be incredibly frustrated and leave in disgust. This is a good thing, but the price may be too high for some of the ideas that aren't just fads of the hour. #:Erik -- Solution to U.S. Presidential Election Crisis 2000: Let Texas secede from the Union and elect George W. Bush their very first President. All parties, states would rejoice.