Convo-Lang: LLM Programming Language and Runtime

COBOL ? Hurrah! If there’s anything that would improve vibe coding, it’s a “come from“ statement. :P

  MARKETING DIVISION

One pain point such a PL could address is encoding tribal knowledge about optimal prompting strategies for various LLMs, which changes with each new model release.

I like that :) thank you

Its an interpreted language. The interpreter and parser are written in TypeScript so it does use Javascript at runtime but its not a transpiled language that is just converted to Javascript.

The Convo-Lang CLI allows you to run .convo files directly on the command line or you can embed the language directly into a TypeScript or Javascript applications using the @convo-lang/convo-lang NPM package. You can also use the Convo-Lang VSCode and Cursor extensions to execute prompt directly in your editor.

The Convo-Lang runtime also provides state management for on-going conversations and handles the transport of messages to and from LLM providers. And the @convo-lang/convo-lang-react NPM packages provides a set of UI components for building chat interfaces and generated images.

Its both a library and a language. You can use it directly in TypeScript and Javascript using the `convo` tagged template literal function from the @convo-lang/convo-lang NPM package.

https://www.npmjs.com/package/@convo-lang/convo-lang

Here is an example of using in TypeScript: ``` ts import {convo} from "@convo-lang/convo-lang"

const categorizeMessage=convo`

    > define
    UserMessage = struct(
        sentiment: enum("happy" "sad" "mad" "neutral")
        type: enum("support-request" "complaint" "compliment" "other")
        # A an array of possible solutions for a support-request or complaint
        suggestedSolutions?: array(string)
        # The users message verbatim
        userMessage: string
    )

    @json UserMessage
    > user
    Categorize the following user message:

    <user-message>
    ${userMessage}
    </user-message>

`

console.log(categorizeMessage)

```

And for a userMessage that looks something like:

---- My Jackhawk 9000 broke in half when I was trying to cut the top of my 67 Hemi. This thing is a piece of crap. I want my money back!!! ----

The return JSON object would look like: ``` json

{

    "sentiment": "mad",

    "type": "complaint",

    "suggestedSolutions": [

        "Offer a full refund to the original payment method",

        "Provide a free replacement unit under warranty",

        "Issue a prepaid return shipping label to retrieve the broken item",

        "Offer store credit if a refund is not preferred",

        "Escalate to warranty/support team for expedited resolution"

    ],

    "userMessage": "My Jackhawk 9000 broke in half when I was trying to cut the top of my 67 Hemi. This thing is a piece of crap. I want my money back!!!"

}

```

Not sure I'm sold on this particular implementation, but here's my best steelman: working with LLMs through plain text prompts can be brittle...tiny wording changes can alter outputs, context handling is improvised, and tool integration often means writing one-off glue code. This is meant to be DSL to add structure: break workflows into discrete steps, define vars, manage state, explicitly control when and how the model acts, and so on.

It basically gives you a formal syntax for orchestrating multi-turn LLM interactions, integrating tool calls + managing context in a predictable, maintainable way...essentially trying being some structure to "prompt engineering" and make it a bit more like a proper, composable programming discipline/model.

Something like that.

Riding the LLM hype train to its exhaustion.

Sometimes I feel like an LLM . I takes a little getting used to, but that is the same for any new language. And the Convo-Lang syntax highlighter helps to.

The triple questions marks (???) are used to enclose natural language that is evaluated by the LLM and is considered an inline-prompt since it is evaluated inline within a function / tool call. I wanted there to be a very clear delineation between the deterministic code that is executed by the Convo-Lang interpreter and the natural language that is evaluated by the LLM. I also wanted there to be as little need for escape characters as possible.

The content in the parentheses following the triple question marks is the header of the inline-prompt and consists of modifiers that control the context and response format of the LLM.

Here is a breakdown of the header of the first inline-prompt: (+ boolean /m last:3 task:Inspecting message)

----

- modifier: +

- name: Continue conversation

- description: Includes all previous messages of the current conversation as context

----

- modifier: /m

- name: Moderator Tag

- description: Wraps the content of the prompt in a <moderator> xml tag and injects instruction into the system describing how to handle moderator tags

----

- modifier: last:{number}

- name: Select Last

- description: Discards all but the last three messages from the current conversation when used with the (+) modifier

----

- modifier: task:{string}

- name: Task Description

- description: Used by UI components to display a message to the user describing what the LLM is doing.

----

Here is a link to the Convo-Lang docs for inline-prompts - https://learn.convo-lang.ai/#inline-prompts

I have to agree, it looks wild, even the simpler examples don't feel ergonomic.

… I think I’ll just stick with pydantic AI for now

I haven't used DSPy this much, but as I understand it: this lang is more like an orchestration DSL for writing and running LLM conversations and tools, whereas DSPy is a framework that compiles and optimizes LLM programs into better-performing prompts...like DSPy has automatic improvement of pipelines using its compilers/optimizers. With DSPy you deal with modules and signatures.

I've already done that LOL

You're absolutely right!