5 ms·
I’m not sure I buy this definition of type even in theory. From a category theoretic point of view a type would be nothing more then the constraints on how ter
by CuriousSkeptic 8y ago
I’m not sure I buy this definition of type even in theory.
From a category theoretic point of view a type would be nothing more then the constraints on how terms may be composed.
Either you simply view types as as objects in some category or, perhaps a bit more interesting, as a functor. See f.ex http://noamz.org/papers/funts.pdf http://noamz.org/papers/funts.pdf
Or rather it seems to be a common theme in language design to conflate these two notions of types, and we should probably stop doing that.
- ArchTypical 8y agoCategory theory doesn't require NULL but physical state does. Given the state of the machine as a constraint, there must be an uninitialized state of unknown or undefined (but allocated) for each type to ensure types are run as functors. I don't see why talking about the theory is useful, given the practical constraint will always provide an asterisk of *given you're working on physical memory All types are functors in practice...which always has an element of initialization to ensure the type is defined in the memory.
- CuriousSkeptic 8y agoBut that is a big asterisk, which was my point. Only the compiled and running program is actually forced to working with physical memory. All stages before that is just modeling. My belief is that we should stop conflating data types (input and state modeling) and program types (domain modeling) so we can advance to more productive workflows. F.ex runtime reflection should never have been a thing, instead the focus should have been on macros and staged compilation, most meta programming can probably be better evaluated design time rather than run time.
- ArchTypical 8y agoWell said.