todo.md
This commit is contained in:
parent
dfa364bc0f
commit
edd3441511
1 changed files with 79 additions and 0 deletions
79
todo.md
Normal file
79
todo.md
Normal file
|
@ -0,0 +1,79 @@
|
|||
* BUG: cant find morphism when path is trivial, or when
|
||||
*some* members of a struct have trivial morphism
|
||||
|
||||
* BUG: -O3 kills some Morphisms
|
||||
|
||||
* BUG: erroneous code generation with Packed struct layout
|
||||
|
||||
* type Aliases / typedefs (load from input file)
|
||||
-- platform specializations
|
||||
-- shortcuts
|
||||
|
||||
* add highest-common-rung to generated morphism names
|
||||
(to avoid potential ambiguities)
|
||||
|
||||
* add bounds to Morphism type:
|
||||
- subtype bounds
|
||||
- trait bounds
|
||||
- value bounds
|
||||
|
||||
* data dependence:
|
||||
- Each Struct creates a Context,
|
||||
where a struct member becomes a type-variable,
|
||||
available after it has been parsed from the input buffer.
|
||||
- need some kind of partial Order over the member data fields,
|
||||
to express parsing dependencies.
|
||||
|
||||
* bounds:
|
||||
-> ℕ ~ UInt64 ---> ℕ ~ UInt8
|
||||
- know that value fits into UInt8 ?
|
||||
|
||||
-> <Digit 128> ~ UInt64 --> <Digit 128> ~ UInt8
|
||||
allows the following path:
|
||||
<Digit 128> ~ UInt64
|
||||
-> <Digit 128> ~ Char ~ Ascii ~ native.UInt8
|
||||
-> <Digit 128> ~ native.UInt8
|
||||
|
||||
this will result in 'invalid digits' that are out of the ascii range
|
||||
and is not wanted.
|
||||
maybe the Morphism from digit to char should not exist for radix 128 (->value bounds on type vars)?
|
||||
-fixed by adding explicit <Digit R>~UInt64 -morph-> <Digit R>~UInt8
|
||||
|
||||
* type descriptions: signed posints?
|
||||
- Include minus sign '-' into the <Digit Radix> type ?
|
||||
- or use [<Digit Radix> | Sign] ?
|
||||
- or rather <SignedPosInt Radix Endianness> ~ {
|
||||
sign: <Option Sign~Char>;
|
||||
digits: <Seq <Digit 10>~Char>
|
||||
};
|
||||
- ?
|
||||
|
||||
* size estimation & memory allocation
|
||||
- from each type definition, we need to derive
|
||||
a form for an "allocation schema",
|
||||
of which a value instance of that type defines
|
||||
concrete length values for arrays and members
|
||||
and thus the total required buffer size.
|
||||
|
||||
- in parallel to each morphism we need to know
|
||||
the output-allocation schema in accordance to
|
||||
a given allocation schema of the input data.
|
||||
|
||||
- Complex morphisms allocate a double buffering
|
||||
with maximum required size at each point in the chain
|
||||
|
||||
- optional: allocation free morphisms for members in struct morphism ?
|
||||
- In-Place Morphisms
|
||||
|
||||
|
||||
* improve debugability of "no morphism path found"
|
||||
- find a heuristic to guess "implementation overhead" of
|
||||
a missing morphism by its type
|
||||
- Step 1: Calculate Connected Components of src and dst Type ;
|
||||
- Step 2: For each combination of a vertex-pair from src and dst Components,
|
||||
calculate the implementation overhead heuristic ;
|
||||
- Step 3: suggest to the developer the n smallest morphism types that would
|
||||
bridge the two components
|
||||
|
||||
|
||||
* allow to define (ladder-typed) functions, not just morphisms
|
Loading…
Add table
Add a link
Reference in a new issue