Prev: A pascal generator in CL ?
Next: lightweight database
From: Tamas K Papp on 17 Mar 2010 07:10
On Wed, 17 Mar 2010 03:44:44 -0700, Coddie wrote:

> 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.
From: Coddie on 17 Mar 2010 07:17
>  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?
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.

From: Tamas K Papp on 17 Mar 2010 09:11
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.

>>  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
From: Coddie on 17 Mar 2010 09:50
On 17 мар, 16:11, Tamas K Papp <tkp...(a)gmail.com> wrote:
> 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.
From: Coddie on 17 Mar 2010 09:59

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.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: A pascal generator in CL ?
Next: lightweight database