hey, it's better than us - we never managed to put together a good easily-browseable version of the spec that doesn't need to be read in Scrivener. (though you will find HTML exports in that repo)
Conversation
hmmm, so we think it's in a sense a mistake to have struct types as a primitive in the language. you can build them out of product types, so it doesn't make sense to have both. you can have pre-built structs as a library feature rather than a language feature.
2
1
The issue is that these are 'dependent struct types', so they are more 'dependent sums' than 'product types'. I'm still on the fence as to if I want them to be nominal definitions though.
1
1
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).
1
1
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…
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
Show replies