Customized interpreter for executing computer code generated by large language model

Abstract

The present disclosure relates to systems, methods, and non-transitory computer-readable media for generating context engine outputs by utilizing an interpreter specially constructed for executing code generated by a large language model. For example, the disclosed system generates executable computer code for responding to a query by utilizing a large language model. Further, the disclosed system executes model-generated computer code using an interpreter integrated with a context engine, the context engine further including interchangeable logic interchangeable across multiple actuators. Further, the disclosed system may also generate a first context engine output by implementing the interpreter at the first executor as part of executing the computer code with the interpreter. In addition, the disclosed system may also generate a second context engine output by implementing an interpreter at a second actuator.

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit to U.S. Application No. 18 / 482,715, filed October 6, 2023, which is incorporated herein by reference in its entirety. Background Technology

[0003] Advances in computing devices and networking technologies have spurred various innovations in machine learning and computer architecture. For example, native and web-based computing systems have been developed that utilize or implement computer code interpreters to execute computer code and produce results from programs written in computer languages. Some existing interpreters can execute a wide variety of functions and adapt to a variety of functions or programs written in their respective compatible computer languages. However, despite these advances, existing interpreters still suffer from many shortcomings, particularly in terms of security, efficiency, and flexibility.

[0004] As just mentioned, some existing computer code interpreters are insecure. More specifically, some interpreters predefine types when executing a computer program, potentially exposing large amounts of data (including object and function definitions) before any operation that calls the data during execution. Because types are predefined in this way, some interpreters expose type data during initialization and before execution, thus risking the leakage of sensitive data and / or the execution of unsafe operations. Such unsafe operations include disallowed reading, writing, and deletion of content items, as well as various network operations and the creation of new child processes performed by downstream models or systems. Not only does this pre-configured type lead to security problems, but simply performing type checking in advance also introduces stability problems when a computer program calls functions or objects that do not exist in the predefined types (but still pass the initial check), which can lead to crashes and other stability issues.

[0005] Besides their security issues, existing computer code interpreters are also inefficient. More specifically, due to the constant canonicalities of fully predefined types, some existing interpreters consume or use significant computational resources (such as processing power and memory) that could be preserved by more efficient interpreters. For example, existing interpreters often need to compile and recompile code for every new update or change (to types or other parts of code) because, when types have full characteristics at initialization, the interpreter has no way of knowing which changes actually affect functions or objects called in specific code segments of the computer program.

[0006] Existing interpreters suffer further from a lack of flexibility, at least due to their fully defined nature. In fact, as suggested, some existing interpreters are rigidly fixed to predefined types, thus requiring resources to be started for at least some of these defined types that are never even invoked by the computer code during execution. In effect, their inflexible nature prevents many existing interpreters from adapting types as needed, further exacerbating their inefficient use of computational resources. Summary of the Invention

[0007] This disclosure describes embodiments of one or more systems, methods, and non-transitory computer-readable storage media that provide benefits and / or solve one or more of the foregoing and other technical problems. For example, the disclosed systems utilize custom interpreters built specifically for running code generated by neural networks (especially large language models) to execute computer code. In some cases, the disclosed systems utilize a context engine combined with a large language model to generate computer code. For example, the disclosed systems utilize a context engine and a large language model to generate computer code for performing specific operations or programs executed by the interpreter. In particular, the disclosed systems define and implement custom interpreters tailored to code generated from large language models by integrating specific features, including pre-runtime type checking and runtime type checking, interchangeable logic, and state persistence. Attached Figure Description

[0008] With reference to the accompanying drawings, this disclosure will describe one or more exemplary embodiments with additional specificity and detail. The following paragraphs briefly describe these drawings, in which:

[0009] Figure 1 A schematic diagram of an example environment for a custom interpreter system according to one or more embodiments is shown;

[0010] Figure 2 An example overview of a custom interpreter system that utilizes an interpreter to generate context engine output, according to one or more embodiments, is shown;

[0011] Figure 3 Example diagrams illustrating the static and dynamic type checking performed by a custom interpreter system according to one or more embodiments are shown.

[0012] Figure 4 An example diagram is shown of a custom interpreter system that executes computer code using multiple endpoints according to one or more embodiments;

[0013] Figure 5 An example diagram is shown illustrating the state of a custom interpreter system persisting the interpreter according to one or more embodiments;

[0014] Figure 6 An example diagram illustrating the recovery state of a custom interpreter system according to one or more embodiments is shown;

[0015] Figure 7 An example diagram is shown illustrating a custom interpreter system receiving multiple iterative interactions from a client device, according to one or more embodiments.

[0016] Figure 8 Example diagrams are shown illustrating the modification or generation of additional computer code by a custom interpreter system according to one or more embodiments;

[0017] Figure 9 An example diagram is shown illustrating code execution errors generated by a custom interpreter system according to one or more embodiments;

[0018] Figures 10A-10B An example graphical user interface is shown for a custom interpreter system according to one or more embodiments, which receives an input query and generates an output response.

[0019] Figure 11 Example lines executed by a custom interpreter system according to one or more embodiments are shown;

[0020] Figure 12 A block diagram of an example computing device according to one or more embodiments is shown; and

[0021] Figure 13 An example environment of a network system with a custom interpreter system according to one or more embodiments is shown. Detailed Implementation

[0022] This disclosure describes one or more embodiments of a custom interpreter system that can define and implement a custom computer code interpreter specifically built to run or execute computer code generated by a large language model. For example, the custom interpreter system utilizes an interpreter integrated (or communicating) with a context engine and a large language model to execute computer code. In some scenarios, the custom interpreter system receives a query from a client device in the form of a text prompt. The custom interpreter system uses the context engine to process the text prompt to break it down into a set of individual sub-prompts, which are customized or designed for more precise processing by the large language model (and the results are combined to form the target output from the initial prompt / query). Furthermore, the custom interpreter system uses the large language model to generate code segments from the individual sub-prompts. The custom interpreter system then uses the custom interpreter to execute each code segment, generating appropriate output that can be combined using the context engine for use with the target output of the initial prompt / query.

[0023] As described in further detail below, an interpreter includes interchangeable logic that is compatible with and interchangeable between multiple different executors or endpoints. For example, an interpreter can be interchangeable to run (and execute computer code) on different target executors or platforms without recompiling or reconfiguring the body of the interpreter's programming or computer code. Due to its interchangeable nature, the interpreter is more efficient than existing non-interchangeable interpreters, which require reprogramming or recoding all or part of the interpreter architecture and / or the computer code executed by the interpreter for each individual executor.

[0024] In one or more embodiments, the custom interpreter system performs static type checking (e.g., at compile time) before executing the computer code. For example, in some embodiments, the custom interpreter system defines code types (where the definition includes properties and / or functions of type expressions) before runtime. In other words, in some embodiments, the custom interpreter system analyzes the text of a program (e.g., its computer code) to verify or determine its compatibility in its usage context. For example, the custom interpreter system utilizes the static type checking process to verify type safety by examining the syntax, completeness, compatibility, and other coding definition standards of type expressions identified in the computer code (e.g., in code segments corresponding to each sub-hint) as defined by the corresponding programming language.

[0025] In one or more embodiments, the custom interpreter system performs dynamic runtime type checking. For example, during code execution, the custom interpreter system performs dynamic type checking on type expressions encountered by the interpreter as it runs various code segments. In some embodiments, the custom interpreter performs runtime type checking in addition to static type checking to improve stability. In effect, by performing type checking at runtime, the custom interpreter system can identify incomplete expressions, poorly defined expressions, expressions that call types that are not defined at all, and / or expressions that include other syntactic or contextual errors as the interpreter analyzes the lines of code to be executed.

[0026] In one or more embodiments, the custom interpreter system also persists the interpreter's state. For example, the custom interpreter system persists or saves the interpreter state while running computer code (e.g., for later recovery of interrupted computer code). In some embodiments, the interpreter maintains its state for a threshold time period (e.g., five minutes, one hour, five days, etc.). Additionally, in some embodiments, the interpreter invokes previously persisted state to interact with a large language model (e.g., a large language model of a context engine) to recall or regenerate past input. In some embodiments, by persisting the state, the custom interpreter system facilitates the on-the-fly generation of new code, where the state of the code can be saved until a certain point, and new code can be generated and added to that point (or the new code can completely replace the saved code). Furthermore, in some embodiments, the interpreter utilizes a multi-round function as a result of persisting the state, where the user can ask multiple subsequent questions one after another, and the interpreter remembers previous answers and provides further details in each round. To persist the state, in some embodiments, the custom interpreter system saves or stores memory registry data, call stacks, and / or instruction pointers indicating which line or part of a function is being executed at the time of saving.

[0027] Furthermore, in one or more embodiments, the custom interpreter system also performs in-function garbage collection while the interpreter is running the code. Specifically, in-function garbage collection helps the interpreter efficiently free up memory in the middle of a function.

[0028] As described above, custom interpreter systems can offer several improvements or advantages over existing interpreters. For example, custom interpreter systems can provide improved security compared to many existing interpreters. While some interpreters predefine types and expose potentially large amounts of data, open-source interpreters can run computer code in a way that dynamically exposes types. For instance, in some instances, custom interpreters use layer wrappers to abstract encoded expressions and dynamically expose types during execution, thereby improving security by exposing type data only when the type is called in their respective expressions or functions. Moreover, in some embodiments, dynamic exposure of types further improves stability by preventing crashes caused by unknown types due to processor calls to types or functions that do not exist.

[0029] Furthermore, in some embodiments, the exposed interpreter integrates explicitly defined types to enhance security. For illustration, in some instances, explicitly defined types cause the interpreter to run only computer code containing explicitly defined types and avoid running code that includes expressions not found in the explicit type definitions. By doing so, the custom interpreter system avoids running code that violates security or privacy protocols (e.g., by preventing large language models from generating computer code based on type data that exceeds the explicit encoding used for such purposes). In some cases, the exposed interpreter exposes type data only in the corresponding expression or code segment that calls the type, stores the type data in memory during expression execution, and then removes or overwrites the type data as execution continues to subsequent expressions (unlike previous interpreters, which stored type numbers long-term when types were defined outside of wrapper expressions).

