OK, last word.
It's been rumoured that Tyson Dowd said:
> if you write a 3rd party tool
> to do interop, it's very hard to get the languages to help write your
> tool or keep it up to date.
Well, I sense a bit of the us-n-them perception that comes with
proprietary code. And of course, the whole economic point of
open source is that if you care enough, you can fix it.
You don't have to be either a core perl developer, or a core swig
developer, to make changes to them to make it do what you want it to
do.
And the flip side: if you're a maintainer of an unpopular tool,
of course its very hard to get anybody help you maintain it.
But if its important, you will get help from many places. And
that's the whole Open Source vs. Proprietary ansatz.
--linas
>thesis
Sooo ... wouldn't a declarative language be exactly the right thing
for describing an interface? (So that I can auto-convert my C header
files to e.g. mercury or other declarative lang, and then, from that,
autogenerate um, guile bindings? You said that the 'intermediate
language' would have to be a superset of what other languages provide,
but is that really true? It doesn't need to be a superset, it only
needs to be able to describe a superset; algorithmically, we'll do
the rest. I'm hoping that you'll respond that in fact, yes, with
mercury, you can go places that the corba IDL people or the XML
Schema people (or even the java reflection people) haven't even
thought of yet ...
--linas
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
