Anyone heard of Bee Lisp?
Mark Carter
heard of it? Is it any good?
Giovanni Gigante
> I'm not really a Lisp programmer, but I saw an ad for Bee Lisp. Anyone
> heard of it? Is it any good?
From the home page:
"BEE Lisp is a superficial compiler"
After decades of dreaming of the fabled "smart enough compiler", we are
left in a world of superficial ones.
And not even a flying car in sight.
Futu Ranon
I saw it on gmail and thought of posing this same question to c.l.l.
I looked into it a little and I could find no useful information beyond
the host site. The demo isn't very crippled so you could just just
evaluate it for your needs.
I did enjoy this claim from the website:
> BEE Lisp Compiler and the Lisp language itself makes compiled programs
> very difficult to crack or to reverse engineer.
fortunatus
for sale (as indeed that is one of the officially approved ways to
make money using the GPL). Or else, bearing in mind the "superficial
compiler" remark, it might be a stripped-down Lisp, or else it is some
project someone spent years building up and is trying to get some
benefit from.
I wonder if they get any customers? I doubt they provide support,
etc, beyond install instructions, from looking at the site. So what
would the value be? Do they simply count on folks finding their ad
before finding the world of (free, free) Lisps? What programmer who's
interested in Lisp wouldn't Google?
Or perhaps this is someone who is a consultant, and will use Lisp
anyway, and wants to charge their client for Lisp (which is OK by me
so long as the client understands), and so this is the storefront for
allowing client's purchasing dept to make the purchase?
In any case, clearly this is not a real business effort in itself, or
else more offered value would be apparent.
PS - I've often suspected with products that look like a repackage of
GPL code, there might be a trojan.
Tamas K Papp
Other amazing quotes from the website:
"BEE Lisp is a superficial expandable compiler for The Lisp language"
Wow, "The Lisp language". The one and only.
"Extensibility of the compiler through open COM interfaces"
Thanks, but I am fine extending my compiler with macros, and occasionally
compiler macros. Given the choice, I would rather go skinny dipping in a
piranha tank than use COM.
Also, docs & language specs are conspicuously missing. It seems to be
a one-person effort, and the nicest part is that it costs EUR 29.75.
With standardized, mature dialects of Lisp floating around, each with
at least one free compiler and development environment, I am sure that
people who are willing to buy this product will get exactly what they
deserve.
Tamas
Tamas K Papp
> I'm not really a Lisp programmer, but I saw an ad for Bee Lisp. Anyone
> heard of it? Is it any good?
I am curious where you saw the ad. Based on first impressions, Bee
Lisp is either a scam or a misguided attempt. In either case, it seems
surprising that they advertise.
Tamas
Futu Ranon
I've seen it in (and first heard of it from) gmail targeted ads and on
Google searches.
refun
says...
I've once bumped into it before as I saw it linked from Wikipedia's Lisp page,
but apparently they've removed it as it was spam:
http://en.wikipedia.org/w/index.php?title=Lisp_%28programming_language%29
&action=historysubmit&diff=339709588&oldid=338728703
The code samples appeared weird in their indentation and syntax. The function
names were close to CL's in some places, but the semantics were rather
different (DEFMACRO seems to be a way to define a function which will be
inlined, you can find the documentation in the CHM file included with the
demo). The standard library is rather tiny and the functions seem rather low-
level(malloc/free, JMP/CMP/CJMPREL/JMPREL/CALL/CALLAPI and some others).
This claim
> I did enjoy this claim from the website:
>
> > BEE Lisp Compiler and the Lisp language itself makes compiled programs
> > very difficult to crack or to reverse engineer.
made me curious, so I did take a second look at it.
A 15minute glance at the demo executable told me the following things:
- It's coded in C++, with heavy non-portable Win32 extensions, compiled with
Microsoft's C compiler version 8 (included in Visual Studio).
- The claim about it being a compiler is misleading - it's not a native code
compiler, but a bytecode one. Actually all code is compiled into bytecode and
appended at the end of the executable or DLL. They also seem to encrypt all the
strings with a simple 8bit/1byte xor cipher with a constant key for the entire
file(the fact that they use strings for almost everything was something that I
found strange). The interpreter reads the bytecode from the executable using
file APIs, which I'd expect to be quite slow, and it does it on-demand (one
instruction at a time).
- All standard/documented forms seem to be special forms which are handled in
the interpreter.
- There is more than enough info in the executable to make it rather easy for
an industrious reverse engineer to make a decompiler if they wanted. I think
reverse engineering code compiled for example by SBCL, despite being open
source, is a lot more harder than this.
I also don't think they stole GPL code unlike fortunatus' guess. Most of the
code is Windows API specific and the language seems a lot more primitive than
LISP 1.5 was. Anyone seriously considering writing real code should probably
pick a real Lisp instead, however I suppose it has some merit for giving
comfort to those that think picking an obscure/unused language with a strange
implementation which intentionally (slightly) obfuscates the generated code
will protect them from someone reverse engineering their precious secrets.
Futu Ranon
> The code samples appeared weird in their indentation and syntax. The
> function
> names were close to CL's in some places, but the semantics were rather
> different (DEFMACRO seems to be a way to define a function which will be
> inlined, you can find the documentation in the CHM file included with the
> demo). The standard library is rather tiny and the functions seem
> rather low-
> level(malloc/free, JMP/CMP/CJMPREL/JMPREL/CALL/CALLAPI and some others).
Online docs are here:
http://www.beelisp.com/online-help/default.htm
> <list> DEFMACRO (name parameters body)
> Defines marco and returns its body. Unlike function, macro body is
> inserted in place of its call.
> Example:
> (DEFMACRO println (text)
> (PRINT text)
> (PRINT “\n”)
> )
Who is Marco and what is BEE Lisp doing with his body?
Andrew Poelstra
It's obvious they made a typo and intended to write "defiles".
--
Andrew Poelstra
http://www.wpsoftware.net/andrew
refun
says...
I was a bit bored, so I took a quick look at the documentation. Here is a
complete listing of all functions/special forms:
CAR/CDR/CONS - seems to work on lists instead of cons cells. The documentation
seems to allude that a list might not be built out of CONSes, but it's actually
an array of pointers to objects. Testing (CONS 1 2) in the REPL seems to
generate a list of 2 elements (1 and 2).
READ - seems to either read something from the console or from a string and
coerce it into a list.
QUOTE - Prevents evaluation of the parameter. Strangely, typing random things
which can't be evaluated at the REPL seems to just return them as if quoted.
EVAL - The usual meaning, evaluates an object/quoted list.
PRINT - Prints an object. Strings seem to come with some standard C-like escape
sequences (\n \r \t \\ \")
SETF - I'll quote from manual:
>Sets value of object VAL to the value of object ID. If ID is identifier, then
function will search for the object with that name, going up through the stack
to higher addresses memory block, where global variables defined. If such an
object is found, its value will be changed to VAL. If such an object doesn?t
exist, then it will be created in local memory of current function. If ID is
list, then it will be evaluated, and assignment will be made to that evaluation
result.
LET - Misleading name. It's actually an assignment operator:
>Sets value of object VAL to the value of object ID. If such an object is found
on the local stack frame, its value will be changed to VAL. If such an object
doesn?t exist, then it will be created in local memory of current function. If
ID is list, then it will be evaluated, and assignment will be made to that
evaluation result.
> Example:
> (LET myvar ?(3 4 5)) ; assign list to ?myvar? atom
>(LET (CAR myvar) 5) ; replace the first element of ?myvar?
list to 5.
DEFUN/DEFBIN/DEFMACRO - Defines a global function, DEFBIN seems to define a
callback (arranges for the executable to have an export with that name that
calls the interpreter). DEFMACRO seems* to make the function inlined.
STRREAD - reads a string from the console
AND/OR - logical and/or, not short circuiting!
NOT - logical not
PLUS/MINUS/DIV/MUL - integer operations
LESS/MORE - comparsion functions
AREF - Returns nth character in a string or nth element in a list
LEN/LENGTH - List or string length
STRCAT - Concatenates strings.
LOOP - C while loop equivalent.
IDIV/IMUL/MOD - Unlike DIV and MUL, these only take 2 arguments.
MALLOC/FREE - Allocate/free a block of memory.
GETBYTE/GETWORD/GETDWORD/GETSTRING/SETBYTE/SETWORD/SETDWORD/SETSTRING -
read/write to logical memory of the application. Will work with any memory
pointer it seems, but I suspect they're meant to be used with malloc/free.
CALL - calls a pointer.
CALLAPI - Resolves and calls a Win32 API or DLL function.
S - Quote from documentation:
>Converts A to string and forbids automatic type conversion for resulting
object.
> Example:
> (CALLAPI "MessageBoxA" "User32.dll" 0 "Hello World" "12" 0) ; error! 12 is passed as number
> Solution:
> (SETF str (S ?12?) )
> (CALLAPI "MessageBoxA" "User32.dll" 0 "Hello World" str 0)
FREECONSOLE - "Detaches console from the process"
UNTYPED - "Cancels automatic type conversion for resulting object."
CHR - "Returns string, consisting of object A, which represents symbol ASCII
code"
ORD - "Returns ASCII code of first symbol of string S."
HEX - "Returns hexadecimal number represented by string S."
EXIT - Returns a value from a function.
EXITBLOCK - Returns from a block of code if the passed expression is true.
JMP - "Jumps to k-th function within current block and continue successive
execution."
JMPREL - "Jumps to k-th function relative to the current one within current
block and continue successive execution. Zero means next instruction."
CJMP/CJMPREL - Like JMP, but relative. The semantics of these functions are a
mystery to me.
$EVAL_ERROR$ - A global variable which contains the current evaluation error.
GET-PROGRAM-CODE - "Returns program code"
GET-PROGRAM-MEMORY - "Returns virtual machine memory (as object list)"
Other functions/special forms:
COND,EQ,EQUAL,ATOM,BOUNDP,ISSRING,ISNUMBER,ISINTEGER,BITWISE-AND/BITWISE-
OR/BITWISE-NOT/BITWISE-XOR
* - The documentation is not perfectly clear about the exact semantics of many
such forms, for example, the only line in the DEFMACRO's documentation is:
>Defines marco and returns its body. Unlike function, macro body is inserted in
place of its call.
>Example:
>(DEFMACRO println (text)
> (PRINT text)
> (PRINT ?\n?)
>)
This seems considerably more low-level than I expected.
Pillsy
It's right next to the Google Groups "sponsored links" for speech
therapists. I glanced through the documentation I found on the linked
website, and concluded that it's a worthy commercial competitor for
Newlisp.
Cheers,
Pillsy
Mark Carter
> I am curious where you saw the ad.
Gmail ad (not an actual spam email itself). I have been fooling around
with Lisp and a couple of Schemes lately, which explains why the ad
appeared.
Mark Carter
I saw it on a Gmail ad. I've been toying around with Lisp and some
Schemes recently.
cbbrowne
For a while, I saw it as an ad on GMail, evidently because I had
enough Lisp-ish stuff in my inbox.
--
Christopher Browne
Sufferer
like someone said here
Being a C++ programmer, I found this implementation to be very
comfortable to me.
Yes, their example are very C-styled, but it makes BEE Lisp very C-
programmer friendly
implementation.
I feel uncomfortable wrtiting true lispy code since I am a beginner in
Lisp.
So I think, for C++ programmer, willing to try lisp, BEE Lisp it the
best implementation.
I have some experience in disassembling and I looked into BEE Lisp
executable of LISPPAD.EXE,
a clone of notepad but in BEE Lisp. Well, it is not a compiler to
native code. But it is not
a byte-code one. It looks like a hybrid of native and byte code
mixture.
I suppose it is done to preserve mutable nature of lisp code - i.e we
still may
change functions bodies in runtime and I beleive this is possible
because there are
byte code in EXE (and some functions have native code inside).
And, another benefit is that it allows to make dlls and then use them
from C++ code so
that I can combine my C++ code with lisp. So, lispy things can be
coded and lisp and the
most other project - in C++. It's very convinient. I think it is good
implementation. Esepcially
for C++ programmers.
Thomas Atkins
If you look at Sufferers google groups profile
http://groups.google.com/groups/profile?enc_user=LgX6jRUAAADKWmRM6e4w9X67ak6Ds8769h3i3SmjGmAJbX05nZ-8fQ
it lists his website as beelisp.com.
Erik Winkels
What a surprise :-) I expected something like that reading his reply.
Erik Winkels
>
> I am curious where you saw the ad. Based on first impressions, Bee
> Lisp is either a scam or a misguided attempt. In either case, it seems
> surprising that they advertise.
I saw it in a free twitter client supported by ads on my iPhone when
searching for the #lisp tag. So at least he chose a good ad company :)
Coddie
I'm cheif developer of BEE Lisp :) And initially it was my idea to
implement such product. Currently, development team consist of several
developers, but in the begining (in 2004, when the first line of code
appeared) it was just me.
Well, the purpose of this product is to give a "traditional"
imperative language programmer (such as pascal, C++ etc) some
implementation
of Lisp that he will be comfortable with. If you like, BEE Lisp is a
lisp for beginners. Of course, it is not complete common lisp because
CL is qute large and the development team is quite small :) So the
main focus was to implement classical lisp (McCarthy one) that has an
easy interface to Win32 API. (however, with a Common Lisp in mind, I
hope in future releases we'll get more close to CL).
I'm of course, aware of some other implementations that are older than
BEE Lisp. But their foreign language interface (i.e. interface to api)
is more compicated as well. And, speaking about price, those
implementations are far more expensive.
BEE Lisp was written from scratch, so it is NOT an wrap over a GPL
implementation like someone said here. And of course, it is not a
trojan - I suggest everyone who doubts it - just send BEE Lisp files
to AV vendors. Well, just post it on virustotal for example.
We have a solid number of custumers who are satisfied with BEE Lisp
and we keep working to improve our product.
I am a C++ developer myself and was enchanted by Lisp in mid 2000s. I
tried some implementations and most of them
were quite hard for a 'traditional language' developer to move to. So
I decided to make a Lisp that will make this step easier.
As I said, we keep working to imporve BEE Lisp and you may send your
ideas about improving it to support - we'll try to implement it in
future versions. And of course, everyone is encouraged to try demo
version before buying a full one - thats exactly demo version is
created for :) Demo version also contains full language reference and
some samples to demonstrate main BEE Lisp features.
P.S. Speaking about Sufferer, I haven't noticed ANY home page in his
profile :)
Tamas K Papp
> future releases we'll get more close to CL). I'm of course, aware of
> some other implementations that are older than BEE Lisp. But their
> foreign language interface (i.e. interface to api) is more compicated as
> well. And, speaking about price, those implementations are far more
> expensive. BEE Lisp was written from scratch, so it is NOT an wrap over
That's a lie - not all of them are more expensive. In fact, there are
excellent _free_ CL implementations out there.
> a GPL implementation like someone said here. And of course, it is not a
And of course you know about them...
> main BEE Lisp features. P.S. Speaking about Sufferer, I haven't noticed
> ANY home page in his profile :)
I have seen it too, he may have changed it in the meantime. Don't
worry, creating false endorsements for worthless products is not as
easy as it initially looks, you guys will get better at it gradually.
At best, BEE Lisp is a joke implementation, easily dominated by freely
available CL and Scheme implementations. You keep hinting at some
vague advantage to C programmers, and "difficulties" with foreign
function interfaces of existing dialects/implementations, but so far
you have failed to make any convincing arguments. You won't get away
with handwaving here: you have to point at an actual FFI and tell us
why you find it hard to use, and how BEE Lisp is better.
I wonder why you are doing this. Trying to sell a product like this
on c.l.l is like walking into a physics conference and trying to sell
perpetual motion devices.
Maybe you get the occasional sucker who won't google for 3 minutes to
learn more about Lisp before making a purchase on your website, but
then it is in your best interest to keep a low profile and not engage
in any arguments.
Tamas
Coddie
looks easy to use for me. There are commercial implementations
however, that are more convinient than GPL ones, but they are more
expensive.
I see, Tamas, you really don't like BEE Lisp :) So - it is your right
- people have different taste. For example, some of them like Linux
and really hate Windows (and windows users also : ) - others have
opposite opinion, and some of IT professionals like both Win and
Linux. The same thing may be applied to languages and compilers =)
Well, I really hope that our customers appear on this discussion some
day and say what they think about product they purchased by
themselves. And I think they google a lot before purchasing BEE Lisp.
Some of them post a mail to support with their questions (and, we
answer them of course) before taking a descision to buy BEE Lisp.
Tamas K Papp
> Well, of course I heard about GPL implementations - but none of them
> looks easy to use for me. There are commercial implementations however,
"Looks"? Have you actually tried them? Do you have anything concrete
to say about them?
> that are more convinient than GPL ones, but they are more expensive.
> I see, Tamas, you really don't like BEE Lisp :) So - it is your right -
> people have different taste. For example, some of them like Linux and
> really hate Windows (and windows users also : ) - others have opposite
You are trying to fudge the issue here, trying to make this sound like
a matter of taste instead of entering into a discussion about the
technical merits of BEE Lisp (or the lack thereof). This approach is
understandable, given that it would be hard to compete with mature CL
or Scheme implementations. I find your strategy dishonest, but you have
to work with what you've got.
> thing may be applied to languages and compilers =) Well, I really hope
> that our customers appear on this discussion some day and say what they
> think about product they purchased by themselves. And I think they
Please, don't bother making up fake posters who will "endorse" your
product.
To sum up: during this discussion, you haven't made a single technical
argument concerning BEE Lisp, the choices you made when implementing
it, why you made them, etc. As long as you avoid technical discussions
about your product, it will be treated as bogus, no matter how many fake
endorsements we get.
Best,
Tamas
Coddie
As I said we took classical Lisp for a basis. The main goal of BEE
Lisp was to provide a convinient way to talk to DLLs.
There were some possible approaches. We could make our users to
describe API prototypes (something that FFI requires) before they
could use it, but we decided to allow just a mention of function name
and a DLL where it is located. Why? First of all, to reduce amount of
code user has to type. This approach however, has it's disadvantage -
you may give for example less parameters to a function and cause an
exception in your app. So it's not a "type-safe" language. However,
programmers usually look into a documentation of particular API and
pass correct amount of parameters. By the way pure C has same feature,
but it still beloved language of systems programmers. So, we made a
choice of reducing coding in this issue.
A DLL, coded in BEE Lisp may contain "native" functions and C++-like
functions. In first case, you define a function via DEFUN form and
this function will contain Lisp native types - ATOMS and Lists as it's
parameters. You may however, use them from C++ via LispObject
interface.
Other functions - non-native may have C-like parameters - integers,
strings, structures etc.
Well, BEE Lisp "kernel" is rather minimalistic in this issue , but is
upgradable through additional libraries user may write in lisp itself
or as an "COM-addon". For example, LISPPAD sample has some sort of C-
like structures support, that is implemented in struct.lsp.
We also implemented BEE Lisp as a series of COM servers, so user may
drive compilation process programmatically. It allows him to make for
example an IDE for BEE Lisp or something like that. BEE Lisp however,
integrates itself into PSPad a popular multilanguage IDE.
And by the way, you haven't pointed concrete free (or commercial)
implementation here to compare BEE Lisp with.
Coddie
it to move such descussion there...
Tamas K Papp
> Technical descisions... Ok, let's show some of them here. As I said we
> took classical Lisp for a basis. The main goal of BEE Lisp was to
> provide a convinient way to talk to DLLs. There were some possible
> approaches. We could make our users to describe API prototypes
> (something that FFI requires) before they could use it, but we decided
> to allow just a mention of function name and a DLL where it is located.
> Why? First of all, to reduce amount of code user has to type. This
I don't see how this requires less typing than, say, CFFI. But in any
case, you can autogenerate FF definitions for CL (see SWIG).
> itself into PSPad a popular multilanguage IDE. And by the way, you
> haven't pointed concrete free (or commercial) implementation here to
> compare BEE Lisp with.
You could compare foreign function interfaces to CFFI, which is the de
facto standard for CL. You can compare BEE Lisp to CL. Then, in
effect, you will be comparing to all free & commercial implementations
of CL. The point is that these things are standardized, so you don't
have to pick a single one.
However, the FFI is not a central issue. I am dismissing BEE Lisp
because the design of the core language deviates from conventions in
ways which could only be termed brain-dead (eg LET, DEFMACRO, etc).
Even if you had the most amazing FFI, programming in BEE Lisp would
still be anything but convenient. Can you provide a link to a single
medium-scale OSS* project written in BEE Lisp?
Tamas
*It has to be open source, otherwise the claim that it is sufficiently
complex and/or written in BEE Lisp is not verifiable.
Coddie
> because the design of the core language deviates from conventions in
> ways which could only be termed brain-dead (eg LET, DEFMACRO, etc).
DEFMACRO?
Speaking about large scale projects in BEE Lisp - I don't know any
yet.
I think that's because we haven't got lots of corporate customers yet.
Tamas K Papp
You carefully deleted my questions where I asked you to support your
claims w.r.t alleged inconveniences of FFI in CL. Very telling.
>> I am dismissing BEE Lisp
>> because the design of the core language deviates from conventions in
>> ways which could only be termed brain-dead (eg LET, DEFMACRO, etc).
> Can you please be more concrete - what's exactly wrong with LET &
> DEFMACRO?
DEFMACRO: it is unclear how you handle variable capture etc.
LET: appears to be nothing more than an assignment operator. Does BEE
Lips have closures?
> Speaking about large scale projects in BEE Lisp - I don't know any yet.
> I think that's because we haven't got lots of corporate customers yet.
Given how backward BEE Lisp is, I would be surprised if you had a
_single_ serious customer.
Cheers,
Tamas
Coddie
> On Wed, 17 Mar 2010 04:17:40 -0700, Coddie wrote:
>
> You carefully deleted my questions where I asked you to support your
> claims w.r.t alleged inconveniences of FFI in CL. Very telling.
Well, FFI requires developer to declare API prototypes. So, before
using API I, as a developer, must declare all APIs I want to use.
I suppose however, that there might be some already declared APIs (for
example, most used ones) , but in general developers have to spend
time declaring standard apis they're going to use.
By the way I mentioned it indirectly, while I was talking about BEE
Lisp - to - API interface.
Coddie
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.
DEFMACRO - it's just like an inlined function, something very close
to C #define operator.
The variables are handled in very similar way.
Tamas K Papp
> 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
Coddie
>
> - Показать цитируемый текст -
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
Pillsy
[...]
> 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
Tamas K Papp
> 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
markha...@gmail.com
suggest we make the best of it and be positive about Bee Lisp
refun
> "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.
Giovanni Gigante
> 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???
Andrew Poelstra
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
Tamas K Papp
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
Pillsy
> 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
Aleksej Saushev
> In article <80cal6...@mid.individual.net>, tkp...@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.
...
> 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.
If it is Lisp, there should exists mutual intelligibility between BEE Lisp
and other Lisp dialects Common Lisp and Scheme included.
As you can easily see from above, this is hardly the fact.
Therefore BEE Lisp isn't Lisp.
--
HE CE3OH...
Pascal J. Bourguignon
> I think products like this are usually one of the GPL Lisps wrapped up
> for sale (as indeed that is one of the officially approved ways to
> make money using the GPL). Or else, bearing in mind the "superficial
> compiler" remark, it might be a stripped-down Lisp, or else it is some
> project someone spent years building up and is trying to get some
> benefit from.
>
> I wonder if they get any customers? I doubt they provide support,
> etc, beyond install instructions, from looking at the site. So what
> would the value be? Do they simply count on folks finding their ad
> before finding the world of (free, free) Lisps? What programmer who's
> interested in Lisp wouldn't Google?
>
> Or perhaps this is someone who is a consultant, and will use Lisp
> anyway, and wants to charge their client for Lisp (which is OK by me
> so long as the client understands), and so this is the storefront for
> allowing client's purchasing dept to make the purchase?
>
> In any case, clearly this is not a real business effort in itself, or
> else more offered value would be apparent.
>
> PS - I've often suspected with products that look like a repackage of
> GPL code, there might be a trojan.
If it was a repackaging of GPL code, the sources should be provided, so
there would be no trojan.
People wanting to sell trojans would use another license, such as MIT or
BSD....
Once again, the goodness of GPL proves over the evilness of BSD! :-)
PS: No need to mention that people distributing trojan woundn't mind
defying the GPL too.
:-)
--
__Pascal Bourguignon__
Pascal J. Bourguignon
Personally, the only thing that I find frightening in www.beelisp.com is
that they do not mention that it's a Common Lisp (or scheme or ISO
Lisp). All the rest looks rather nice (apart from a few hints such as:
The majority of Lisp systems are provided with a considerable
quantity of libraries often frightening users by its large size and
slowness. Newbies who studies Lisp usually afraid of it - , they
think. Why do we need to deliver additional libraries with the
compiler, if all necessary functionality is already present in the
operating system? Well, we don't if we are BEE Lisp programmers!
).
If they took a CL implementation, and wrapped it in a nice MS-Windows
IDE such as what Bee Lisp looks to be, and added features such as
"stand-alone" compilation to DLL and nice FFI, I'd be all in favor.
Even if it was only a "subset of the Common Lisp language" or even if it
was only a scheme.
--
__Pascal Bourguignon__
Pascal J. Bourguignon
> So the main focus was to implement classical lisp (McCarthy one) that
> has an easy interface to Win32 API.
Are you aware that McCarthy work is 50 years old?
That is, it is almost as old as the Big Bang, in computer history...
I, for one, implemented the AIM-8 LISP in Common Lisp
http://www.informatimago.com/develop/lisp/small-cl-pgms/aim-8/
but it is more of a joke or rather an archeological reconstruction and
nobody would dream making it a commercial product. Well nobody but
you.
So, let's grade your Bee Lisp according to this criteria. How well does
Bee Lisp compile to a DLL the programs written 50 years ago such as the
Wang algorithm?
http://www.informatimago.com/develop/lisp/small-cl-pgms/wang.html
At least, Common Lisp only needs half a page of compatibility layer to
run it unchanged. How does Bee Lisp fare?
> (however, with a Common Lisp in mind, I
> hope in future releases we'll get more close to CL).
You can be sure we all pray so that future releases of Bee Lisp may
qualify at least as a "subset of Common Lisp". Check the standard and
notice how this is explicitely allowed, and it would be a great
feature.
In the meantime, you may want to study the literature about "tree
shakers", and consider a rewrite using eg. ecl.
http://ecls.sourceforge.net/
--
__Pascal Bourguignon__
fortunatus
> I suppose we should redesign our website and add some kind of forum to
> it to move such descussion there...
Good idea - and you could collect 1) suggestions for added features;
2) suggestions for improvements; 3) customer stories, including links
to their commercial websites.
As others here, I wonder why your customers would pay for the
product. For instance MzScheme and Guile are embeddable into C
programs by design.
And I wonder, to make money, why not choose to advocate a mature Lisp
product (CL, Scheme, Clojure, etc) and provide services to your
customers like training. Obviously with BEE you must provide training
already. That way you get a fuller language without investing
programmer hours. You could invest more hours into marketing - and
you would have a solid basis of features to market. And your training
business could probably expand a lot faster.
You could extend a mature product with some special DLL interfacing to
meet your DLL motivations - and any such changes would be a basis for
marketing, as well.