Typed holes
Typed holes can be used for:
- automatic suggestion of matching functions (depending on context)
- treating fragments of code like fragments of a (drag and drop) jigsaw puzzle with comparable seams
- storing partially complete programs in the codebase (serves as TODO documentation)
- shifting around type mismatches to where they are relevant rather where they are auto-detected by forward or backward type inference
- seeing intersections of type-class constraints
- combining edit-time, compile-time, and run-time simultaneously in a (projectional/structural) coding interface
- having as much code as possible live (code flowing around obstructions in nonempty holes)
- ...
For some drag and drop of typed holes
see the annotated lambda diagram mockups
Contents
Local code fragments
Input hole - aka undefined argument
A local function with an argument lacking a link to an eventually needed dependency.
Collectively input holes define the input surface of a code fragment.
(The local functions needs to have at least the inputs already being defined).
Output hole - aka result
Output of a function that already got defined.
It may have zero or more use contexts already but
locally is not hooked up to anything yet.
Collectively output holes define the output surface of a code fragment.
(Multiple use of outputs calls for let…in constructs).
(The local functions needs to have at least the return type already being defined).
Bridge holes
Intended connection points with type mismatch.
Expression of programmer intent.
Eventually need to be filled either by a function or
by a whole program fragment bridging the type-gap.
Internally a code fragment can be partially connected
and feature complex gaps (many output and input holes).
Function border crossing code fragments
Unused parameters – output holes
Parameters that are given to a function but then not used.
Collectively they define the output surface of a code fragment.
Local values without local dependents.
Orthogonal properties
typeclass-intersection holes
These carry constraints on types that do not yet narrow the type down to uniqueness.
Connecting output holed and input holes with different type-class constraints
gives an intersection of the constraints.
non-empty holes
These carry both defined and undefined values within.
Both can flowing through.
Misc notes
Design decision to make:
Does/can the order of argument carrying meaning or not.
With types argument order can often be figured out by matching type.
Design decision to make:
Structural editors could even allow for generating arguments values and return values without requiring a human readable name.
Automatic numbered names (hash).
But this seems questionable at best. Likely a quite bad idea.
– Human naming laziness may lead to unnamed variables remaining
– Dealing with the additional case of unnamed variables is then needed
Related
External links
- hazel
