jkomoros / prompt-garden

A framework for gardening LLM prompts
Apache License 2.0
9 stars 0 forks source link

A `namespace` environment variable #37

Closed jkomoros closed 1 year ago

jkomoros commented 1 year ago

It's best practice to attach a prefix (e.g. komoroske.com) to variable names in var/let, to store IDs, and memoryIDs. This helps ensure that different seeds from different authors don't stomp on each other's state.

But it's super tedious and annoying to add it everywhere within a file.

Add a namespace environment variable.

The behavior is:

When computing the variable name for var/let, the memory ID for memory, or the store ID for store, if the prefix property is not empty, and the var name is not a known environment name (skip this for storeID and memoryID), and the var does not already include something before a prefix, replace the variable name / memory ID / store ID with prefix:varname.

Another approach is to only do this for varNames etc that start with ..

When used in combination with packet-level environment (issue #38), the convention is to set the prefix at the top-level packet environment and never think about it again.

This expansion is done at the time of the seed being executed, not before. The pro is that we can late-bind the prefix (so, for example, you don't need to prepend it in the packet-level environment if you're also specifying a model, because it won't be prefixed until being used). The con is that static analysis tools that look at the seed graph will need to know about this behavior to appropriately figure out the variable names (and also perform lets/vars in that graph traversal).

Document in README.md how namespace works. Describe the inner workings, but then summarize: "Include a namespace in the environment of each packet. Whenever you need to reference a var, memory, or fact from another author, include author-prefix.com: in front, and otherwise don't think about it."

validateSeedPacket should verify that any namespace that is set does not include :.

How to handle _default_memory et al? In some cases you really do want to overlap in the commons. If you set a namespace, how do you say don't namespace this name for one of memory, or store, or whatever? Maybe the answer is that all of those memory/store ids are namespaced, just with :_default_store or whatever. And that way if you want to do a memory name that's not the same as the namespace you're using you can just manually configure :_default_store. (_default_store should have its name changed if we expect people to every so often type it...)

Originally tracked in #36.

jkomoros commented 1 year ago

This is now done as of 78d6121