Re: lisp interface?
- Paul Moore wrote:
> 2. Expose a feature to allow the user to have access to Vim'sVim does make a difference between numbers and strings. Each variable
> functions. OK, but Vim doesn't distinguish internally between
> strings and numbers, so that bufexists() returns "1" or "0" -
> rather than numbers 1 or 0, which would be more useful (in Python,
> at least). So you can write a wrapper for bufexists() (but as
> above, where do you stop?) or you have to modify Vim's internals to
> have the concept of numeric and string values. That's a *massive*
has a "var_type" field. Variables are converted automatically when
used, which may make you think there is no difference.
ARTHUR: What does it say?
BROTHER MAYNARD: It reads ... "Here may be found the last words of Joseph of
Aramathea." "He who is valorous and pure of heart may find
the Holy Grail in the aaaaarrrrrrggghhh..."
BROTHER MAYNARD: "The Aaaaarrrrrrggghhh..."
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
/// Creator of Vim - Vi IMproved -- http://www.vim.org \\\
\\\ Project leader for A-A-P -- http://www.a-a-p.org ///
\\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
- "Stahlman Family" <stahlmana@...> writes:
> Sorry. I've looked into the source in if_python.c now, andNo problem - I agree with you entirely over the "not everyone has
> 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.
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 addYou may well be right. I think arrays were one of those features that
> 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...
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 theNo problem. I didn't take your comments personally, I was just using
> python interface lacking in some way. I do not at all.
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 theThat's exactly why there are so many language interfaces (and
> 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.
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