3 ms·
The definition of a list is that it contains zero or more elements. There's nothing deep about it; it's just the way the type is defined (and always has been, b
by noelwelsh 2y ago
The definition of a list is that it contains zero or more elements. There's nothing deep about it; it's just the way the type is defined (and always has been, back to the early days of Lisp from which functional programming evolved.)
- TeMPOraL 2y agoConceptually, I see this as seeing a list as its own thing, independent of its contents. That is, a List<Int> is a value in itself, that can exist even if no instance of an Int exists anywhere in the program; it'll just be a List of Int that happens to have zero Ints in it. Probably makes more sense when you come from imperative programming background, where List<Int> is a piece of mutable state that you can construct and then fill, in two explicitly separate steps (and then possibly empty it again in yet another step). Then again, I believe even mathematicians are fine with ideas of an empty set, or of a one-element set being distinct from the element itself.
- nyssos 2y ago> Then again, I believe even mathematicians are fine with ideas of an empty set, or of a one-element set being distinct from the element itself. Especially mathematicians. Distinguishing stuff and structure is a common theme throughout mathematics.
- sriram_malhar 2y agoYes, that's true. But Lisp is untyped. The notation [a] could just as easily have meant a non-empty list
- HelloNurse 2y agoIt is necessary to represent the empty list whose elements (if it had any) are type A, and its type must be the same as a nonempty list of A, because concatenating the two must be a well-defined and representable operation while concatenating empty lists of different types must be as wrong as concatenating nonempty ones. Moreover, in practice most variables, function parameters and the like should be declared as a possibly empty list of A, without special cases.