Don't be surprised if once a C API is available that other people write dynamic bindings for that instead. IOW I'm not sure this is such a great idea for the goals of this project.
--- On Mon, 11/7/11, Marvin Humphrey <[email protected]> wrote: From: Marvin Humphrey <[email protected]> Subject: Re: [lucy-dev] Argument processing model To: [email protected] Date: Monday, November 7, 2011, 2:31 PM On Sun, Nov 06, 2011 at 12:01:59PM -0800, [email protected] wrote: > > On Oct 31, 2011, at 8:57 PM, Marvin Humphrey wrote: > > > Implementing a C API will be conceptually more complicated, because we will > > have to make some decisions and leave some features out. We can't support > > default values from C, for example. > > Perl’s gv_fullname function became gv_fullname3 and then gv_fullname4 when > more params were added. You could conceivably do the same for default > parameters, but it might lead to API explosion, which, come to think of it, > renders this a very bad idea. ;) The C API will just have to be less sophisticated because C itself is less sophisticated. No labeled params for C, either. :) Lucy C API users will have to enter default argument values manually. But we can protect them somewhat with a policy of considering the changing of a default value a backwards compatibility break. Lucy is primarily targeted at high level dynamic languages. It is not optimized for C developers. Marvin Humphrey
