"Stahlman Family" <stahlmana@...
> Sorry. I've looked into the source in if_python.c now, and
> understand a little more about the interface. It looks very
> thorough. It's not that I have anything against the interface or
> Python. It's just that not everyone has python installed, and some
> who do have it installed don't have the python interface enabled;
> hence, plugins or extensions written with the python interface will
> be useful only to a subset of the Vim community.
No problem - I agree with you entirely over the "not everyone has
Python installed" point. It applies to *every* language interface, and
it's what has made all of the existing ones more or less "personal use
[Regarding string/number distinctions]
> I guess you saw Bram's response to this.
I did - I had forgotten that fact (unless it was added after I did the
Python interface and I hadn't noticed...) Actually, I really need to
go back to the Python interface and look at it in the light of Vim's
current code - it's not been changed for a *long* time. But part of me
feels that the demand isn't there - "if it ain't broke, don't fix it"
and all that...
> Actually, I don't think it would be all that difficult to add
> support for arrays to the eval implementation in eval.c. Perhaps if
> a growarray * member were added to the union var_val, and the
> growarray array to which it pointed were used to hold struct
> var... Arrays of arrays would be possible. I've implemented
> something along these lines for work. Maybe if I get some time soon,
> I'll play around with it...
You may well be right. I think arrays were one of those features that
a number of prople wanted, but which haven't been implemented for
whatever reason (Bram hasn't needed it, and no-one else came up with a
good patch, possibly).
> Please accept my apologies for having given the impression that I found the
> python interface lacking in some way. I do not at all.
No problem. I didn't take your comments personally, I was just using
the Python interface as the example I knew best - all of the existing
language interfaces have had to address the same issues.
> The problem is, I started looking into Ruby and Python at around the
> same time, and couldn't decide which one to go with. They both seem
> so similar in many ways. Ruby actually seems a little better
> designed to me, but doesn't seem to have caught on here as
> well... Maybe it's because I've done so much procedural programming,
> in so many different languages, that when I discovered Lisp and its
> variants, it was sort of like a breath of fresh air.
That's exactly why there are so many language interfaces (and
conversely, why none of them is a clear "standard"). Language choice
is a highly personal issue, and there's no way of getting agreement on
a standard - Bram would have to make an executive decision. And there
would still be the "not everyone has it installed" issue. [Actually,
if I was feeling like arguing the case, Lua makes a good embedded
language choice. It is tiny, designed to be statically linked into the
application (so no "it's not installed" issues) and highly
flexible. Of course, it's also relatively unknown, so *no-one* would
think it's the right choice - maybe that's an argument in it's favour
Anyway, I hope my point is clear - I personally don't have an issue
with extra language interfaces - the more the merrier - but I don't
think that there's any mileage in trying to get any particular one
"blessed" as somehow more official than the others.
PS One further thought - the language interfaces on Windows
dynamically load the language DLLs. This is incredibly useful, as I
normally build Vim with support for every language I can included,
then the same executable just works using whatever languages are
installed on the client machine. I'd recommend this approach for
any new language interfaces.
This signature intentionally left blank