Re: [Chicken-users] <inexact> and <exact>

[Daniel B. Faken]

On Thu, 12 Aug 2004, Felix Winkelmann wrote:
> Daniel wrote:
> >   Do you think chicken will be able to handle the class-specializations
> > (maybe via user-defined class specification?) and/or different object
> > systems any time soon?  Maybe there could just be a user-accessible
> > version of the bindings that currently tie C++ to TinyCLOS?
> >   I would like to implement it myself, but don't have time..
> 
> You mean forms similar to foreign-lambda... specifically for C++?

Felix,

  Thanks for the other replies.  Macros + foreign-lambda* seem to be 
sufficient.

  What I meant above was: Chicken is autogenerating code that can tie 
TinyCLOS-instance creation to C++-instance creation (putting the C++ 
pointer in the 'this slot).  It is also able to infer a TinyCLOS 'class' 
for certain C objects (strings, numbers, etc.).  But why tie the system to 
TinyCLOS?  Why not let the programmer have control over how C++/C objects 
are "wrapped" by the EasyFFI?
  Basically, what the EasyFFI is adding here, and doesn't (I think) have 
a macro equivalent, is the parsing of C++ and subsequent interpretation in 
terms of TinyCLOS.  Why not make the parsed definitions available to user 
code, like maybe:
(define defs
#>$     ;// '$' is just an arbitrary new suffix for this mode
class foo {
  int foo(int bar);
  int foo(double bar);
  int foo(char *bar);
}
rabbit *abracadabra(char *hat);
<#
 -->
'defs' contains a list/structure indicating the classes, types, functions, 
etc. that have been specified, their C/C++ parameter/return types
(which only seem available at compile time right now),
closures mapping to the functions, constructors/destructors for the 
classes/types, etc.

  Now maybe this is a bit too *much* information for most people defining 
an FFI, and I would build an EasyFFI layered on top of this which just 
defines things the way they are now - but it seems like it would be useful 
for things like using object systems other than TinyCLOS (e.g. meroon), 
and allowing run-time inspection of FFI-closures' types etc.

  Forgive me for rambling here.  Maybe what I really should do is just 
make some bindings for one of the C/C++ parsers out there.

cheers,
Daniel