The aim here is to improve trace-ability of errors in stdlib fns.
DvalSource is used throughout Dark's Runtime to track the source of Incomplete or Errors.
It has two values - SourceID of tlid * id and SourceNone (implying we don't have context of the source).
The Interpreter currently does a good job of tracking the sources of Dvals.
When a SourceID is returned (rather than a SourceNone), the Editor does a great job of highlighting the source of an Error:
The stdlib fns, however, do a poor job of tracking the source of errors - all stdlib functions that return a DError currently simply return a DError(SourceNone, "message") without context of which bit of code (often a fn arg) caused the error. I believe this is a limitation of our standard library functions simply not having the 'id's of each of their params.
The definition of BuiltInFnSig is
type BuiltInFnSig = (ExecutionState * List<Dval>) -> DvalTask
and a standard library function demonstrating this limitation may be found in Date::parse:
{ name = fn "Date" "parse" 0
parameters = [ Param.make "s" TStr "" ]
returnType = TDate
description = "Parses a string representing a date and time..."
fn =
(function
| _, [ DStr s ] ->
match ocamlCompatibleDateParser s with
| Error () -> Ply(DError(SourceNone, "Invalid date format"))
| Ok d -> Ply(DDate d)
| _ -> incorrectArgs ())
sqlSpec = NotQueryable
previewable = Pure
deprecated = ReplacedBy(fn "Date" "parse" 1) }
If we updated BuiltInFnSig to instead look like
BuiltInFnSig = (ExecutionState * List<id * Dval>) -> DvalTask
then this function definition could instead be
fn =
(function
| state, [ (sID, DStr s) ] ->
match ocamlCompatibleDateParser s with
| Error () -> Ply(DError(SourceID(state.tlid, sID), "Invalid date format"))
| Ok d -> Ply(DDate d)
| _ -> incorrectArgs ())In order to support such, many things would have to change in the Interpreter (just a bunch of id-tracking and type changes) - I started going down this path, but got lost. This is me recording my thoughts/progress, to see if this makes sense to pursue after a break. What do you think?
Beyond this limitation with Standard Library functions, we also over-use SourceNone, or could seemingly choose a "better" (more precise) id to reference - those can be handled separately.
The aim here is to improve trace-ability of errors in stdlib fns.
DvalSourceis used throughout Dark's Runtime to track the source of Incomplete or Errors.It has two values -
SourceID of tlid * idandSourceNone(implying we don't have context of the source).The Interpreter currently does a good job of tracking the sources of Dvals.
When a
SourceIDis returned (rather than aSourceNone), the Editor does a great job of highlighting the source of an Error:The stdlib fns, however, do a poor job of tracking the source of errors - all stdlib functions that return a
DErrorcurrently simply return aDError(SourceNone, "message")without context of which bit of code (often a fn arg) caused the error. I believe this is a limitation of our standard library functions simply not having the 'id's of each of their params.The definition of
BuiltInFnSigistype BuiltInFnSig = (ExecutionState * List<Dval>) -> DvalTaskand a standard library function demonstrating this limitation may be found in
Date::parse:If we updated
BuiltInFnSigto instead look likeBuiltInFnSig = (ExecutionState * List<id * Dval>) -> DvalTaskthen this function definition could instead be
In order to support such, many things would have to change in the Interpreter (just a bunch of
id-tracking and type changes) - I started going down this path, but got lost. This is me recording my thoughts/progress, to see if this makes sense to pursue after a break. What do you think?Beyond this limitation with Standard Library functions, we also over-use
SourceNone, or could seemingly choose a "better" (more precise) id to reference - those can be handled separately.