[0030] In addition to improving the security of conventional interpreters, custom interpreter systems also improve efficiency in some embodiments. Unlike conventional interpreters, which typically require types to be fully defined in advance, custom interpreter systems implement dynamic type exposure in some embodiments. For example, as described above, in some embodiments, dynamic type exposure helps the interpreter expose the types that are called only at runtime. In other words, dynamically exposing types helps the custom interpreter system avoid confusing the circuitry and avoid calling types that are not intended to be called. Therefore, in some embodiments, custom interpreter systems leverage interpreters with dynamic type exposure to improve the efficiency of running computer code by reducing resource requirements and eliminating the need to pre-store and process everything. Furthermore, the exposed interpreter includes interchangeable logic that preserves or avoids the computational overhead of reconfiguring the interpreter for use by different executors. Additionally, the interpreter utilizes both static and dynamic type checking to improve stability and prevent recompiling code for every new update or change (which may or may not affect parts of the code), thereby saving additional computational resources.

[0031] Custom interpreter systems also improve operational flexibility, at least in part due to enhanced security and efficiency. While conventional interpreters are strictly fixed to predefined types and consume resources of certain defined types that are never invoked by the computer code during execution, in some embodiments, custom interpreter systems leverage dynamic type exposure by only running computer code with explicitly defined types and exposing the types only when the computer code invokes them. Thus, custom interpreter systems improve operational flexibility by adapting types in real-time (on the fly) as they process the computer code.

[0032] As discussed above, this disclosure utilizes various terms to describe the characteristics and advantages of a custom interpreter system. Further details regarding the meaning of these terms as used herein are provided below. As used herein, the term "query" includes or refers to a request for data or a specific model output in the form of input, to search for information within the system and / or to generate information using a large language model. Specifically, queries include text queries, which can range from single-order text queries to multi-order text queries. For example, a query such as "Who did I spend the most time with this month?" can be broken down into multiple sub-components (and is therefore a multi-order text query). To illustrate, the example mentioned above includes (i) a sub-component to determine the details of the user who made the query, (ii) a sub-component to determine all meetings the user attended in the past month, (iii) a sub-component to determine all participants in each meeting in the past month, and (iv) other sub-components to determine combinations of the aforementioned sub-components (e.g., aggregating the results of the first few components and selecting those matching the text query). Moreover, in some instances, the custom interpreter system extracts data from the query or prompt. Specifically, the custom interpreter system 102 can extract natural language structured procedural data from the query or prompt. Therefore, in some instances, custom interpreter systems generate computer code in response to extracting structured, procedural data of natural language from queries (e.g., by using a context engine to interact with a large language model).

[0033] As described above, custom interpreter systems utilize context engines. As used herein, the term "context engine" includes or refers to a model (e.g., a machine learning model) that collaborates with a large language model to decompose a text query into individual prompts and generate computer code from the prompts. For example, a context engine determines the order of text queries and decomposes the query into a set of first-order prompts. A context engine can also combine the outputs generated by each first-order prompt into a context engine output in response to the initial query. For illustration, custom interpreter systems utilize context engines (e.g., context engines) such as the one described by Rajkumar Janakiraman in U.S. Patent Application No. 18 / 309,496 entitled "GENERATING MULTI-ORDER TEXT QUERY RESULTSUTILIZING A CONTEXT ORCHESTRATION ENGINE," which is hereby incorporated herein by reference in its entirety.

[0034] Furthermore, in some embodiments, the custom interpreter system further executes computer code at an executor. As used herein, the term "executor" includes a runtime engine that executes computer code on a target platform. For example, an executor can refer to a program or application that includes executing computer code on behalf of an interpreter at a particular endpoint. For instance, the custom interpreter system implements the interpreter via an executor to execute computer code in a particular web browser, device, or operating system (e.g., the executor may execute computer code at a client device that sends text queries to the custom interpreter system).

[0035] As described above, custom interpreter systems utilize interpreters that integrate explicitly defined types. For example, in computer programming (e.g., object-oriented programming), a "type" includes (in programming languages) a set of values, operations, or a description of building blocks used to organize and model data in a software system. Specifically, a defined type can include coded expressions that define the structure and behavior of objects of a particular type. For example, a type can include attributes of coded expressions (e.g., for file system operation types, attributes could include file location, file type, etc.) and functions (e.g., reading a file, writing to a file, or deleting a file).

[0036] As described above, a custom interpreter system generates context engine output. As used herein, the term "context engine output" includes output generated by leveraging the context engine to determine (and combine) data produced by an interpreter executing code generated from a large language model. For example, in some embodiments, context engine output includes functions or operations performed by the large language model, such as accessing emails from an email application, retrieving all calendar events for a specific week, sending messages, retrieving files from a content management system, booking flights, booking hotels, booking carpooling, and other actions performed by the application.

[0037] As described above, the context engine includes or refers to a machine learning model. In one or more embodiments, a "machine learning model" includes a computer algorithm or a collection of computer algorithms that can be trained and / or fine-tuned based on input to approximate an unknown function. For example, a machine learning model may include a computer algorithm with branches, weights, or parameters that change based on training data to improve performance for a specific task. Thus, a machine learning model can leverage one or more learning techniques to improve accuracy and / or effectiveness. Example machine learning models include various types of decision trees, support vector machines, Bayesian networks, random forest models, or neural networks (e.g., deep neural networks).

[0038] Similarly, a "neural network" includes a machine learning model composed of interconnected artificial neurons (e.g., organized in layers) that communicate and learn to approximate complex functions and generate outputs based on multiple inputs provided to the model. In some cases, a neural network includes algorithms (or a set of algorithms) that implement deep learning techniques, which utilize a set of algorithms to model high-level abstractions in data. For illustration, in some embodiments, a neural network includes a convolutional neural network, a recurrent neural network (e.g., a long short-term memory neural network), a transformer neural network, a generative adversarial neural network, a graph neural network, a diffuse neural network, or a multilayer perceptron. In some embodiments, a neural network includes a neural network or a combination of neural network components.

[0039] Along these lines, custom interpreter systems leverage context engines to interact with large language models. The term "large language model" as used in this paper includes or refers to one or more neural networks capable of processing natural language text to generate a range of outputs from combinations of data within content items, whether predictive, analytical, or stored. Specifically, a large language model can include parameters trained on large amounts of data (e.g., through deep learning) to learn language patterns and rules for summarizing and / or generating digital content. Examples of large language models include BLOOM, Bard AI, ChatGPT, LaMDA, DialoGPT, DropboxGPT, and Dropbox FileGPT.

[0040] As described above, the custom interpreter system 102 utilizes an interpreter to run computer code generated from a large language model. As used herein, the term "interpreter" includes or refers to software or applications that read and execute computer code (e.g., source code) written in a high-level programming language. For example, an interpreter may read computer code line by line, statement by statement, or instruction by instruction and may execute the code without converting it to machine code. In some cases, the interpreter may also, or alternatively, translate the computer code into machine code or other representations. Furthermore, in some cases, the interpreter does not use a separate compilation step when running the computer code.

[0041] Additional details regarding the custom interpreter system will now be provided with reference to the accompanying drawings. For example, Figure 1 A schematic diagram of an example system environment for implementing a custom interpreter system 102, according to one or more embodiments, is shown. About Figure 1 An overview of the custom interpreter system 102 is described. A more detailed description of the components and processes of the custom interpreter system 102 is then provided with reference to the following figures.

[0042] As shown, the environment includes multiple servers 104 with a custom interpreter system 102, a database 114, multiple servers 116, and client devices 108. The custom interpreter system 102 includes a context engine 105, which further includes an interpreter 103 and a context data source 107. Each component of the environment can communicate via a network 112, and the network 112 can be any suitable network that allows computing devices to communicate. The following is in conjunction with... Figure 12-13 The example network will be discussed in more detail.

[0043] As described above, the example environment includes client device 108. Client device 108 can be one of a series of computing devices, including smartphones, tablets, smart TVs, desktop computers, laptops, virtual reality devices, augmented reality devices, or a combination thereof. Figure 12-13 Another computing device described. Client device 108 can communicate with server 104 via network 112. For example, client device 108 can receive user input from a user interacting with client device 108 (e.g., via client application 110) to, for example, access, generate, modify, or share context engine output, or select user interface elements for interacting with content management system 106 (e.g., to indicate context data source 107 or interaction definition text query). Furthermore, a custom interpreter system 102 located on server 104 can receive information related to various interactions with content items and / or user interface elements based on the input received by client device 108.

[0044] As shown, client device 108 may include client application 110. Specifically, client application 110 may be a web application, a native application (e.g., a mobile application, desktop application, etc.) installed on client device 108, or a cloud application, wherein all or some of its functions are executed by server 104. Based on instructions from client application 110, client device 108 may present or display information, including a user interface for interacting (or collaborating) with the output of the generated context engine. Using the client application, client device 108 may perform (or request to perform) various operations, such as instructing the context data source and / or generating context engine output for text queries.

[0045] like Figure 1As shown, the example environment also includes servers (multiple) 104. Servers 104 can generate, track, store, process, receive, and transmit electronic data, such as text queries, context engine output, query component-specific computer code, interactions with interface elements, and / or interactions between user accounts or client devices. For example, server 104 can receive instructions from client device 108 instructing user interactions that define a text query. Furthermore, server 104 can send data to client device 108 as context engine output for a text query. In practice, server 104 can communicate with client device 108 to send and / or receive data via network 112. In some embodiments, server 104 includes a distributed server, comprising a series of server devices distributed across network 112 and located in different physical locations. Server 104 may include one or more content servers, application servers, container coordination servers, communication servers, web hosting servers, machine learning servers, and other types of servers.

[0046] like Figure 1 As shown, server 104 may also include a custom interpreter system 102 as part of content management system 106. Content management system 106 can communicate with client device 108 to perform various functions associated with client application 110, such as managing user accounts, defining text queries, and / or specifying contextual data sources. In practice, content management system 106 may include a web-based intelligent cloud storage system to manage and maintain content items and related data across numerous user accounts. In some embodiments, custom interpreter system 102 and / or content management system 106 utilize database 114 to store and access information such as content items, contextual data sources, text queries, results for text queries, responses to text queries, and other information related to maintaining the state of interpreter 103.

