design: type system design #3
1 changed files with 28 additions and 1 deletions
|
@ -3,7 +3,7 @@
|
||||||
doc
|
doc
|
||||||
)
|
)
|
||||||
|
|
||||||
= Type data model
|
= Type system
|
||||||
|
|
||||||
== Requirements
|
== Requirements
|
||||||
|
|
||||||
|
@ -14,3 +14,30 @@
|
||||||
- custom types (structs/enums)
|
- custom types (structs/enums)
|
||||||
- algebraic enums
|
- algebraic enums
|
||||||
- traits (`Numeric`...)
|
- traits (`Numeric`...)
|
||||||
|
- functions as data
|
||||||
|
|
||||||
|
== Ideas
|
||||||
|
|
||||||
|
=== Generic-focused
|
||||||
|
|
||||||
|
Color-awareness may be handled as seperate types, so one might have `LinearRgb`, `SRgb`, `Xyz` etc. Optimally implemented using our own constructs.
|
||||||
|
|||||||
|
|
||||||
|
An image in sRGB might have the following type signature: `Image<SRgb>`. Colors could also have a trait which could implement conversions.
|
||||||
|
|
||||||
|
=== Group inference
|
||||||
|
|
||||||
|
==== Example: Multiplying an image with 0.5
|
||||||
|
|
||||||
|
The syntax should be the same as just multiplying two numbers, just that one of the values is an image.
|
||||||
|
|
||||||
|
Type signatures of the values in a generic system:
|
||||||
|
|
||||||
|
`Image<SRgb<u8>> * f32`
|
||||||
|
|
||||||
|
Desugared that would look like this:
|
||||||
|
|
||||||
|
`[[(u8, u8, u8)]] * f32 -> [[(u8, u8, u8)]]`
|
||||||
|
|
||||||
|
Since all of the values are numbers (-> implementing `Num`/`Number`), they should be able to implicitely multiplied.
|
||||||
multisamplednight
commented
Typo.
Typo.
```diff
-Since all of the values are numbers (-> implementing `Num`/`Number`), they should be able to implicitely multiplied.
+Since all of the values are numbers (-> implementing `Num`/`Number`), they should be able to implicitly multiplied.
```
|
|||||||
|
|
||||||
|
Since an image has additional data, how should that be handled? should the resolution be static array lengths?
|
||||||
|
|
Loading…
Reference in a new issue
Why not use the
palette
crate instead?I meant in-language constructs, but that's probably something to put on the far future todo list...
I'm concerned about lacking support for OCIO, but realistically, throw that on that list too lol