-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Constrained representation types #354
Comments
I'm having trouble understanding, what exactly does |
It parses an array of format descriptions that have a common representation, resulting in an array of that common representation type. It popped up back when I had the links to We might come up against some better motivating examples though, so I kind of just wanted to note this down in case. |
Oh right I see, so that input array is an array of formats... tricky to construct such a beast! |
It it might eventually be useful to be able to ‘constrain’ representation types using something like
Format { Repr = ... }
(this popped up in other approaches to figuring out the font tables).
This could allow us to write formats like:
join16 : fun (len : U16) (A : Type) -> Array16 len (Format { Repr = A }) -> Format { Repr = Array16 len A }
As Fathom is based on intensional type theory implementing such a construct could require a bit of thought – I'm not entirely clear on what the interactions and difficulties are, or if there are ways to simplify this.
A weird connection to module systems and associated types
This reminds me a bit of a limited form of:
where type
in Standard ML (A Crash Course on ML Modules)with type
(OCaml Manual)Iterator<Item = T>
This kind of makes sense if you imagine a
Format
to be a builtin/hard-coded module type:You could imagine extending this 'module' to support sizes too:
Note: I'm absolutely not recommending we implement
Format
s in this way - I just find it an interesting perspective!The text was updated successfully, but these errors were encountered: