[plt-scheme] Linking Scheme- and C-variables

From: Richard Cleis (rcleis at mac.com)
Date: Sat Nov 1 20:26:53 EST 2003

I don't have enough scheme experience to estimate efficiency.  I just 
like to do as much as possible in scheme.  By keeping the primitives, 
er, primitive, bounds-checking etc can be written and tested in 
DrScheme then scheme_loaded into the embedding app.  The scheme code 
needs to simulate the primitive to get everything working, then the 
primitive-simulator is removed and the embedded code is tested with the 
c-primitive.  (The actual primitive might conveniently overload the 
simulated primitive, but I haven't tried that.)

rac

On Saturday, November 1, 2003, at 04:36 PM, Daniel K. Skovenborg wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>>>> I access c-doubles, for example, by making a
>>>> closure-like primitive for
>>>> each variable:
>>>>
>>>> scheme_add_global( "access-the-double",
>>>> 		       scheme_make_closed_prim_w_arity(
>>>> AccessADouble,
>>>> &theDouble,
>>>> "access-the-double",
>>>> 0, 1), e);
>>>>
>>>> AccessADouble is written to return theDouble with
>>>> scheme_make_double(theDouble).  If a parameter is
>>>> supplied, it is
>>>> validated then stored in theDouble first.
>>>>
>>>> Ie, (access-the-double 12.3) "sets" theDouble to
>>>> 12.3.
>>>> (access-the-double) "gets" 12.3 .
>>>
>>> That's exactly what I'm trying to avoid: making
>> access-functions for
>>> each variable that should be used :)
>>
>> AccessADouble is only written once, and can be bound
>> to as many
>> variables as you care to register with
>> scheme_make_closed_prim_w_arity.
> [snip]
>
> So, you method will work and when used with Eli Barzilays hack it can't
> be seen in the code that we're using access-functions.  But do you 
> think
> it would be slower or faster than my method 2 (the wrapper classes with
> overloaded operators calling scheme-functions) - especially if common
> calls like scheme_evaluate_string("foo", env) are compiled in the
> constructor before use.
>
> Wouldn't the first be fastest if the most of the work with the 
> variables is
> done in C and vice versa (the environment that have to call wrapper
> functions will be the one making delays compared to working with the
> variable in the other environment)?
>
> In my case it's a game where the characters behavior are scripts. So
> Scheme will do reading and writing with the variables while I suppose
> C++ will read them (when deciding where to display the characters,
> determining if they're dead etc).
>
>>> 2. The variables are in the Scheme environment and
>> can be accessed in
>>>    similar ways:
>>>     SCHEME_INT_VAL( scheme_evaluate_string("foo",
>> env) ) to get the
>>>    value  of the integer foo. To set the variable:
>>>     Scheme_Object * args[2] =
>> {scheme_evaluate_string("foo", env),
>>>
>> scheme_make_integer(42)};
>>>     scheme_apply(set, 2, args);
>>>    where
>>>     Scheme_Object * set =
>> scheme_evaluate_string("set!", env);
>>>
>>>    This could either be encapsulated in
>> C-functions (taking a string
>>>    argument that contains the name of the
>> variable) or in a class (one
>>>    for each type) with overloaded 'type'-operator
>> (for example operator
>>>    int for the integer-wrapper class) and =
>> operator. I like the latter
>>>    best.
> [snip]



Posted on the users mailing list.