bug-zile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-zile] Nested buffers


From: Reuben Thomas
Subject: Re: [Bug-zile] Nested buffers
Date: Thu, 13 Feb 2014 23:27:22 +0000

On 5 February 2014 22:30, Gary V. Vaughan <address@hidden> wrote:
Hi Reuben,

On Feb 4, 2014, at 3:23 AM, Reuben Thomas <address@hidden> wrote:
> I think it's also important to note this is a good fit with the structure of Lisp: while nested buffers can of course be represented naturally in Lua too (or even JSON), Lisp offers a more natural way to have them intepret themselves, because the relevant code (e.g. command) can be directly embedded in the data structure, without requiring a separate interpreter. Maybe this difference seems small, in that the "interpreter" in Lua could be trivial, but the nice thing about embedded code is that it's context-free, and can even take into account updates to the "interpreter".

All good ideas.  It's all just a simple matter of programming at this point ;)

But seriously, these are all directions that I think are worthwhile and fun.  I'm feeling more encouraged than ever to finish up sexpr and put a full-blown (and hopefully reasonably fast) Lisp engine into Zmacs, which is perhaps the limiting factor at this point?  In the mean time, pinning down a high-level design for what a nested buffer actually entails, and how to implement it so that the interactions are intuitive seems like a worthy next step to me.

Care to elaborate on your vision some more?

Sorry I took so long to get back to this.

The more I think about concrete coding, where you directly manipulate files, store data structures directly on disk e.g. a list as a directory of files, or an XML document as a nested directory structure, all the better intimately to intermingle different languages and tools, the more I think sexps are an ideal "abstract" representation, because they map easily to both concrete on-disk and in-memory formats, and also are suitable for programming with directly. The closest I've seen to trying to instantiate this vision is http://lush.sourceforge.net/ though there the emphasis is also on seamless integration with C (but I think that's an excellent thing too).

I'm unconvinced it's worth inventing another Lisp engine in Lua. Don't we have enough?

--
http://rrt.sc3d.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]