Loading ...
Sorry, an error occurred while loading the content.

Re: lisp interface?

Expand Messages
  • Bram Moolenaar
    ... Vim does make a difference between numbers and strings. Each variable has a var_type field. Variables are converted automatically when used, which may
    Message 1 of 36 , Nov 1, 2002
      Paul Moore wrote:

      > 2. Expose a feature to allow the user to have access to Vim's
      > 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*
      > job.

      Vim does make a difference between numbers and strings. Each variable
      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..."
      ARTHUR: What?
      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 ///
    • Paul Moore
      ... 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
      Message 36 of 36 , Nov 2, 2002
        "Stahlman Family" <stahlmana@...> writes:
        > 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
        only" features.

        [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
      Your message has been successfully submitted and would be delivered to recipients shortly.