Hi Mark, > Since you don't want to continue this discussion on a theoretical basis, > can you please provide a concrete example of how the addition of > scm_exact_integer_sqrt might be a maintenance burden in the future, > given that our public C interface already consists of approximately 2K > functions, including most (maybe all?) of the other numeric operators?
Ok, ok, I have to admit that my reply extended the context from the specific question of exact-integer-sqrt to the more broader question of "write Scheme rather than C". As such most of what I wrote should be read in that broader context. > What I'm asking for is a specific example of how some future change in > the internal workings of Guile's implementation might result in us > saying "Damn, if only we hadn't exported those last few numerical > operators, this would've been less of a pain!" Returning to the question at hand, rather than publishing lots and lots of C interfaces, I would much rather see generic approaches like what Andy wrote in his reply: > Nota bene: this doesn't have to make the lives of C users difficult! On > the contrary, we have to make it easy to invoke the Scheme API, and in > this case to get some number of expected return values. For example in > this case, one could do a: > > scm_call_1_2v (scm_variable_ref (exact_integer_sqrt_var), n, &root, &rest); This looks very nice and reduces lots of function calls to a more generic interface that will be easier to maintain and is completely orthogonal to what is done in scheme. The opposite side of this coin - calling C from scheme - is nicely demonstrated by the sqlite3 bindings that Andy come up with[1]. In there, _everything_ is done in scheme. Not a single line of C is needed. This is due to the genericity of 'pointer->procedure' plus 'dynamic-func'. In my opinion it is a worthwhile goal to strive for such genericity also in the C calling to Scheme domain. Cheers Detlev [1] https://gitorious.org/guile-sqlite3 -- Practice random senselessness and act kind of beautiful.
