Summary
Context parameters provide the flexibility of dynamic binding with lexical scope. Sometimes, there is the need to enforce that a context parameter may not be shadowed/re-bound in a context.
Motivation
A concrete example is a tool for LLM:
class Tool(name: String, run: ToolInput => Outcome receives logger)
Notice that the tool when called will be provied a logger from call site. It is important that the tool implementation will not accidentally shadow the provided logger via rebinding.
For example, it is a mistake to capture a logger from the lambda creation site and provision it in the body of the lambda --- that would shadow the logger from the lamda call-site.
Analysis
The non-shadowing should not be a property of a context parameter, but a property at particular provision specification, e.g. receives in lambda types and function definitions.
For example, it is imaginable that a logger context parameter may be rebound in some context but not in other context.
Proposed design
TODO
Alternatives considered
TODO
Summary
Context parameters provide the flexibility of dynamic binding with lexical scope. Sometimes, there is the need to enforce that a context parameter may not be shadowed/re-bound in a context.
Motivation
A concrete example is a tool for LLM:
Notice that the tool when called will be provied a
loggerfrom call site. It is important that the tool implementation will not accidentally shadow the provided logger via rebinding.For example, it is a mistake to capture a logger from the lambda creation site and provision it in the body of the lambda --- that would shadow the
loggerfrom the lamda call-site.Analysis
The non-shadowing should not be a property of a context parameter, but a property at particular provision specification, e.g.
receivesin lambda types and function definitions.For example, it is imaginable that a
loggercontext parameter may be rebound in some context but not in other context.Proposed design
TODO
Alternatives considered
TODO