From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Browning To: Marius Vollmer Cc: guile-gtk@sourceware.cygnus.com, gnucash-devel@gnucash.org Subject: Re: Taking the defs file issue Date: Sun, 12 Nov 2000 16:56:00 -0000 Message-id: <87k8a8d70j.fsf@raven.localnet> References: <200011122001.OAA18311@cs.utexas.edu> <878zqoeulm.fsf@raven.localnet> <87wve83eoa.fsf@zagadka.ping.de> X-SW-Source: 2000-q4/msg00026.html Marius Vollmer writes: > I quite strongly disagree with this. In my view, the functions > exported to the Scheme side must not be not be `dangerous' in the > sense that a pilot error can not lead to memory corruption, memory > leaks or similar. Well, I suppose this depends on your perspective, and what you want. If you want to create a tool that lets you do from scheme the same things you can do from C with a given C API, and if you want to provide a way for people to *quickly* wrap *existing* C APIs without having to write a lot of additional glue code, then I think it's going to be *very* difficult to avoid the "dangerous" things you're talking about. I guess this is going to run us right smack into the middle of the inevitable "flexiblilty vs performance vs safety vs user-burden" argument, where here user-burden means two different things. On the one hand, there's the burden on the "wrapper-spec-writer" to consider. If you require that nothing dangerous ever be allowed from scheme, then the wrapper-spec-writer's job's going to be a lot harder, and depending on the API, performance may likely suffer. As you pointed out, you had to change Gtk+ to make it safe, and in general, requiring universal safety may often require the wrapper-spec-writer to add "safe functions" on top of an existing C API before publishing to scheme via g-wrap. On the other hand there's the burden on the end-user of the scheme API. If you require everything to be safe, their life is probably, in general, easier, that is unless they just want to translate some code from C to scheme that already uses the C API successfully, but does it in a way that while perfect for the C API, doesn't match the "safe" interface quite right. Not sure what the right answer is, but it doesn't seem clear-cut to me. I could make a case either way... In the end, if we could design it properly, it still might make sense to take things in layers. G-wrap could, at the lowest level, provide some infrastructure that makes generating the correct glue easier, even if it's not completely safe, then a safe layer could be put on top of that that fixes up bits that aren't safe, and then only the safe functions could be published from the resulting module by default. However, I still worry that it may be hard to come up with a safe and efficient scheme side interface for every C API without a lot of effort, and in some cases, just having the API might be better than having the perfect one. I keep thinking of CPAN and how nice it would be to have some of that stuff available from guile, and then I think about how much less manpower we have to implement it, and *that* leads me to think about g-wrap (or something similar) to help automate the process, and automatically maintain the result... Don't get me wrong. I'd love a solution that was safe, efficient, and easy on the wrapper-writers. If we can come up with one, I'd be thoroughly pleased. FWIW -- Rob Browning PGP=E80E0D04F521A094 532B97F5D64E3930