From: Chris Bitmead
Subject: Re: Foreign functions (Re: Why lisp failed in the marketplace)
Message-ID: <>
In article <······················> ········ (Martin Cracauer) writes:

>This is correct but misleading
>In CMUCL, I define an alien struct this way:
>  (def-alien-type nil
>    (struct regex_t
>            (re_magic int)
>            (re_nsub size_t)
>            (re_endp c-string) 
>            (re_g voidptr) 
>    ))
>This definition generates Lisp macros to access the fields from Lisp. 
>But this is no different from the way (defstruct ...) works, so your
>point that using alien data from Lisp requires additional setup is not

I'm saying that, if you are having a standard which has to be able to
be implemented in any possible implementation of lisp, then I think
additional setup may be a requirment but that a particular
implementation may decide to ignore because it has a better way.

>>>- Will memory allocated in aliens be handled by the Lisp Garbage
>>>  collector? 
>>Of course not. Maybe there will be hooks in case you do though.
>"Or course?". A Lisp that uses a conservative collector anyway can do
>so, of course.

NO. We are talking about a standard interface here. No standard
interface can make the assumption that a conservative garbage
collector is being used.

So of course memory allocated in aliens will NOT be garbage collected,
unless you make special provision for it.

>>C functions expect NULL terminated. Lisp implementations are sometimes
>>not NULL terminated. If not, then they must convert. If so, then don't
>>convert. No problem.
>It is a problem as soon as you want an abstract layer for alien
>Although an interface may hide and automate the conversion, the
>programmer needs to know about it because a conversion may cause a
>totally different performance behaviour of the program.

We are talking about a standard interface here. Whether a particular
lisp cannot implement something super-efficient here is beside the
point. There has to be a trade off for the sake of a standard.

Of course if you want the ultimate performance, and/or don't care
about portability, then you can always use an interface native to your
particular lisp.

>>Yes fine. But even if only a subset of the possible functionality was
>>available it would be ok. In most cases the ultimate performance is
>>not an issue.
>In the case of FFI, I think it is very often, much more often than for
>Lisp code in general.

I don't think it is too often. The classic examples are building a GUI
and a database interface. Whatever overhead there is in the FFI is
totally and completely irrelevant.

| Chris Bitmead.....................................9690 5727 |
| ············· |
The sum of the intelligence of the world is constant.  
The population is, of course, growing.