Anyone heard of Bee Lisp?
in [Lisp]
|
Prev: A pascal generator in CL ?
Next: lightweight database
From: Tamas K Papp on 17 Mar 2010 10:27 On Wed, 17 Mar 2010 06:59:02 -0700, Coddie wrote: > I forgot to give comments on let and DEFMACRO. > > LET is very close to C++ local variable assigment. Let's say you have > global atom V and a local atom V Something like this: > > (LET V 1) > > (defun localfunction () > (LET V 11) > > ) > > While in global scope, V is assigned 1. When a program enters > localfunction, BEE Lisp creates a closure for V1 so that it becomes 11 > until function terminates. After that , a previous value is restored. > This is the behavior, described in standard lisp, AFAIK. Not really. What would be the BEE Lisp equivalent of the CL code (defun closure-accessor (&optional initial-v) (let ((v initial-v)) (lambda (&optional new-v) (if new-v (setf v new-v) v)))) (defparameter *a* (closure-accessor 9)) (defparameter *b* (closure-accessor 7)) (funcall *a*) ; => 9 (funcall *a* 13) (funcall *b*) ; => 7 (funcall *b* 5) (funcall *a*) ; => 13 (funcall *b*) ; => 5 ? > DEFMACRO - it's just like an inlined function, something very close to > C #define operator. > The variables are handled in very similar way. So you cannot handle variable capture etc. And yet you are, for some reason, calling this a Lisp. Ouch. Tamas
From: Coddie on 17 Mar 2010 10:59 On 17 маÑ, 17:27, Tamas K Papp <tkp...(a)gmail.com> wrote: > On Wed, 17 Mar 2010 06:59:02 -0700, Coddie wrote: > > I forgot to give comments on let and DEFMACRO. > > > LET is very close to C++ local variable assigment. Let's say you have > > global atom V and a local atom V Something like this: > > > (LET V 1) > > > (defun localfunction () > >  (LET V 11) > > > ) > > > While in global scope, V is assigned 1. When a program enters > > localfunction, BEE Lisp creates a closure for V1 so that it becomes 11 > > until function terminates. After that , a previous value is restored. > > This is the behavior, described in standard lisp, AFAIK. > > Not really.  What would be the BEE Lisp equivalent of the CL code > > (defun closure-accessor (&optional initial-v) >  (let ((v initial-v)) >   (lambda (&optional new-v) >    (if new-v >      (setf v new-v) >      v)))) > > (defparameter *a* (closure-accessor 9)) > (defparameter *b* (closure-accessor 7)) > > (funcall *a*)              ; => 9 > (funcall *a* 13) > (funcall *b*)              ; => 7 > (funcall *b* 5) > (funcall *a*)              ; => 13 > (funcall *b*)              ; => 5 > > ? > > > DEFMACRO - it's just like an inlined function,  something very close to > > C #define operator. > > The variables are handled in very similar way. > > So you cannot handle variable capture etc.  And yet you are, for some > reason, calling this a Lisp.  Ouch. > > Tamas- СкÑÑÑÑ ÑиÑиÑÑемÑй ÑекÑÑ - > > - ÐоказаÑÑ ÑиÑиÑÑемÑй ÑекÑÑ - Well, defparameter and funcall are not implemented. For what reason we call it Lisp? Because it is compatible with pure lisp of John McCarthy. If you're a lisper you should know that lisp is one of the languages that have lot of dialects, and the only common requirement for them is to be compatible with classical McCarthy Lisp. CL is not yet completely supported, but anyway it can be implemented in Lisp itself if all CL addons are backward compatible with pure lisp
From: Pillsy on 17 Mar 2010 11:11 On Mar 17, 9:50 am, Coddie <eugene.balaba...(a)gmail.com> wrote: [...] > Well, FFI requires developer to declare API prototypes. So, before > using API I, as a developer, must declare all APIs I want to use. Not really. CFFI supports the FOREIGN-FUNCALL macro[1] which requires no such pre-declaration, and it provides a pretty good picture of the lowest common denominator of what Lisp FFIs support, as its chief goal is portability across Common Lisp implementations. I would strongly advise you to become more familiar with the capabilities of modern Common Lisp implementations before you attempt to compete with them commercially. Cheers, Pillsy [1] http://common-lisp.net/project/cffi/manual/html_node/foreign_002dfuncall.html
From: Tamas K Papp on 17 Mar 2010 11:26 On Wed, 17 Mar 2010 07:59:49 -0700, Coddie wrote: > On 17 мар, 17:27, Tamas K Papp <tkp...(a)gmail.com> wrote: >> On Wed, 17 Mar 2010 06:59:02 -0700, Coddie wrote: >> > I forgot to give comments on let and DEFMACRO. >> >> > LET is very close to C++ local variable assigment. Let's say you have >> > global atom V and a local atom V Something like this: >> >> > (LET V 1) >> >> > (defun localfunction () >> > (LET V 11) >> >> > ) >> >> > While in global scope, V is assigned 1. When a program enters >> > localfunction, BEE Lisp creates a closure for V1 so that it becomes >> > 11 until function terminates. After that , a previous value is >> > restored. This is the behavior, described in standard lisp, AFAIK. >> >> Not really. What would be the BEE Lisp equivalent of the CL code >> >> (defun closure-accessor (&optional initial-v) >> (let ((v initial-v)) >> (lambda (&optional new-v) >> (if new-v >> (setf v new-v) >> v)))) >> >> (defparameter *a* (closure-accessor 9)) (defparameter *b* >> (closure-accessor 7)) >> >> (funcall *a*) ; => 9 (funcall *a* 13) >> (funcall *b*) ; => 7 (funcall *b* 5) >> (funcall *a*) ; => 13 (funcall *b*) >> ; => 5 >> >> ? >> >> > DEFMACRO - it's just like an inlined function, something very close >> > to C #define operator. >> > The variables are handled in very similar way. >> >> So you cannot handle variable capture etc. And yet you are, for some >> reason, calling this a Lisp. Ouch. >> >> Tamas > > Well, defparameter and funcall are not implemented. For what reason we You are not getting it. I was trying to find out whether closures were implemented, but either you don't understand or keep evading the issue on purpose. Again, very telling in either case. > call it Lisp? Because it is compatible with pure lisp of John McCarthy. > If you're a lisper you should know that lisp is one of the languages > that have lot of dialects, and the only common requirement for them is > to be compatible with classical McCarthy Lisp. CL is not yet completely "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. Of course, feel free to refute this claim if you can. Just implement ONCE-ONLY ( http://common-lisp.net/project/cl-utilities/doc/once- only.html ) in BEE Lisp, and post the result here. Same applies to closures. > supported, but anyway it can be implemented in Lisp itself if all CL > addons are backward compatible with pure lisp Yes, you can certainly write an X86 emulator in C++, call it from BEE Lisp, run CLISP in it and voila, you get CL via Turing completeness. But BEE Lisp itself seems to lack the facilities for 1) non-trivial macros, 2) closures. If you don't miss these, that again is a telltale sign that you don't even have a superficial understanding of Lisp. It is amazing that people who "invent" new dialects of Lisp over a weekend _always_ miss these two things. It is like inventing a car without wheels and an engine. Search the archives for threads on newLisp, which was a similar experiment. But at least those guys had the decency not to charge money for it. Tamas
From: MarkHaniford on 17 Mar 2010 14:00
Xah Lee and Madhu have demanded that we start using Bee Lisp, so I suggest we make the best of it and be positive about Bee Lisp |