Anyone heard of Bee Lisp?
in [Lisp]
|
Prev: A pascal generator in CL ?
Next: lightweight database
From: refun on 18 Mar 2010 04:26 In article <80cal6FcuvU1(a)mid.individual.net>, tkpapp(a)gmail.com says... > "Compatible?" I don't think you understand the term. Your BEE Lisp > is not at all compatible with eg Lisp 1.5, or any other version you > could call the original Lisp. But compatibility is beside the point - > Scheme and CL are not "compatible" with each other per se, but they > are both Lisps. > > Regarding BEE Lisp: you are certainly using the parenthesis syntax, > but you don't seem to know why. The real purpose is of course the > ability to write sophisticated macros, which give you the real power > of Lisp. These appear to be ruled out in BEE Lisp, because of the > primitive macro facilities. I'm actually curious if BEE Lisp is a Lisp. Arguments for it being a Lisp: - It has Lisp in its name - Some of the operators/function names are taken from the Lisp family of languages, but the semantics for some of them is different. - Parenthesized notation, albeit the official documentation seems to use rather non-standard(C-like) indentation for a Lisp. - It may be possible to write a metacircular interpreter for a tiny subset of it (remove the FFI and some functions), but this has not been tested yet. This may be enough to call it a Lisp, but nobody attempted to write one. QUOTE, COND, ATOM, EQ, CONS, CAR, CDR should likely be enough to write it. - It does have EVAL. It may be possible to use EVAL to emulate FEXPRs as long as one manually quotes the arguments in such a way to provide support for some crude syntax extensions. Arguments for it not being a Lisp: - If you ignore the FFI functions, the core language is rather tiny, and a lot of the functions have different semantics than you'd expect (DEFMACRO, LET, CONS, AND/OR, ...). DEFMACRO defines an inlined function. LET declares a local variable for the entire function, as opposed to just in the scope of LET, CONS does not make a CONS object, instead it seems to be a way to build lists. - Lists might not be made of CONSes, instead they may be a vector array of pointers (the documentation does not confirm this, but it seems to allude to such a representation). - It doesn't have proper lexical or dynamic scope. It appears to have C-like global/local variables, but not enough details about are given in the documentation. - No support for macros, symbol macros, reader macros. What is called a macro appears to be a way to define inlined functions. - No compile or readtime evaluation. - No local functions. - No lambda, no closures. - No lambda lists, or at least minimal variable argument support (don't see anything in the documentation) - No first class function objects, no APPLY or FUNCALL. - No first-class symbols, no functions to operate on symbols. - No apparent vector/array support, but one might be able to improvise something with the low-level memory access functions. - Lack of common standard library functions (map/reduce, list, list processing functions, ...) - It's unknown if its garbage collected, the documentation does not mention anything about this, but it provides MALLOC/FREE functions and some functions for reading/writing to memory addresses. - The documentation mentions something about automatic type conversion and gives a function to prevent strings from being automatically cast to integers. It's unknown if this behaviour is limited to a few functions or if automatic casting of arguments to other types always occurs. This is unusual for Lisp, as even though its a dynamic language, it usually provides some type safety, and when automatic coercion happens the documentation mentions this clearly(such as symbol designator, string designator, package designator, ...) - No packages or modules. - Type system is underspecified. - Lacks an object system. User may be able to emulate one, but it's unknown how much effort it would require. - No true defstruct support. It does have (external) support for something called DEFSTRUCT (rather different than Lisp's defstruct) - it's a C-like structure definition. It also appears to be limited to 4096 bytes per object, but the user can probable change that by redefining the library, quoted from struct.LSP: >(setf p (malloc 4096) ) ; one page is enogh for most types... User also has to manually free these objects with FREE or deleteObject. - Error handling seems to be limited to checking exit codes and a global variable called $EVAL_ERROR$ - Not portable to anything except Win32. - No streams or I/O. The recommended way is to use the Win32 FFI. - No hashtables. - No character object. You can only make a string made of one character from an ordinal. No way to access individual characters of a string, you can only get the ordinal of the first character. - It's unknown if anything except floats and up to 64bit ints are supported. I've managed to crash(gives an access violation (segmentation fault)) the evaluator by running something as simple as: (* 99999999 9999999999999999999999999999) - No clear way to access the environment, even though it's interpreted-only. - Indentation used in the documentation is C-like, but I don't think it's enforced. Even with all these shortcomings and its lack of support for a lot of features one might want in a Lisp, one might be able to call it a Lisp, just because it looks like it might be possible to write a metacircular interpreter for a subset of it, however nobody has published such an interpreter for it. It might also be useful to some Windows developers wanting to embed a Lisp in their applications, but it's questionable they'll be embedding a real Lisp. ECL or some Scheme sound like better candidates for programmers looking to embed a Lisp.
From: Giovanni Gigante on 18 Mar 2010 07:26 Tamas K Papp wrote: > With standardized, mature dialects of Lisp floating around I am curious why this phenomenon periodically occurs: that someone arises out of nothing claiming to have invented a "new lisp" -- which almost always fails miserably. I mean, maybe I am not informed enough, but I've never heard of "new cobols" or "new javas" or whatever (well, there's the "new kind of science", but that's another story). But lisp seems to have a special misterious charm that lures people into wanting to reinvent it. Why???
From: Andrew Poelstra on 18 Mar 2010 08:56 On 2010-03-18, Giovanni Gigante <giov(a)cidoc.iuav.it> wrote: > Tamas K Papp wrote: >> With standardized, mature dialects of Lisp floating around > > I am curious why this phenomenon periodically occurs: that someone > arises out of nothing claiming to have invented a "new lisp" -- which > almost always fails miserably. > I mean, maybe I am not informed enough, but I've never heard of "new > cobols" or "new javas" or whatever (well, there's the "new kind of > science", but that's another story). But lisp seems to have a special > misterious charm that lures people into wanting to reinvent it. Why??? Because it's so deceptively simple to implement. No doddering about with grammar rules, just (func a b c) And from there add a few short-hand characters (` ' , # etc), a few built-in functions (for math operators, say), and you're almost done. Now just add closures and garbage collection, and it's a little harder than you thought, but still good. Now add macros and a separate compilation/execution time and y'know what, let's just forget all those damn features, label it "lisp" and go have a beer. Writing software is stupid anyway. -- Andrew Poelstra http://www.wpsoftware.net/andrew
From: Tamas K Papp on 18 Mar 2010 09:04 On Thu, 18 Mar 2010 12:26:48 +0100, Giovanni Gigante wrote: > Tamas K Papp wrote: >> With standardized, mature dialects of Lisp floating around > > I am curious why this phenomenon periodically occurs: that someone > arises out of nothing claiming to have invented a "new lisp" -- which > almost always fails miserably. > I mean, maybe I am not informed enough, but I've never heard of "new > cobols" or "new javas" or whatever (well, there's the "new kind of > science", but that's another story). But lisp seems to have a special > misterious charm that lures people into wanting to reinvent it. Why??? That's quite a puzzle. The desire to improve on existing languages is certainly laudable, but if I wanted to make a better X, I would make sure that I understand existing X's fairly well. It is even more puzzling why they are trying to market it. Even if they had no idea of Lisps before, trying to implement one should have made them realize that they failed quite badly. A modicum of intellectual honesty should prevent them from selling it for money. That said, implementing a Lisp must be an interesting intellectual exercise. I wish I had known about Lisp when I was a teenager, I am sure I would have tried designing my own Lisp (I could still try, but now I am more interested in applications). Such undertakings are valuable for the learning experience, not the end result. But BEE Lisp certainly has nothing to do with this attitude. Tamas
From: Pillsy on 18 Mar 2010 11:35
On Mar 18, 7:26 am, Giovanni Gigante <g...(a)cidoc.iuav.it> wrote: > Tamas K Papp wrote: > > With standardized, mature dialects of Lisp floating around > I am curious why this phenomenon periodically occurs: that someone > arises out of nothing claiming to have invented a "new lisp" -- which > almost always fails miserably. I think there are two closely-related reasons. One is that implementing a simple Lisp interpreter is not tremendously difficult. The other is that there is the idea that Lisp is, at its core, a small number of special operators and primitive functions. There really is a tradition stretching back all the way to the very beginning that you don't need to offer a whole lot to be a Lisp. There's a lot of room between "a Lisp" and a complete implementation of Common Lisp, or a mature implementation of Scheme, or a respectable new dialect like Clojure. Sure, you don't need much more than QUOTE, LAMBDA, CONS, CDR and CONS to have a Lisp, but you need vastly more than that to have a Lisp that's useful as anything more than a learning exercise. The really pitiful thing about BEE Lisp is that it doesn't even meet that minimal standard. But even if it did, it's foolishly ignoring the fact that people have spent fifty years building on that initial simple core. It's particularly disappointing because saying, "I would like to use Lisp as a tool for using and experimenting with Windows DLLs in a convenient and interactive way," is a perfectly reasonable desire, and a great rationale for a Lisp project. But how on Earth do you get from there to implementing a whole new Lisp from scratch? Cheers, Pillsy |