[0047] As further illustrated, the environment includes multiple servers 116 hosting a large language model 118. Specifically, the large language model 118 communicates with server 104, client devices 108, and / or database 114. For example, a custom interpreter system 102 provides domain-specific language segments to the large language model 118, where the domain-specific language segments indicate contextual data sources used to generate results for various query subcomponents. In practice, the large language model 118 may include machine learning models driven by neural networks or other machine learning architectures for generating responses to text queries. For example, the large language model 118 may refer to the ChatGPT model, which generates computer-executable code segments for accessing contextual data sources to generate responses to query subcomponents.

[0048] although Figure 1 A custom interpreter system 102 located on server 104 is shown, but in some embodiments, the custom interpreter system 102 may be implemented by one or more other components of the environment (e.g., wholly or partially located). For example, the custom interpreter system 102 may be implemented by client device 108 and / or a third-party system. For example, client device 108 and / or a third-party system may download all or part of the custom interpreter system 102 to implement it independently of or in conjunction with server 104.

[0049] In some embodiments, although not in Figure 1 As shown, however, the environment can have a different component arrangement and / or can have a completely different number or group of components in total. For example, client device 108 can communicate directly with custom interpreter system 102, thereby bypassing network 112. The environment may also include one or more third-party systems, each corresponding to a different context data source of context data source 107. Furthermore, the environment may include a database 114 located outside server 104 (e.g., communicating via network 112) or located on server 104 and / or client device 108. In some cases, server 104 and / or client device 108 may host or accommodate all or part of a large language model 118.

[0050] As described above, the custom interpreter system 102 uses an interpreter integrated with a context engine to run computer code. Figure 2 An overview of a custom interpreter system 102, which generates context engine output using an interpreter based on a received text query according to one or more embodiments, is shown.

[0051] For example, Figure 2 A custom interpreter system 102 is shown receiving a text query 202 via a context engine 200. Specifically, the custom interpreter system 102 receives the text query 202 from a client device (e.g., via an interface for interacting with a large language model 204). As shown, Figure 2 The text query 202 in the example is read as "Who will I meet with next week, and what do I need to do?". As mentioned above, text query 202 can range from a single sequential text query to multiple sequential text queries. Here, Figure 2 The text query 202 shown indicates a multi-sequential text query with (i) calendar data for the next week's meetings, (ii) other people who will attend the meetings next week, and (iii) sub-components related to tasks associated with each meeting.

[0052] also, Figure 2The diagram illustrates the interaction between the context engine 200 and the large language model 204 to generate computer code 206. Specifically, the context engine 200 receives a text query 202 and, in response, generates computer code 206 from the text query 202. Moreover, in some embodiments, the custom interpreter system 102 utilizes the context engine 200 and the large language model 204 to generate computer code 206 corresponding to different sub-components of the text query 202.

[0053] To illustrate the generation of computer code 206 in detail, in some cases, the custom interpreter system 102 decomposes the text query 202 into the individual sub-components (i), (ii), and (iii) described above. For example, as described in U.S. Patent Application No. 18 / 309,496 (incorporated above), the custom interpreter system 102 utilizes the context engine 200 to determine how to divide the text query 202 into sub-components (or low-level text queries) to be provided to the large language model 204. In practice, the custom interpreter system 102 provides the large language model 204 with the different sub-components of the text query 202 (e.g., (i), (ii), and (iii) above). The large language model 204, in turn, processes the constituent queries / hints of the sub-components to generate computer code segments corresponding to the respective sub-components. In some cases, the context engine 200 combines the individual code segments into a single code segment corresponding to the text query 202 (from which the sub-component queries are extracted).

[0054] As mentioned, the custom interpreter system 102 utilizes the context engine 200 and the large language model 204 to generate computer code 206. In some embodiments, the computer code 206 includes a set of instructions written in a programming language that a computing device can interpret and execute to perform a specific task. Specifically, the computer code 206 includes a series of statements and functions that perform specific operations. Furthermore, the computer code 206 includes statements written in a specific syntax that can be translated into machine code for execution by a computing device. Therefore, the custom interpreter system 102 generates computer code 206 for a specific query from a sub-component of the text query 202 or as a combination of sub-components provided to the large language model 204. In some cases, the computer code 206 corresponds to a contextual data source of the text query 202 (e.g., email application, browser history, messaging application, calendar, file history, file content, etc.). For example, the custom interpreter system 102 generates computer code 206 specific to each contextual data source and is executable for each sub-component in response to the text query 202.

[0055] For example, a contextual data source refers to the location or system containing the data. Specifically, contextual data sources include databases, spreadsheets, documents, websites, browsers, social networking platforms, and other sources of structured and unstructured data. For instance, contextual data sources include structured and unstructured data that supports various applications used on computing devices. Therefore, contextual data sources can include internal or external data at the organization, individual, or application level.

[0056] like Figure 2 As shown, computer code 206 is represented by pseudocode indicating a function that uses an Application Programming Interface (API) call to retrieve data from a calendar application and uses the data from the calendar application as input data. Furthermore, Figure 2 A custom interpreter system 102 is shown passing computer code 206 from a large language model 204 (and / or context engine 200) to an interpreter 208. For example, Figure 2 Different code segments of computer code 206 within interpreter 208 are shown. In some cases, individual code segments correspond to respective sub-components split from text query 202 (e.g., where code segments for each sub-component are generated by a large language model 204 and passed to interpreter 208). In some embodiments, code segments represent different parts of computer code designated to be executed at different executors or endpoints. In fact, as shown, interpreter 208 passes different code segments to multiple executors. Specifically, Figure 2 The custom interpreter system 102 is shown using interpreter 208 to pass a code segment to a first executor 210, another code segment to a second executor 212, and another code segment to a third executor 214.

[0057] like Figure 2 As further shown, the first executor 210 generates a first context engine output 216, the second executor 212 generates a second context engine output 218, and the third executor 214 generates a third context engine output 220. For example, Figure 2 The illustration shows first executors 210 through third executors 214 executing code segments that, in some embodiments, include separate program segments corresponding to each code segment. In some cases, the code segments constitute a single program rather than multiple programs. Furthermore, in some embodiments, Figure 2 Each context engine output shown is the result of executing the code segment at the corresponding executor.

[0058] As described above, the custom interpreter system 102 utilizes the interpreter to perform both static type checking and dynamic type checking. Figure 3 Additional details are shown regarding static and dynamic checks of the custom interpreter system 102 according to one or more embodiments. For example, Figure 3An executor 300 is shown, which executes computer code generated by a context engine that interacts with a large language model (as described above).

[0059] As described above, in some embodiments, the custom interpreter system 102 requires explicit definitions of the types of the code executed by the interpreter 300. For example, the custom interpreter system 102 utilizes the interpreter 300 to perform type checking statically before runtime and dynamically at runtime. For example, type checking includes processes that verify that the data type or class of variables or code expressions conforms to types explicitly defined within the interpreter 300. Furthermore, type checking helps ensure that variables, expressions, and operations are used consistently and correctly for their data types.

[0060] In one or more embodiments, the custom interpreter system 102 performs type checking to prevent errors and / or to prevent violations of security or privacy protocols. Specifically, static type checking 304 and / or dynamic type checking 306 prevent security issues associated with runtime languages ​​that use full features (e.g., allowing large language models to execute uncensored computer code). For example, in some embodiments, static type checking 304 and / or dynamic type checking 306 prevent unwanted file system operations, such as reading, writing, or deleting data stored for user accounts. In some cases, an interpreter with full functionality upfront can perform such file system operations, which could compromise data security if these operations are unwanted, unauthorized, or not explicitly coded—for example, in cases where a large language model communicates with the interpreter to execute code and perform certain functions, this puts the large language model at risk of accessing all data and functions of fully defined types as part of performing additional operations. Conversely, interpreter 300 utilizes two-layer type checking (and dynamic exposure of type data) to prevent downstream systems or models (e.g., large language models) from instantiating instances of their own file system operations that would otherwise compromise file system data by moving, deleting, renaming, or otherwise altering data not intended for access by the model (and not exposed by interpreter 300). Along these lines, the custom interpreter system 102 also prevents unwanted network operations involving the disclosure of information related to network surveillance (e.g., Internet Protocol), security protocols (e.g., firewalls, security patches, etc.), and connectivity (e.g., uploading and downloading data packets).

[0061] Furthermore, in some embodiments, static type checking 304 and / or dynamic type checking 306 (and / or dynamic type exposure) prevent the disclosure of information related to contextual data. For example, contextual data includes operating system (OS) information, web browser information (e.g., data indicating the browser type), or application information (used by the device) (where the code running the program runs) and / or CPU data. Moreover, in some embodiments, static type checking 304 and / or dynamic type checking 306 also prevent downstream systems or models (e.g., large language models) from creating unwanted child processes. In fact, for reasons similar to those discussed above regarding preventing file system operations, the custom interpreter system 102 can prevent large language models from creating unauthorized child processes that are not explicitly defined as part of the executed computer code. For example, child processes include those created to perform tasks other than the computer code or tasks separate from the computer code.

[0062] As described above, the custom interpreter system 102 performs static type checking 304 before runtime. In some embodiments, static type checking 304 prevents the interpreter 300 from accessing data outside of explicitly defined types (e.g., only those explicitly defined types can be executed by the interpreter). For example, static type checking 304 involves checking the syntax of type expressions in computer code, including object definitions, function definitions, and / or other expressions, to identify errors. Static type checking 304 may also involve determining available computing resources and / or determining the computing environment used to execute the defined type. As part of static type checking 304, the custom interpreter system 102 may determine whether the defined type is compatible with a particular executor (e.g., the executor that will execute the code that defines and / or calls that type). As shown, static type checking 304 includes indicating that function A in the computer code conforms to the explicitly defined type of the code executed by the interpreter 300. Static type checking 304 also indicates that function B does not conform to the explicitly defined type of the interpreter 300—for example, it is a function that is not within the defined type of the computer code. For example, if the type within the code refers to a call to an email application that is incompatible with a defined type, static type check 304 identifies the function as invalid (e.g., interpreter 300 does not run computer code containing types not defined within interpreter 300). Furthermore, in some cases, static type check 304 includes customizing the interpreter system 102 to determine that the computer code run by interpreter 300 conforms to the syntax rules of the programming language and other predefined logical standards.

