3 ms·

> Not in all type systems I think this is inaccurate. We are talking about computer science, which is important and a constraint around the general type theory

> Not in all type systems I think this is inaccurate. We are talking about computer science, which is important and a constraint around the general type theory. A type system is different than how you interact with it, so dispensing with language-specific symbolic representation further normalizes the discussion. Fundamentally, a (computer science) type is a representation of binary, for the most part, data. That representation has to inhabit some part of bounded memory. When that memory is initialized (empty), it's some form of NULL, for a lack of another term. It exists for every type system in computer science. > There are also variants that have separate NULL types for different base types, which also invalidate your claim That's not the same thing. Different NULL types make sense for different sized discrete (fixed bounds) memory allocation. A unicode character has a fixed size allocation, while a string might be unbounded allocation (it grows in some fashion, as needed). Edit: Kneejerk downvoting, classy.

yxhuvud 8y ago
It was not I that downvoted you, but I agree with the down-voter in that you are not making good arguments. There is basically nothing in common with NULL as used by programming languages in general compared to how you want to define it in your comment. How NULL is represented internally, is totally language dependent. C and its ilk has defined it one way (that is reasonably close to your description ON SOME ARCHITECTURES - not all), but how other languages define it differ wildly. And strings may only grow if strings are mutable, which AGAIN is extremely language dependent.
Sharlin 8y ago
This does not make sense. Null is not the same as zero and neither is the same as an all-zeros bit pattern. A memory word interpreted as an integer has no meaningful null value. A memory word interpreted as a pointer may or may not have a special bit pattern (which may or may not be the same as integer zero) that represents a pointer to nowhere; it all depends on language semantics. The address 0x0 can be perfectly valid on some architectures. Even though in C the literal 0 denotes a null pointer constant, it does not mean that the value of a null pointer is literally zero.
- ArchTypical 8y ago
  > A memory word interpreted as an integer has no meaningful null value. What a type is, depends on what the runtime operates on. You can make a runtime that just grabs random bits of data as a type and say "that's an integer" but it's not a useful construct/example. A runtime keeps track of types in some way external to the data itself. So I'll disagree that an all-zeros is not the same as a null, because it's a common way to initialize the data that is identified with a type (like in a pointer table). It's not a 1:1 but it's common. There's not always a formalized name, but it (an uninitialized state) always exists as part of the type system (when not reusing existing memory allocation, which is an initialized state). Always.
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 ago
  Category 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 ago
    But 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 ago
      Well said.

yxhuvud 8y ago

It was not I that downvoted you, but I agree with the down-voter in that you are not making good arguments. There is basically nothing in common with NULL as used by programming languages in general compared to how you want to define it in your comment. How NULL is represented internally, is totally language dependent. C and its ilk has defined it one way (that is reasonably close to your description ON SOME ARCHITECTURES - not all), but how other languages define it differ wildly. And strings may only grow if strings are mutable, which AGAIN is extremely language dependent.

Sharlin 8y ago

This does not make sense. Null is not the same as zero and neither is the same as an all-zeros bit pattern. A memory word interpreted as an integer has no meaningful null value. A memory word interpreted as a pointer may or may not have a special bit pattern (which may or may not be the same as integer zero) that represents a pointer to nowhere; it all depends on language semantics. The address 0x0 can be perfectly valid on some architectures. Even though in C the literal 0 denotes a null pointer constant, it does not mean that the value of a null pointer is literally zero.

ArchTypical 8y ago
> A memory word interpreted as an integer has no meaningful null value. What a type is, depends on what the runtime operates on. You can make a runtime that just grabs random bits of data as a type and say "that's an integer" but it's not a useful construct/example. A runtime keeps track of types in some way external to the data itself. So I'll disagree that an all-zeros is not the same as a null, because it's a common way to initialize the data that is identified with a type (like in a pointer table). It's not a 1:1 but it's common. There's not always a formalized name, but it (an uninitialized state) always exists as part of the type system (when not reusing existing memory allocation, which is an initialized state). Always.

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 ago
Category 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 ago
  But 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 ago
    Well said.