foreign-type-size implementation

[james anderson]

> On 2017-08-18, at 16:11, Luís Oliveira <luismbo at gmail.com> wrote:
> 
> Can't think of a particular explanation off the top of my head. I suspect we simply didn't expect performance-critical code to need foreign-type-size. What's your use case?

i am reading things from an lmdb instance and this is an integrity check.

> Alternatively, we could slap some caching on PARSE-TYPE but I'm pretty sure that'll lead to a least one cache invalidation bug down the road. :-)

sounds like something which would be waiting to break.

> 
> I think we can simplify your compiler macro to just two branches using CONSTANTP + EVAL as other such macros do in CFFI.

i am not sure my tests are correct and am not sure how parnoid they should be.
constantp stil needs to distinguish between keyword, defined constants and quoted terms.
i did not investigate the respective forms which is delivered to the compiler macro, but i do not think that i got it correct.

best regards, from berlin,
> 
> Cheers, 
> Luís
> 
> 
> On Thu, Aug 17, 2017, 09:07 james anderson <james at dydra.com> wrote:
> while profiling code which depends on foreign sizes, i observed that foreign-type-size was doing most of the work.
> this (so it seems) due to the circularity check.
> 
> is there some reason that there is no logic to decide to push the process into compile-time where it is possible?
> 
> something like:
> 
> (define-compiler-macro foreign-type-size (&whole form type)
> (cond ((or (keywordp type) (typep type '(cons (eql :struct))))
>          (foreign-type-size type))
>         ((and (symbolp type) (constantp type))
>          (foreign-type-size (symbol-value type)))
>         (t
>        form)))
> 
> 
> 
>