[0063] Furthermore, in some embodiments, the custom interpreter system 102 performs a second type checking process on the computer code at runtime. In some cases, runtime dynamic type checking 306 also prevents the interpreter 300 from accessing data other than explicitly defined types. For example, dynamic type checking 306 involves checking the syntax of type expressions in the computer code, including object definitions, function definitions, and / or other expressions, to identify errors. Dynamic type checking 306 may also involve determining available computing resources and / or determining the computing environment used to execute the defined types. In some cases, dynamic type checking 306 involves cross-checking the types with their definitions as determined by static type checking 304 when they are executed. As part of dynamic type checking 306, the custom interpreter system 102 may determine whether the defined types are compatible with a specific executor that executes code that calls that type and / or prevents the processor from calling undefined types. If dynamic type checking 306 indicates that the type is incompatible with the executor (or fails dynamic syntax checking or dynamic resource checking), the custom interpreter system 102 terminates the execution of that portion of the code and continues execution of other code. As shown, interpreter 300 is executing the current function 302, and custom interpreter system 102 performs dynamic type checking 306 during execution to analyze the lines of code being interpreted or executed.

[0064] In some embodiments, the custom interpreter system 102 dynamically exposes types defined within the code executed by the interpreter 300. For example, as the interpreter 300 runs the computer code line by line, the custom interpreter system 102 exposes defined types only if the computer code indicates that a type is defined. Thus, unlike interpreters that explicitly and fully define types at the beginning of a computer code segment, the interpreter 300 wraps type definitions within the code, allowing the properties and functions of the types to be dynamically exposed at runtime (e.g., when processing lines of code to be executed). By dynamically exposing types defined within the interpreter, the custom interpreter system 102 prevents type data (e.g., properties and / or functions) from being accidentally exposed to executors or other applications executing programs defined by the computer code (and / or to downstream models, such as large language models that use the output generated by the code for further analysis or prediction). Therefore, dynamic exposure of types helps control data flow, data security, and data propagation across network systems, particularly in networks that include large language models that might otherwise ingest data and / or execute functions not designed for their use / performance.

[0065] To illustrate, the dynamic exposure of types is caused by layer wrappers. As mentioned, a regular interpreter explicitly and fully defines types at the beginning of a computer code segment, while interpreter 300 wraps type definitions into the code. In other words, the custom interpreter system 102 causes interpreter 300 to wrap definitions or expressions when it is called by computer code. For example, for computer code containing five functions, interpreter 300 does not predefine types for all five functions and then execute the computer code for those functions. Instead, the custom interpreter system 102 uses interpreter 300 to run the computer code, and while the first function is running, interpreter 300 calls the explicitly defined functions wrapped within the first function. Furthermore, after the first function has finished running, the custom interpreter system 102 uses interpreter 300 to call explicitly defined functions indicated by a second function, etc. (overwriting the type data for each function in memory).

[0066] In practice, as mentioned, in one or more embodiments, the custom interpreter system 102 utilizes interpreter 300 to prevent downstream models from performing certain tasks. For example, in some cases, the custom interpreter system 102 configures interpreter 300 (e.g., by explicitly defining type attributes and functions) to prevent large language models from executing additional functions and / or accessing additional data that is not part of an explicitly defined type. In some cases, the custom interpreter system 102 prevents the execution of computer code that would activate downstream models to perform unwanted operations (e.g., deleting certain files, reading certain files, writing files, accessing private account information, accessing computing environment state, or executing other subprocesses that violate privacy standards).

[0067] For example, the custom interpreter system 102 utilizes the interpreter 300 to run code that subsequently utilizes a downstream model (e.g., a large language model) to perform certain operations. Therefore, in this case, the custom interpreter system 102 prevents the downstream model from performing unwanted tasks. To illustrate, in the case where a malicious attacker controls a large language model, the interpreter prevents the execution of malicious computer code that could access private or security information or perform unwanted operations.

[0068] Furthermore, in one or more embodiments, the custom interpreter system 102 utilizes interpreter 300 to prevent large language models from generating computer code that analyzes or utilizes type data from computer code, which could potentially violate security or privacy protocols. Typically, large language models can utilize various techniques to generate a wide range of outputs in response to input data, as these models independently decide which processes and data to use in response to prompts. To prevent large language models from having unrestricted access to type data, in some embodiments, the custom interpreter system 102 implements explicit type definitions and dynamic type exposure.

[0069] As previously mentioned, the custom interpreter system 102 can use multiple executors to execute the interpreter's computer code segments. For example, because the interpreter of the custom interpreter system 102 utilizes (or is composed of) interchangeable logic, the custom interpreter system 102 can execute computer code interchangeably at different executors without retooling the interpreter or recoding the code. Figure 4 More details are shown regarding interpreters that use multiple executors (e.g., endpoints). Specifically, Figure 4 The illustration shows, according to one or more embodiments, an interpreter passing multiple code segments of computer code to multiple executors.

[0070] In some embodiments, the custom interpreter system 102 utilizes the interpreter 400 to run computer code in a host environment (e.g., the runtime environment of the computing device implementing the interpreter 400). Furthermore, in some embodiments, the custom interpreter system 102 utilizes different executors to run different segments of the computer code from the interpreter 400 (and / or run the entire computer code). As described above, in some embodiments, the interpreter 400 includes interchangeable logic that is interchangeable between multiple executors. Specifically, the logic or programming of the interpreter 400 is interchangeable because it is cross-compatible with running the same interpreter 400 to execute the same (or different) computer code at different endpoints or executors. For example, the interpreter 400 can run the same computer code at a verification executor and an implementation executor. In some cases, different executors correspond to various target platforms (e.g., mobile devices, browsers, applications, etc.).

[0071] like Figure 4 As shown, interpreter 400 passes a first code segment 402 to a first executor 410 (test executor), a second code segment 404 to a second executor 412 (verification executor), a third code segment 406 to a third executor 414 (production executor), and a fourth code segment 408 to a fourth executor 416 (temporary executor). In practice, interpreter 400 can run at each different executor to execute different code segments (or the same code segments). Furthermore, in one or more embodiments, the custom interpreter system 102 utilizes the interpreter to execute computer code at different endpoints without additional reconfiguration. In other words, interpreter 400 is interchangeable to execute computer code at different endpoints without reconfiguring the interpreter for each different endpoint for compatibility.

[0072] For example, a test executor may include a process of executing computer code in an environment to identify errors or defects in the computer code, while a verification endpoint may include an environment to determine whether the computer code achieves its intended purpose. Furthermore, a production endpoint may include an environment for executing computer code to understand the end-user experience, and a deployment endpoint may include a demonstration environment for further testing of the computer code.

[0073] Furthermore, despite Figure 4 Not shown, but in some embodiments, the custom interpreter system 102 utilizes interpreter 400 to pass each code segment (e.g., first code segment 402 through fourth code segment 408) to the first executor 410. For example, the custom interpreter system 102 utilizes interpreter 400 to pass computer code (with all code segments) to each endpoint so that the entire computer code can be executed at each endpoint. In one or more embodiments, interpreter 400 translates source code into machine code or another intermediate representation. As described above, in some embodiments, because interpreter 400 directly reads and executes the computer code, the custom interpreter system 102 does not require a separate compilation step. For example, in some embodiments, the custom interpreter system 102 utilizes interpreter 400 to run the computer code line by line and convert the computer code into an abstract syntax tree (e.g., a hierarchical data structure representing the syntactic structure of the computer code).

[0074] In some embodiments, the interpreter system 102 is customized to parse, analyze, and execute computer code, starting with an abstract syntax tree. For example, the abstract syntax tree represents an intermediate representation of the computer code (e.g., the syntactic structure of the computer code) and guides the interpreter 400 to execute the computer code accurately.

[0075] Furthermore, in some embodiments, the custom interpreter system 102 performs in-function garbage collection. Specifically, garbage collection includes reclaiming memory that is no longer needed by the computer code. For example, garbage collection includes identifying objects in the computer code that are no longer referenced by the computer code and freeing these objects from memory to release memory allocations. In some embodiments, the custom interpreter system 102 utilizes in-function garbage collection to remove or free stored code for a specific function (or different functions), even while the same function is being executed. In many conventional interpreters, garbage collection is performed after function execution and / or after the entire code segment or program has been completed. In practice, many interpreters fail to perform in-function garbage collection, which includes updating memory as the interpreter 400 runs functions of the computer code. For example, the custom interpreter system 102 updates reference counts and removes objects that are no longer referenced as the interpreter 400 executes functions.

[0076] As described above, the custom interpreter system 102 enables the interpreter's state to be persisted. Figure 5 An example diagram is shown illustrating how a custom interpreter system 102 persists the state of an interpreter according to one or more embodiments. For example, in some embodiments, the custom interpreter system 102 persists the state of interpreter 502 while running computer code. Specifically, the custom interpreter system 102 persists the state of interpreter 502 for a threshold time. In some embodiments of such embodiments, the custom interpreter system 102's persistence of the state of interpreter 502 allows interpreter 502 to recall previous states used when interacting with large language models to remember or regenerate past inputs.

[0077] Furthermore, in some embodiments of such implementations, state persistence also facilitates the on-the-fly generation of new code, wherein the custom interpreter system 102 saves the state of the code, and new or modified code is added to the saved code (e.g., code generated by a large language model). Additionally, in some embodiments, state persistence enables the custom interpreter system 102 to provide multi-turn functionality (e.g., a user can ask multiple follow-up questions one after another, and the interpreter remembers previous answers and provides further details in each turn).

[0078] For example, Figure 5 An interpreter 502 running computer code and memory registry data 504 are illustrated. Specifically, memory registry data 504 includes data currently located within the interpreter 502 at the time of persisting the state. For example, memory registry data 504 includes objects, attributes, or other types of data (or other processing data) of computer code located in memory at the time of persisting the state. In some embodiments, persisting the state involves saving or storing specific data that defines the interpreter's state. Such data includes memory registry data, call stacks, and / or instruction pointers.

[0079] Following these lines of thought, Figure 5 A call stack 506 corresponding to the interpreter 502 running computer code is also shown. Specifically, the call stack 506 includes the position of the interpreter 502 within the current scope of the computer code. Specifically, the call stack 506 includes methods for managing function calls and the execution of the corresponding context for each function call. For example, the call stack 506 tracks the execution order of functions in the computer code (because calls are “stacked” in the call stack 506) and maintains information about each function. In some embodiments, the call stack 506 operates on a last-in-first-out (LIFO) basis. Therefore, the call stack 506 supervises the higher-level functions run by the interpreter 502.

