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).
Holes at the local functions contexts borders
Unused parameters – output holes
Parameters/arguments that are given to a function but then not used.
Use count is 0.
Undefined return value - input hole
There is "nothing" connected to the output of the function yet.
No code fragments to drag and drop
Code-fragments connected spanning across function borders
cannot be treated like drag and drop puzzle-pieces.
If that's desired the code should probably factored differently.
Code fracture as the dual to code fragment
When working from the function fringes inward then
maybe it is better to look at it inversely.
A code fracture splitting the void.
There is literally a void type.
More on that later.
Orthogonal hole 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
