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

lisp interface?

Expand Messages
  • Brett Pershing Stahlman
    Does anyone know whether incorporating a lisp interface (similar to the vim interfaces for python, perl, ruby, etc...) is on the todo list or has ever been
    Message 1 of 36 , Oct 28, 2002
      Does anyone know whether incorporating a lisp interface (similar to the vim
      interfaces for python, perl, ruby, etc...) is on the todo list or has ever
      been discussed? Aside from the fact that lisp is a major programming
      language, it also happens to be a language for extensibility familiar to
      many emacs users; consequently, the addition of a lisp interface to Vim
      might remove one of the major barriers to a longtime emacs user considering
      the switch to Vim for it's better editing features.

      Brett S.
    • 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.