[0080] in addition, Figure 5Instruction pointer 508 is shown corresponding to interpreter 502 running computer code. For example, custom interpreter system 102 uses instruction pointer 508 to track the address (e.g., a specific reference point) of the next instruction to be executed. Specifically, instruction pointer 508 includes an indication of the memory location of the next machine-level instruction to be executed (or the currently executing instruction). Compared to call stack 506, instruction pointer 508 oversees the low-level execution of machine instructions within the computer code. As shown, instruction pointer 508 indicates a specific line of code enclosed in bold square brackets as the current (or next) instruction to be processed or executed.

[0081] like Figure 5 As shown, the custom interpreter system 102 stores in-memory registry data 504, a call stack 506, and an instruction pointer 508 in a database 510. In some embodiments, the interpreter 502 operates within a computing device 500. For example, in some embodiments, the computing device 500 includes a database 510, while... Figure 5 In other embodiments shown, database 510 operates independently of computing device 500. Therefore, in some embodiments, custom interpreter system 102 stores in-memory registry data 504, call stack 506, and instruction pointer 508 in database 510 to persist the state of interpreter 502. Thus, custom interpreter system 102 can save or persist the interpreter state at any instance or moment of code execution for recall in subsequent operations.

[0082] In one or more embodiments, the custom interpreter system 102 persists the state of interpreter 502 for a single session. For example, a single session may include the time from when a user on a client device opens the application to send a text query to when the user on the client device closes the application. Furthermore, in some embodiments, the custom interpreter system 102 persists the state of interpreter 502 for a set period of time (e.g., a day, an hour, or a few minutes).

[0083] In one or more embodiments, the custom interpreter system 102 saves, persists, stores, or maintains multiple states of interpreter 502 over a threshold time period (e.g., hour, day, week, or month). For example, the custom interpreter system 102 saves states in database 510, and when a text query contains a word or phrase that calls back to a previous state of interpreter 502, the custom interpreter system 102 can revert to that previous state. For illustration, the custom interpreter system 102 may combine saved states (e.g., from previous conversations between the client device and the custom interpreter system 102) to generate a more relevant response.

[0084] As described above, as a result of persisting the interpreter state, the custom interpreter system 102 can recall and restore previous interpreter states. For example, the custom interpreter system 102 can receive text queries from client devices to elaborate or build upon previous states saved by the interpreter, and the custom interpreter system 102 can recall that state and continue generating output using the large language model and / or context engine to build upon the saved state (instead of starting from scratch as required by some interpreters that interact with large language models). Figure 6 An example is shown of a custom interpreter system 102 according to one or more embodiments, which persists the state of the interpreter and then restores the persisted state.

[0085] like Figure 6 As shown, the custom interpreter system 102 resumes the execution of computer code corresponding to the persistent state by recalling data stored as persistent state. For example, the custom interpreter system 102 obtains memory registry data, call stack, and instruction pointers from a database, indicating the location within the computer code segment to resume execution, and also includes necessary data for the resumption. Furthermore, the custom interpreter system 102 resumes the execution of the computer code at the segment indicated by the memory registry data, call stack, and instruction pointer.

[0086] Figure 6 Two paths are shown (represented by circled numbers 1 and 2, respectively). The first path illustrates how the custom interpreter system 102 generates output for a first text query, and the second path illustrates how the custom interpreter system 102 generates output for a second text query that interrupts or disrupts the processing of interpreter 604 when executing the computer code used for the first path. Figure 6 As shown, the custom interpreter system 102 receives a text query 600 that reads "Generate a summary of my meetings that happened today". Furthermore, based on the text query 600, the custom interpreter system 102 generates (e.g., via a content engine and a large language model) computer code 602 to generate output for the text query 600. The custom interpreter system 102 also utilizes an interpreter 604 to execute or run the computer code 602.

[0087] As shown, in some embodiments, the custom interpreter system 102 also maintains the state A606 of the interpreter 604. For example, the interpreter 604 receives computer code 602 to generate a summary of meetings that occurred that day, and the interpreter 604 runs the computer code 602 until all such meetings have been summarized. Therefore, in some cases, depending on the code of the text query, executing the computer code for a single text query may take hours, days, or weeks (or other durations). In some embodiments of such embodiments, as described above regarding Figure 5As stated, during the execution of computer code 602 (but before completion), the custom interpreter system 102 maintains state A 606.

[0088] In one or more embodiments, the custom interpreter system 102 includes various instances of the interpreter 604 at different server computing devices. For example, the custom interpreter system 102 uses a first instance of the interpreter 604 to process... Figure 6 The first path shown (indicated by the circled 1) is processed by the second instance of interpreter 604. Figure 6 The second path shown (indicated by circled 2) (e.g., the custom interpreter system 102 maintains different states of interpreter 604 depending on the interpreters running on different server devices).

[0089] As further shown, the custom interpreter system 102 also receives an additional text query 610, which reads “What content item do I have about dogs?”. In this case, the additional text query 610 is completely different from the text query 600 and requires different computer code to generate a response (e.g., determined by the context engine and generated by a large language model). In response to such interrupted queries, the custom interpreter system 102 saves or persists state A 606 (and / or periodically persists state). Furthermore, as shown, based on the additional text query 610, the custom interpreter system 102 generates additional computer code 612 and provides the additional computer code 612 to the interpreter 604. Figure 6 As shown, the second path includes state B 607 of interpreter 604, which in some instances indicates a second instance of interpreter 604 as mentioned above. Furthermore, in some embodiments, interpreter 604 executes additional computer code 612 in response to another text query 610, generates output 614 for the other text query 610, and provides output 614 to the client device providing the other text query 610, while persisting state A 606.

[0090] Furthermore, in some embodiments, the custom interpreter system 102 restores the interpreter 604 to state A 606 and generates output 608 for a summary of the meetings that occurred that day. For example, the custom interpreter system 102 restores the interpreter 604 to state A 606 in response to the completion of execution of computer code 612 that interrupted the execution of computer code 602. In practice, the custom interpreter system 102 accesses the memory registry data, call stack, and / or instruction pointer of state A 606 in order to resume execution of computer code 602 using appropriate data at specific instructions.

[0091] Although not in Figure 6As shown, however, in one or more embodiments, the custom interpreter system 102 can continuously pause and resume the state of the interpreter 604. For example, for text query 600, if the custom interpreter system 102 receives another interrupted query from the client device, the custom interpreter system can generate and execute code for each interrupted query, persist the state of the interpreter 604, and resume the state of the interpreter 604 as the interrupted code completes.

[0092] As described above, the custom interpreter system 102 for persistent interpreter state further implements multi-turn functionality. Figure 7 The illustration shows an example of a custom interpreter system 102, according to one or more embodiments, receiving multiple interactions from a client device for use in a multi-turn function.

[0093] For example, Figure 7 The diagram illustrates the initial text query 700 for reading "What is my meeting on Tuesday?". Furthermore, a custom interpreter system 102 utilizes a context engine 702 that interacts with a large language model 704 to receive the initial text query 700 and generate computer code 706. Additionally, as shown, the custom interpreter system 102 utilizes an interpreter 708 to run the computer code 706.

[0094] As shown, based on the interpreter 708 running computer code 706, the custom interpreter system 102 generates context engine output A 710. Furthermore, as shown, context engine output A 710 includes generating a response 714 to the initial text query 700, which includes "John at 3 p.m. and Sue at 3:45 p.m.". Additionally, as shown, the custom interpreter system 102 receives a further text query 716 that reads "Actually, I want my Monday meeting".

[0095] For example, as shown, the custom interpreter system 102 utilizes a context engine 702 that interacts with a large language model 704 to receive additional text queries 716. As shown, in response to the additional text query 716, the custom interpreter system 102 generates additional computer code and a context engine output B 712 as a response to the additional text query 716. As indicated by the ellipsis, the custom interpreter system 102 may generate additional output based on additional interactions received from the client device.

[0096] In one or more embodiments, because the custom interpreter system 102 persists the state of the interpreter 708, the custom interpreter system 102 can receive multiple interactions from the client device. Therefore, the custom interpreter system 102 provides chat-like functionality to the user of the client device. Specifically, with each round (e.g., an interaction from the client device), the custom interpreter system 102 remembers previous interactions and can either modify the computer code only when responding to another interaction, or generate new computer code based on the initial computer code.

[0097] As described above, in some embodiments, the custom interpreter system 102 generates modified or new computer code. Figure 8 The illustration shows a custom interpreter system 102 according to one or more embodiments generating and / or modifying computer code for text queries.

[0098] For example, as shown, the custom interpreter system 102 receives the initial prompt 800 by utilizing a context engine 802 that interacts with a large language model 804. Furthermore, as shown, the custom interpreter system 102 generates computer code 806 in response to the initial prompt 800 and uses an interpreter 808 to run the computer code 806.

[0099] In some embodiments, if the custom interpreter system 102 does not receive further prompts or interactions from the client device, the custom interpreter system 102 utilizes the interpreter 808 to run the computer code 806 and generate context engine output 812. In some embodiments, the custom interpreter system 102 receives an intermediate query 810 after receiving the initial prompt 800. In response to receiving the intermediate query 810, the custom interpreter system 102 may fine-tune, change, or modify the computer code 806 (e.g., via the context engine 802 interacting with the large language model 804), or the custom interpreter system 102 may generate new computer code to replace the computer code 806.

[0100] In some embodiments, the custom interpreter system 102 determines that some portions of the initially generated computer code upon receiving the intermediate query 810 are persistable. For example, the custom interpreter system 102 utilizes the context engine 802 to interact with a large language model 804 to generate alternative code for non-persistent portions of the computer code (e.g., the computer code corresponding to the intermediate query 810). For illustration, in some embodiments, Figure 7The examples given are suitable for generating modified computer code while retaining a portion of the original computer code. For example, a custom interpreter system 102 determines from intermediate query 810 that the user of the client device actually wants a Monday meeting instead of a Tuesday meeting. In some embodiments of such implementations, instead of generating entirely new computer code, the custom interpreter system 102 generates modified computer code that simply replaces the Tuesday portion with the Monday portion.

