In article <······················@wavehh.hanse.de> ········@wavehh.hanse.de (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
>correct.
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
>definitions.
>
>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 |
| ·············@Alcatel.com.au............................... |
---------------------------------------------------------------
The sum of the intelligence of the world is constant.
The population is, of course, growing.