This commit is contained in:
Michael Sippel 2025-05-27 15:38:57 +02:00
parent dfa364bc0f
commit edd3441511
Signed by: senvas
GPG key ID: F96CF119C34B64A6

79
todo.md Normal file
View 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