[0101] Furthermore, in some embodiments, the custom interpreter system 102 determines that any part of the initially generated computer code is not to be retained. In some embodiments of such embodiments, the custom interpreter system 102 utilizes the context engine 802 to interact with the large language model 804 to generate new computer code corresponding to the intermediate query 810 (e.g., to replace the initially generated computer code). Figure 7 In the example given, instead of the user on the client device sending an intermediate query 810 that includes replacing Tuesday with Monday, the user queries the custom interpreter system 102 to obtain a picture of a cat stored on the client device. In some such instances, because the intermediate query 810 is unrelated to the initial query, the custom interpreter system 102 generates entirely new computer code.

[0102] As an example, the initial prompt 800 could include “Tell me what meetings I have with Jim next week?”. An intermediate query 810 (before the custom interpreter system 102 generates a response to the initial prompt 800) could include “What else do I need to prepare for my meetings with Jim next week?” Therefore, in response to the intermediate query 810, the custom interpreter system 102 could modify the computer code 806 on the fly to accommodate the intermediate query 810.

[0103] Figure 9 A custom interpreter system 102 is illustrated, according to one or more embodiments, to generate a code execution error in response to the interpreter running computer code. For example, Figure 9 The custom interpreter system 102 is shown to generate computer code 904 by using a context engine 900 that interacts with a large language model 902.

[0104] also, Figure 9 The diagram illustrates interpreter 906 running computer code 904 at first executor 908. As shown, while computer code 904 is running at first executor 908, custom interpreter system 102 generates code execution error 910. For example, code execution error 910 includes the custom interpreter system 102 using interpreter 906 to perform dynamic analysis and determine that computer code 904 contains types not explicitly defined within interpreter 906. Furthermore, in some instances, code execution error 910 includes context engine output.

[0105] In one or more embodiments, based on code execution error 910, the custom interpreter system 102 also utilizes context engine 900 to generate modified computer code. In some instances, in response to code execution error 910, the custom interpreter system 102 sends a notification to the client device. Specifically, the notification may include providing the user of the client device with the option to approve the execution of the computer code (e.g., even though the computer code includes types not explicitly defined in interpreter 906). For illustration, the notification may request the user of the client device to approve the sharing of private email messages within a public messaging application.

[0106] In some embodiments, the custom interpreter system 102 determines a static type error 912. Specifically, the static type error 912 includes the custom interpreter system 102 using interpreter 906 to run computer code 904 and determining that, during pre-run, the computer code 904 contains types that are not explicitly defined within interpreter 906. Similar to code execution error 910, in some embodiments, the static type error 912 also causes the custom interpreter system 102 to utilize context engine 900 to generate modified computer code.

[0107] Figure 10A A custom interpreter system 102 is illustrated operating within a graphical user interface according to one or more embodiments. For example, Figure 10A A client device 1000 with a graphical user interface 1002 (e.g., the DROPBOX homepage) is shown. Furthermore, Figure 10A The text query 1004 is shown, which reads as "Who do I need to meet this week?". In response to the user-input text query 1004 on client device 1000, the custom interpreter system 102 utilizes the method described above to generate a context engine output 1006 for the text query 1004. Specifically, the context engine output 1006 includes "Jim – Monday 1:00pm, Sue – Tuesday 12:00pm, Fred – Friday 8:00am".

[0108] and, Figure 10B The custom interpreter system 102 is further illustrated by receiving additional text queries. For example, Figure 10B The diagram shows an additional text query 1008 following the receipt of context engine output 1006. Specifically, additional text query 1008 is read as "What do I need to do to prepare for my Monday meeting?". As shown, the custom interpreter system 102 generates additional context engine output 1010, which is read as "- Organize data, - Write an analysis about the data, - Send an email to the engineering department". For example, as... Figure 10BAs shown, the custom interpreter system 102 utilizes the interpreter's state persistence to remember the text query 1004 in order to generate additional context engine output 1010.

[0109] Although Figure 11 Actions are shown according to certain implementations, but alternative implementations may omit, add, reorder, and / or modify them. Figure 11 Any action shown. Figure 11 The action can be performed as part of a method. Alternatively, a non-transitory computer-readable medium can include instructions that, when executed by one or more processors, cause a computing device to perform... Figure 11 The action. In a further implementation, the system can perform... Figure 11 The action.

[0110] like Figure 11 As shown, a series of actions 1100 may include action 1110 of generating computer code executable in response to a query, action 1120 of executing the computer code using an interpreter, action 1130 of generating the output of a first context engine, and action 1140 of generating the output of a second context engine.

[0111] Specifically, action 1110 includes, as a response to a query received from a client device, utilizing the context engine to interact with a large language model to generate executable computer code in response to the query. Furthermore, action 1120 includes executing the computer code using an interpreter integrated with the context engine and including interchangeable logic interchangeable across multiple executors. Moreover, action 1130 includes, as part of executing the computer code using the interpreter, implementing the interpreter to interpret the computer code from the context engine to a first executor, thereby generating a first context engine output. Additionally, action 1140 includes, as part of executing the computer code using the interpreter, implementing the interpreter to interpret the computer code from the context engine to a second executor, thereby generating a second context engine output.

[0112] Furthermore, in one or more embodiments, a series of actions 1100 includes utilizing an interpreter that includes explicitly defined types to define attributes and functions of code expressions. Additionally, in one or more embodiments, a series of actions 1100 includes preventing computer code from causing the interpreter to perform file system operations to read, write, or delete data stored for user accounts. Moreover, in one or more embodiments, a series of actions 1100 includes dynamically exposing types defined within the interpreter corresponding to the computer code.

[0113] Furthermore, in one or more embodiments, a series of actions 1100 includes executing computer code at a first executor using the interpreter for testing. Furthermore, in one or more embodiments, a series of actions 1100 includes executing computer code at a second executor using the interpreter for verification without refactoring the interpreter. Moreover, in one or more embodiments, a series of actions 1100 includes generating intermediate context engine output using the interpreter as a response to a first interaction from a client device. Furthermore, in one or more embodiments, a series of actions 1100 includes receiving a second interaction from a client device. Moreover, in one or more embodiments, a series of actions 1100 includes generating a modified context engine output from the intermediate context engine output using a large language model based on the second interaction.

[0114] Furthermore, in one or more embodiments, a series of actions 1100 includes storing in a database memory registry data associated with functions executed via the interpreter during the execution of computer code. Also, in one or more embodiments, a series of actions 1100 includes storing in a database a call stack, which includes data defining the computer environment of an executor from a plurality of executors. Furthermore, in one or more embodiments, a series of actions 1100 includes, as a response to a state persistence event, storing in a database an instruction pointer indicating a segment of computer code being executed by the interpreter.

[0115] Furthermore, in one or more embodiments, the series of actions 1100 includes retrieving memory registry data, a call stack, and an instruction pointer from a database. Additionally, in one or more embodiments, the series of actions 1100 includes resuming execution of computer code at a segment indicated by the instruction pointer. Furthermore, in one or more embodiments, the series of actions 1100 includes generating first output using the interpreter as a response to a first interaction from a client device.

[0116] Furthermore, in one or more embodiments, the series of actions 1100 includes persisting the state of the interpreter corresponding to the first output. Additionally, in one or more embodiments, the series of actions 1100 includes generating a second output based on persisting the state of the interpreter corresponding to the first output in response to a second interaction from a client device. Furthermore, in one or more embodiments, the series of actions 1100 includes performing garbage collection within a function as part of executing computer code.

[0117] Furthermore, in one or more embodiments, a series of actions 1100 includes, in response to a query received from a client device, utilizing a context engine to interact with a large language model to generate executable computer code that responds to the query. Furthermore, in one or more embodiments, a series of actions 1100 includes executing the computer code using an interpreter integrated with the context engine and containing interchangeable logic interchangeable across multiple executors. Furthermore, in one or more embodiments, a series of actions 1100 includes, as part of executing the computer code using the interpreter, implementing the interpreter to interpret the computer code from the context engine to a first executor to generate a first context engine output for testing. Furthermore, in one or more embodiments, a series of actions 1100 includes, as part of executing the computer code using the interpreter, implementing the interpreter to interpret the computer code from the context engine to a second executor to generate a second context engine output for verification.

[0118] Furthermore, in one or more embodiments, a series of actions 1100 includes utilizing the interpreter to prevent it from processing code expressions beyond explicitly defined types, whereby the explicitly defined types define the properties and functions of the code expressions. Furthermore, in one or more embodiments, a series of actions 1100 includes utilizing the interpreter to prevent downstream models from performing network operations, determining contextual data for a first executor and a second executor, or creating one or more new child processes. Furthermore, in one or more embodiments, a series of actions 1100 includes exposing the called data corresponding to the type as part of a function executing computer code that references the called data. Furthermore, in one or more embodiments, a series of actions 1100 includes not exposing uncalled data corresponding to the type as part of a function executing computer code.

[0119] Furthermore, in one or more embodiments, a series of actions 1100 includes storing in a database memory registry data associated with functions executed via the interpreter during the execution of computer code. Furthermore, in one or more embodiments, a series of actions 1100 includes storing in a database a call stack, the call stack including data defining the computer environment of an executor among a plurality of executors. Furthermore, in one or more embodiments, a series of actions 1100 includes storing in a database, in response to a state persistence event, an instruction pointer indicating a segment of computer code executed by the interpreter.

[0120] Furthermore, in one or more embodiments, a series of actions 1100 includes, in response to a query received from a client device, utilizing a context engine to interact with a large language model to generate executable computer code that responds to the query. Furthermore, in one or more embodiments, a series of actions 1100 includes executing the computer code using an interpreter integrated with the context engine and including explicitly defined types and interchangeable logic, the explicitly defined types defining properties and functions of code expressions, and the interchangeable logic being interchangeable across multiple executors. Furthermore, in one or more embodiments, a series of actions 1100 includes, as part of executing the computer code using an interpreter, implementing an interpreter to interpret the computer code from the context engine to a first executor to generate a first context engine output. Furthermore, in one or more embodiments, a series of actions 1100 includes, as part of executing the computer code using an interpreter, implementing an interpreter to interpret the computer code from the context engine to a second executor to generate a second context engine output.

