Conversation

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)
1
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
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
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
Show replies