[swift-lldb-dev] REPL questions

[Todd Fiala]

> On Dec 6, 2015, at 6:48 AM, Perry E. Metzger via swift-lldb-dev <swift-lldb-dev at swift.org> wrote:
> 
> On Sat, 5 Dec 2015 16:33:54 -0800 Todd Fiala via swift-lldb-dev
> <swift-lldb-dev at swift.org> wrote:
>> Thanks for the questions on the REPL.
> [...]
>> I would direct you to those licenses to see if they are
>> compatible with your desired usage.
> 
> Licensing isn't really what I'm worried about. I have a technical
> issue.
> 
>> There are at least a few apps that incorporate LLDB into their
>> IDEs, either via the SB API (the LLDB C++-based API), via the GDB
>> Remote protocol, and via the GDB mi protocol (via lldb-mi).  It is
>> definitely possible to go the route of setting up an app that
>> communicates with LLDB to get a REPL experience that way.
>> 
>> I'll be able to comment more directly on questions this upcoming
>> week.
> 
> What I'm more looking for is this. Consider how Emacs uses elisp --
> the application can be extended and altered by the end user at will
> by adding new interpreted elisp code in the field.
> 
> Say I wanted to have a Swift based system that did more or less the
> same thing, that is, which provided users with the ability to extend
> the function of their program by writing Swift code which was loaded
> and interpreted at run time and which interacted seamlessly with the
> Swift code that makes up the body of the application.
> 
> I'm sure that given enough work this could be done, but I'm asking
> if this is something that should be reasonably practical to do with
> the REPL given the current architecture or if it would require an
> unreasonable amount of work.
> 
> Note that I'm not trying to build an IDE. It is rather an application
> where a sophisticated end user may have needs that are difficult for
> the application programmer to fully anticipate.
> 
> (If there is some other way to do this that is more practical, say
> somehow incorporating the compiler at runtime and compiling and
> loading new code into the app, I'd be interested in knowing. However,
> an interpreter seemed like the easier choice.)
> 

Sorry I missed this yesterday.  My normal gmail account is missing from the lists, so my last answer was made without seeing this first.

The Swift REPL works by injecting code into a separate Swift process.  The code is JIT-ed and then run in the separate process by way of LLDB’s highly-specialized code used to control other processes (as one would expect to find in a debugger).  It would be challenging to adapt that code as is to run in the same process (as it sounds like you want, for purposes of app customization along the lines of Python/Maya, elisp/Emacs, etc.)  However, it certainly would act as a template on how to do it.  I don’t think you’d want to try to build the app incorporating LLDB, because LLDB brings with it a whole lot of functionality that is likely not useful unless your app is a debugger.

The places to start looking would be any of the files with *Expression* to get a sense of how our expression engine works.  The Swift specific ones will set up a context to compile, JIT and run code.  The run part is what you would likely need to change, as instead of sending code over to another process, usurping a thread, and sending results back, your code will instead want to arrange to run the newly JIT-ed code in the local process.

I don’t think interpreting will be easier if you plan to base your code on what you find in LLDB.  The JIT is all there, but I don’t think there is any existing interpreter code (Sean - please correct me if I’m wrong here).  Unless that’s incorrect, I think you’d find that you need to write more code to handle interpreting rather than JIT-ing it.

Hope that helps!

-Todd

> Perry
> -- 
> Perry E. Metzger		perry at piermont.com
> _______________________________________________
> swift-lldb-dev mailing list
> swift-lldb-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-lldb-dev