[0121] Furthermore, in one or more embodiments, a series of actions 1100 includes performing a first type check process prior to runtime for executing computer code to prevent the interpreter from accessing data beyond explicitly defined types. Furthermore, in one or more embodiments, a series of actions 1100 includes performing a second type check process at runtime for executing computer code to prevent the interpreter from accessing data beyond explicitly defined types.

[0122] Furthermore, in one or more embodiments, the series of actions 1100 includes generating a first output using the interpreter in response to a first interaction from a client device. Furthermore, in one or more embodiments, the series of actions 1100 includes persisting the state of the interpreter corresponding to the first output. Furthermore, in one or more embodiments, the series of actions 1100 includes generating a second output using a large language model based on the first output indicated by persisting the interpreter's state.

[0123] Components of the custom interpreter system 102 may include software, hardware, or both. For example, components of the custom interpreter system 102 may include one or more instructions stored on a computer-readable storage medium and executable by a processor of one or more computing devices. When executed by one or more processors, the computer-executable instructions of the custom interpreter system 102 may cause the computing device to perform the methods described herein. Alternatively, components of the custom interpreter system 102 may include hardware, such as a dedicated processing device for performing a particular function or set of functions. Additionally or alternatively, components of the custom interpreter system 102 may include a combination of computer-executable instructions and hardware.

[0124] Furthermore, components of the custom interpreter system 102 that execute the functions described herein can be implemented, for example, as part of a standalone application, as a module of an application, as a plugin for an application including a content management application, as a library function or function that can be called by other applications, and / or as a cloud computing model. Therefore, components of the custom interpreter system 102 can be implemented as part of a standalone application on a personal computing device or mobile device.

[0125] Embodiments of this disclosure may include or utilize a special-purpose computer or a general-purpose computer, including computer hardware such as one or more processors and system memories, as discussed in more detail below. Implementations within the scope of this disclosure also include physical or other computer-readable media for carrying or storing computer-executable instructions and / or data structures. In particular, one or more processes described herein may be at least in part instructions embodied in a non-transitory computer-readable medium and may be executed by one or more computing devices (e.g., any media content access device described herein). Typically, a processor (e.g., a microprocessor) receives instructions from a non-transitory computer-readable medium (e.g., memory, etc.) and executes those instructions to perform one or more processes, including one or more processes described herein.

[0126] Computer-readable media can be any available medium that can be accessed by a general-purpose computer system or a special-purpose computer system. A computer-readable medium storing computer-executable instructions is a non-transitory computer-readable storage medium (device). A computer-readable medium carrying computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, implementations of this disclosure may include at least two distinct types of computer-readable media: a non-transitory computer-readable storage medium (device) and a transmission medium.

[0127] Non-transitory computer-readable storage media (devices) include RAM, ROM, EEPROM, CD-ROM, solid-state drive (“SSD”) (e.g., RAM-based), flash memory, phase-change memory (“PCM”), other types of memory, other optical disc storage devices, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of computer-executable instructions or data structures and that can be accessed by a general-purpose computer or a special-purpose computer.

[0128] A “network” is defined as one or more data links that enable the transmission of electronic data between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer via a network or another communication connection (whether hardwired, wireless, or a combination of hardwired and wireless), the computer correctly regards that connection as a transmission medium. Transmission media may include networks and / or data links that can be used to carry desired program code in the form of computer-executable instructions or data structures and are accessible by a general-purpose computer or a special-purpose computer. The combination of the above should also fall within the scope of computer-readable media.

[0129] Furthermore, upon arrival at various computer system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from the transmission medium to a non-transitory computer-readable storage medium (device) (and vice versa). For example, computer-executable instructions or data structures received via a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC") and then eventually transferred to the computer system's RAM and / or to the computer system's less volatile computer storage medium (device). Therefore, it should be understood that non-transitory computer-readable storage media (devices) can be included in computer system components that also (even primarily) utilize the transmission medium.

[0130] Computer-executable instructions include, for example, instructions and data, which, when executed by a processor, cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a specific function or group of functions. In some implementations, the computer-executable instructions are executed on a general-purpose computer to turn the general-purpose computer into a special-purpose computer that implements the elements of this disclosure. Computer-executable instructions can be, for example, binary files, intermediate format instructions (such as assembly language), or even source code. Although the subject matter is described in language specific to structural features and / or methodological behavior, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or behaviors described above. Rather, the described features and behaviors are disclosed as exemplary forms for implementing the claims.

[0131] Those skilled in the art will recognize that this disclosure can be practiced in networked computing environments with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronic devices, network PCs, minicomputers, mainframes, mobile phones, PDAs, tablets, pagers, routers, switches, etc. This disclosure can also be practiced in distributed system environments where both local and remote computer systems perform tasks via network links (via wired data links, wireless data links, or a combination of wired and wireless data links). In a distributed system environment, program modules can reside on both local and remote storage devices.

[0132] The implementations of this disclosure can also be implemented in a cloud computing environment. In this description, "cloud computing" is defined as a model for enabling on-demand network access to shared pools of configurable computing resources. For example, cloud computing can be adopted in the market to provide ubiquitous and convenient on-demand access to shared pools of configurable computing resources. Shared pools of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.

[0133] Cloud computing models can be composed of various characteristics, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measurable services. Cloud computing models can also expose various service models, such as Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). Cloud computing models can also be deployed using different deployment models, such as private clouds, community clouds, public clouds, and hybrid clouds. In this description and in the claims, "cloud computing environment" refers to the environment in which cloud computing is employed.

[0134] Figure 12 The illustration shows a block diagram of an example computing device 1200 (e.g., server 104, server 116, and / or client device 108) that can be configured to perform one or more processes described above. It will be appreciated that server 104 and / or client device 108 may include one or more computing devices, such as computing device 1200. Figure 12 As shown, computing device 1200 may include processor 1202, memory 1204, storage device 1206, I / O interface 1208, and communication interface 1210, which can be communicatively coupled through communication infrastructure 1212. Although in Figure 12 The diagram illustrates an example computing device 1200, but... Figure 12The components illustrated are not intended to be limiting. Additional or alternative components may be used in other implementations. Furthermore, in some implementations, computing device 1200 may include more than […]. Figure 12 The number of components shown is fewer. They will now be described in more detail below. Figure 12 The components of the computing device 1200 shown in the figure.

[0135] In a specific implementation, processor 1202 includes hardware for executing instructions, such as those constituting a computer program. By way of example, and not limitation, to execute instructions, processor 1202 may retrieve (or fetch) instructions from internal registers, internal caches, memory 1204, or storage device 1206, and decode and execute them. In a specific implementation, processor 1202 may include one or more internal caches for data, instructions, or addresses. By way of example, and not limitation, processor 1202 may include one or more instruction caches, one or more data caches, and one or more translation-backup buffers (TLBs). Instructions in the instruction cache may be copies of instructions in memory 1204 or storage device 1206.

[0136] Memory 1204 can be used to store data, metadata, and programs for execution by the processor. Memory 1204 may include one or more of volatile and non-volatile memory, such as random access memory (RAM), read-only memory (ROM), solid-state drive (SSD), flash memory, phase-change memory (PCM), or other types of data storage. Memory 1204 may be internal memory or distributed memory.

[0137] Storage device 1206 includes storage for storing data or instructions. By way of example and not limitation, storage device 1206 may include the non-transient storage media described above. Storage device 1206 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk drive, magneto-optical disk drive, magnetic tape drive, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Storage device 1206 may include removable or non-removable (or fixed) media, as appropriate. Storage device 1206 may be internal or external to computing device 1200. In a particular implementation, storage device 1206 is a non-volatile solid-state memory. In other implementations, storage device 1206 includes read-only memory (ROM). Where appropriate, the ROM may be a mask-programmable ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0138] I / O interface 1208 allows a user to provide input to computing device 1200, receive output from computing device 1200, and otherwise transmit and receive data to and from computing device 1200. I / O interface 1208 may include a mouse, keypad or keyboard, touchscreen, camera, optical scanner, network interface, modem, other known I / O devices, or combinations of these I / O interfaces. I / O interface 1208 may include one or more devices for presenting output to a user, including but not limited to a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., display drivers), one or more audio speakers, and one or more audio drivers. In some implementations, I / O interface 1208 is configured to provide graphical data to a display for presentation to a user. The graphical data may represent one or more graphical user interfaces and / or any other graphical content, which may serve a particular implementation.

[0139] Communication interface 1210 may include hardware, software, or both. In any case, communication interface 1210 may provide one or more interfaces for communication (such as packet-based communication) between computing device 1200 and one or more other computing devices or networks. By way of example and not limitation, communication interface 1210 may include a network interface controller (NIC) or network adapter for communicating with Ethernet or other cable-based networks, or a wireless NIC (WNIC) or wireless adapter for communicating with wireless networks (such as Wi-Fi).

[0140] Alternatively or concurrently, the communication interface 1210 may facilitate communication with one or more portions of an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or the Internet, or a combination of two or more of these. One or more portions of these networks may be wired or wireless. As an example, the communication interface 1210 may facilitate communication with a wireless PAN (WPAN) (such as, for example, BLUETOOTH WPAN), a Wi-Fi network, a Wi-Fi Max network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or other suitable wireless networks, or a combination of these.

[0141] Furthermore, the communication interface 1210 can facilitate communication using various communication protocols. Examples of communication protocols that can be used include, but are not limited to, data transmission media, communication devices, Transmission Control Protocol (TCP), Internet Protocol (IP), File Transfer Protocol (FTP), Telnet, Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), Session Initiation Protocol (SIP), Simple Object Access Protocol (SOAP), Extensible Markup Language (XML) and its variations, Simple Mail Transfer Protocol (SMTP), Real-Time Transport Protocol (RTP), User Datagram Protocol (UDP), Global System for Mobile Communications (GSM) technology, Code Division Multiple Access (CDMA) technology, Time Division Multiple Access (TDMA) technology, Short Message Service (SMS), Multimedia Messaging Service (MMS), Radio Frequency (RF) signaling technology, Long Term Evolution (LTE) technology, wireless communication technologies, in-band and out-of-band signaling technologies, and other suitable communication networks and technologies.

[0142] The communication infrastructure 1212 may include hardware, software, or both, that couple the components of the computing device 1200 to each other. By way of example and not limitation, the communication infrastructure 1212 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infiniband interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or another suitable bus or combination thereof.

