I'm also thinking I might want to separate out 'dependent sequence formats' from 'dependent structs' - this might help me with some of the phase problems I was having (mentioned in another tweet).
Conversation
when you say phase problems, what do you mean exactly?
1
Ie. how to deal with the interpretation of 'formats descriptions' into the host language. Eg. do you mean a U32Be or an { x : Int | x in 0..u32_max }? It shows up where you have dependent types though. Gotta head off for a bit, but I can try to explain later!
2
1
Like, the best I can come up with right now is that U32Be is not really a type - more term that describes a type and a method of parsing that type that is constrained to live at compile time.
2
You could imagine allowing these format descriptions to live at runtime, say if you wanted to describe formats dynamically, but forcing them to live statically helps me in terms of building a compiler, at this stage!
1
notionally, your user can always build their own version that exists at runtime. (or if they can't, your primitives aren't powerful enough and should be fixed.)
1
making them special cases makes sense in the short term, but long-term it would probably be better to have a notion of compiler hints or something
1
Yeah, I'm kind of trying to figure out what I can put off implementing in the short term in order to get this working, and useful, while still leaving the door open to this stuff in the future. It's an interesting problem…
1
1
I'm hoping that I don't actually need multistage programming for this, but it's there if I do!
1
1
heh, indeed.
1
Thanks btw for this discussion! I've been in a bit of an exhausted state with this project for a while now, and this was energising! I appreciate it!
glad to help! also, happy to talk about this anytime.