I have a value which I define, and then use in the next line. However, this value is only recognized depending on how I use it below:
specifically, the messages
variable, defined in the first line of each example, is not recognized in the second example. I should also note that since the last time I tested this, there is also now a type mismatch error on the line which uses the value from the function chaining line as well.
Here are two examples, which should be equivalent, but the first saves an intermediate value, and the second one uses more chaining:
Working
messages = Chat.appendUserMessage previousMessages Stdin.line! {}
response = Http.send (Chat.buildHttpRequest client messages {}) |> Task.result!
updatedMessages = Chat.updateMessageList response messages |> Tools.handleToolCalls! client toolHandlerMap
printLastMessage! updatedMessages
Broken
messages = Chat.appendUserMessage previousMessages Stdin.line! {}
updatedMessages =
Http.send (Chat.buildHttpRequest client messages {})
|> Task.result!
|> Chat.updateMessageList messages
|> Tools.handleToolCalls client toolHandlerMap
printLastMessage! updatedMessages
In the second example, I get the following error messages:
── TYPE MISMATCH in roc-agent.roc ──────────────────────────────────────────────
This 1st argument to printLastMessage has an unexpected type:
45│ printLastMessage! updatedMessages
^^^^^^^^^^^^^^^
This updatedMessages value is a:
Task (List Tools.Message) [
DirErr [
AlreadyExists,
NotADirectory,
NotFound,
Other Str,
PermissionDenied,
],
PathErr InternalPath.GetMetadataErr,
]
But printLastMessage needs its 1st argument to be:
List Chat.Message
Tip: Add type annotations to functions or values to help you figure
this out.
── UNRECOGNIZED NAME in roc-agent.roc ──────────────────────────────────────────
Nothing is named `messages` in this scope.
41│ Http.send (Chat.buildHttpRequest client messages {})
^^^^^^^^
Did you mean one of these?
Message
initMessages
Integer
Result
Known bug...or more accurately a variant of a known bug
!
does not desugar correctly with tasks
Specifically, it desugars incorrectly when used in pipelines
I advise moving to purity inference if you can
These are the kinds of bugs that aren't really worth spending time to fix now that purity inference is here
Context:
Yep, makes total sense. Thanks Brendan!
Ian McLerran has marked this topic as resolved.
Last updated: Jul 06 2025 at 12:14 UTC