[0143] Figure 13 This is a schematic diagram of an environment 1300 in which one or more implementations of a custom interpreter system 102 may be implemented. For example, the custom interpreter system 102 may be part of a content management system 1302 (e.g., content management system 106). The content management system 1302 may generate, store, manage, receive, and send digital content (such as digital content items). For example, the content management system 1302 may send and receive digital content to and from client devices in client device 1306 via network 1304. In particular, the content management system 1302 may store and manage collections of digital content. The content management system 1302 may manage the sharing of digital content among computing devices associated with multiple users. For example, the content management system 1302 may facilitate users sharing digital content with another user of the content management system 1302.

[0144] Specifically, the content management system 1302 can manage the synchronization of digital content across multiple client devices 1306 associated with one or more users. For example, a user can use a client device in client device 1306 to edit digital content. The content management system 1302 can then enable the client device in client device 1306 to send the edited digital content to the content management system 1302. The content management system 1302 then synchronizes the edited digital content on one or more attached computing devices.

[0145] In addition to synchronizing digital content across multiple devices, one or more implementations of the content management system 1302 can also provide efficient storage options for users with large amounts of digital content. For example, the content management system 1302 can store a collection of digital content on the content management system 1302, while the client devices in client device 1306 only store reduced-size versions of the digital content. Users can browse the reduced-size versions of the digital content (e.g., thumbnails of digital images) on the client devices in client device 1306. In particular, one way a user can experience digital content is by browsing the reduced-size versions of the digital content on the client devices in client device 1306.

[0146] Another way for users to experience digital content is to select a smaller version of the digital content to request a full-resolution or high-resolution version of the digital content from the content management system 1302. Specifically, after the user selects a smaller version of the digital content, the client device in client device 1306 sends a request to the content management system 1302 to request the digital content associated with the smaller version. The content management system 1302 can respond to the request by sending the digital content to the client device in client device 1306. After receiving the digital content, the client device in client device 1306 can then present the digital content to the user. In this way, users can access a large amount of digital content while minimizing the amount of resources used on the client device in client device 1306.

[0147] The client device in client device 1306 can be a desktop computer, laptop computer, tablet computer, personal digital assistant (PDA), in-vehicle or out-of-vehicle navigation system, handheld device, smartphone or other cellular phone or mobile phone, mobile gaming device, other mobile device or other suitable computing device. The client device in client device 1306 can execute one or more client applications, such as a web browser (e.g., Microsoft Windows Internet Explorer, Mozilla Firefox, Apple Safari, Google Chrome, Opera, etc.) or native or dedicated client applications (e.g., Dropbox Paper for iPhone or iPad, Dropbox Paper for Android, etc.) to access and view content via network 1304.

[0148] Network 1304 may represent a network or a collection of networks (such as the Internet, corporate intranet, virtual private network (VPN), local area network (LAN), wireless local area network (WLAN), cellular network, wide area network (WAN), metropolitan area network (MAN), or a combination of two or more such networks), and a client device in client device 1306 may access content management system 1302 via the network or collection of networks.

[0149] In the foregoing description, this disclosure has been described with reference to specific exemplary implementations thereof. Various implementations and aspects of this disclosure are illustrated with reference to the details discussed herein and by means of the accompanying drawings. The foregoing description and drawings are illustrative and do not limit this disclosure. Numerous specific details have been described to provide a thorough understanding of the various implementations.

[0150] This disclosure may be embodied in other specific forms without departing from its spirit or essential characteristics. The described implementations should be considered illustrative rather than restrictive. For example, the methods described herein may be performed with fewer or more steps / actions, or the steps / actions may be performed in a different order. Furthermore, the steps / actions described herein may be repeated or performed in parallel with the same or similar steps / actions in other instances. Therefore, the scope of this application is indicated by the appended claims rather than the foregoing description. All variations falling within the meaning and equivalent scope of the claims are to be included within their scope.

[0151] The foregoing specification describes specific exemplary implementations thereof. Various implementations are illustrated in the accompanying drawings and with reference to the details discussed herein. The foregoing description and drawings are illustrative and do not limit this disclosure. Numerous specific details are described to provide a thorough understanding of the various implementations.

[0152] Additional or alternative implementations may be embodied in other specific forms without departing from their spirit or essential characteristics. The described implementations should be considered illustrative rather than restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than the foregoing description. All variations falling within the meaning and equivalent scope of the claims are to be included within their scope.

Claims

1. A computer-implemented method, comprising: In response to queries received from client devices, the context engine interacts with a large language model to generate executable computer code to respond to the queries. Execute computer code using an interpreter that integrates with a context engine and includes interchangeable logic that can be interchanged across multiple executors; As part of using an interpreter to execute computer code, the first context engine output is generated by implementing an interpreter to interpret computer code from the context engine into a first executor; as well as As part of using an interpreter to execute computer code, the second context engine output is generated by implementing an interpreter that interprets computer code from a context engine into a second executor.

2. The computer-implemented method of claim 1, wherein the interpreter includes an explicitly defined type that defines the properties and functions of the code expression.

3. The computer-implemented method of claim 1 further prevents computer code from causing the interpreter to perform file system operations that read, write, or delete data stored for a user account.

4. The computer-implemented method according to claim 1, wherein executing computer code using an interpreter further includes dynamically exposing types defined within the interpreter corresponding to the computer code.

5. The computer-implemented method of claim 1, wherein the interchangeable logic of the interpreter facilitates: To use an interpreter to execute computer code at a first executor for testing; and The interpreter is used to execute computer code at a second executor for verification without refactoring the interpreter.

6. The computer-implemented method according to claim 1, further comprising: In response to the first interaction from the client device, the intermediate context engine output is generated using the interpreter; Receive the second interaction from the client device; as well as Based on the second interaction, a modified context engine output is generated from the intermediate context engine output using a large language model.

7. The computer-implemented method of claim 1 further includes persisting the interpreter's state by: During the execution of computer code, memory registry data associated with functions executed via the interpreter is stored in a database; The call stack is stored in the database, and the call stack includes data that defines the computer environment of the executors among multiple executors; as well as In response to state persistence events, instruction pointers that indicate segments of computer code executed by the interpreter are stored in the database.

8. The computer-implemented method of claim 7, further comprising resuming execution of the computer code after a persistent state by: Retrieve in-memory registry data, call stack, and instruction pointer from the database; and Resume execution of computer code at the segment indicated by the instruction pointer.

9. The computer-implemented method according to claim 1, further comprising: In response to the first interaction from the client device, the interpreter generates the first output; Persist the state of the interpreter corresponding to the first output; as well as In response to a second interaction from the client device, a second output is generated based on the state of the interpreter that is persisted to the first output.

10. The computer-implemented method of claim 1, further comprising performing garbage collection within a function as part of executing computer code.

11. A system comprising: At least one processor; as well as A non-transitory computer-readable medium storing instructions that, when executed by at least one processor, cause the system to: In response to queries received from client devices, the context engine interacts with a large language model to generate executable computer code to respond to the queries. Execute computer code using an interpreter that integrates with a context engine and includes interchangeable logic that can be interchanged across multiple executors; As part of using an interpreter to execute computer code, the first context engine output is generated by implementing an interpreter to interpret the computer code from the context engine to the first executor for testing; as well as As part of using an interpreter to execute computer code, the second context engine output is generated by implementing an interpreter to interpret the computer code from the context engine to a second executor for verification.

12. The system of claim 11, wherein the interpreter cannot process code expressions other than those of explicitly defined types of properties and functions that define code expressions.

13. The system of claim 11 further stores instructions that, when executed by at least one processor, cause the system to use an interpreter to prevent downstream models from performing one or more of the following: performing network operations, determining contextual data for the first and second executors, or creating new subprocesses.

14. The system of claim 11 further stores instructions that, when executed by at least one processor, cause the system to dynamically expose types defined within the interpreter by: As part of a function that executes computer code referencing the invoked data, invoked data corresponding to the type is exposed; and As part of a function that executes computer code, it does not expose uninvoked data corresponding to the type.

15. The system of claim 11, further storing instructions that, when executed by at least one processor, cause the system to persist the state of the interpreter by: During the execution of computer code, memory registry data associated with functions executed via the interpreter is stored in a database; The call stack is stored in the database, and the call stack includes data that defines the computer environment of the executors among multiple executors; as well as In response to state persistence events, instruction pointers that indicate segments of computer code executed by the interpreter are stored in the database.

16. A non-transitory computer-readable medium storing executable instructions that, when executed by at least one processor, cause at least one processor to: In response to queries received from client devices, the context engine interacts with a large language model to generate executable computer code to respond to the queries. Execute computer code using an interpreter that integrates with a context engine and includes explicitly defined types of properties and functions that define code expressions, as well as interchangeable logic that can be used across multiple executors; As part of using an interpreter to execute computer code, the first context engine output is generated by implementing an interpreter to interpret the computer code from the context engine to the first executor; as well as As part of using an interpreter to execute computer code, the second context engine output is generated by implementing an interpreter to interpret the computer code from the context engine to the second executor.

17. The non-transitory computer-readable medium of claim 16 further stores instructions that, when executed by at least one processor, cause at least one processor to: First type checking is performed before runtime, before the computer code is executed, to prevent the interpreter from accessing data outside of explicitly defined types; and A second type check is performed at runtime to prevent the interpreter from accessing data outside of explicitly defined types.

18. The non-transitory computer-readable medium of claim 16, further storing instructions that, when executed by at least one processor, cause at least one processor to: During the execution of computer code, memory registry data associated with functions executed via the interpreter is stored in a database; The call stack is stored in the database, and the call stack includes data that defines the computer environment of the executors among multiple executors; as well as In response to state persistence events, instruction pointers that indicate segments of computer code executed by the interpreter are stored in the database.

19. The non-transitory computer-readable medium of claim 16 further stores instructions that, when executed by at least one processor, cause at least one processor to perform garbage collection processing within a function as part of executing computer code.

20. The non-transitory computer-readable medium of claim 16, further storing instructions that, when executed by at least one processor, cause at least one processor to: In response to the first interaction from the client device, the interpreter generates the first output; Persist the state of the interpreter corresponding to the first output; as well as A second output is generated using a large language model based on a first output indicated by the state of the persistent interpreter.

Images