Talk:List (abstract data type)

message: I removed the October 2005 cleanup tag as there is no discussion here of what needs improvement. Hyacinth 11:20, 10 February 2006 (UTC)
thread_title: Cleanup

message: This is the structure for lists used by the Lisp programming language.  Also, while easy to build in RAM, it's not the greatest structure, due to its asymmetry and more (I could argue Lisp speaks lists with a lisp). Other programming languages generally represent & construct lists differently, and often more symmetrically, as via arrays.  Even (X)HTML (a very popular part of computing) doesn't use such structures (cons-cells) externally to construct its lists (OL & UL plus the other XML attributes), nor I really doubt uses them internally in any implementation.  So rename the title of this page.  In its present form, it gives a mis-impression that Computer Science represents Lists this way and THINKS of lists this way, when, more often than not, it doesn't. --MBParker (talk) 01:15, 4 January 2008 (UTC)
replies: text: I agree that the page should be renamed to just List (data type): what is described is not exactly one abstract data type.  I do not agree that this page describes Lisp lists (linked lists) only: those have their own page. Rp (talk) 11:04, 19 March 2012 (UTC)

text: I agree with List (data type). I recommend that at least python be referenced for its built-in list and list-comprehension as described in [5. Data Structures — Python 3.7.6 documentation](https://docs.python.org/3.7/tutorial/datastructures.html) dating back at least to 1996's version 1.4 [Python Tutorial](https://docs.python.org/release/1.4/tut/). Python's version is described as an ADT. DavidLeasure  —Preceding undated comment added 18:50, 24 January 2020 (UTC)
thread_title: page should be renamed to say "List (Lisp)" not "List (computing)

message: User:Jorge Stolfi, a given string is indeed a tuple. But a string as a variable can have any length, not a fixed one, like tuple does! A list is a string, not a tuple. Pcap ping 12:25, 17 August 2009 (UTC)
replies: text: A list, string, or uple value has fixed length, as you say.  In some programming languages, a tuple (or list) variable can be assigned values of different lengths; Python is an example. In other programming languages, a tuple (or list) variable can only be assigned values of the declared length; Pascal is an example.  Therefore that criterion does not distinguish strings from tuples or tuples from lists.  Moreover, the concepts of "variable" and "assignment" do not exist in formal language theory. All the best, --Jorge Stolfi (talk) 18:54, 17 August 2009 (UTC)
replies: text:  The confusion you have with tuples is because you do not consider polymorphic lists. I'll expand on this later; (see chapter 29 in B.C. Pierce (2002) Types and Programming Languages, if you're inclined to write the stuff yourself). Insofar I've fixed the article on tuple to explain the difference between an n-tuple in set theory and a (typed) tuple in type theory, i.e. an element of a product type. Clearly a product type is not the same as a polymorphic list type. Pcap ping 00:41, 18 August 2009 (UTC)

text: Pcap is right.  In type theory, lists are defined by an inductive definition such as A* = μ α. 1 + A × α . So an instance of a list type is indeed isomorphic to a tuple of the form A × ... × A, but the concepts are quite distinct.  --Classicalecon (talk) 09:14, 18 August 2009 (UTC)
replies: text: The point is that lists (or tuples, or any other data structure) are intuitive concepts that can be (and were, and are) defined, used, and studied — in fully rigorous and precise terms — independently of any type theory.  Type theory (or theories) may be nice and useful, but they are not the truth: they are attempts to formalize what programmers and compiler writers do.  Sometimes a formal theory helps, but sometimes it only makes things harder to understand.  Presenting the theoretical definition of a list as if it were the definition, or even a more "correct" defintion, is historically, pedagogically, and practically misleading.  All the best, --Jorge Stolfi (talk) 21:47, 18 August 2009 (UTC)
thread_title:  Misleading lead claimng that a string is a tuple 

message: That section needs some integration with the definition above it. To start, the notation needs to be changed. Also, I don't see why you need the stuff besides return and append to give the monad. The rest appears to be superfluous for that purpose. Pcap ping 00:41, 18 August 2009 (UTC)
thread_title:  Monad section issues 

message: Lists may be many things so the context needs to be explained. Assuming (abstract data type) is what we are discussing. 
From experience implementing list objects in various projects. The difference between a list and an array is blurred by the fact that a list may be implemented as an array.
# Arrays contain a set number of elements of the same type. 
# A list contains some indefinite number of elements, including 0 elements(an empty list), of any type. A list element may be a list.
# Lists may infact be implemented as an array(under laying structure). In lisp 2 they were dynamic arrays containing pointers to typed objects. That is each element of the array was a pointer to a typed element. In this case the array still contains only like elements. A pointer to an object. The list is it's self an object containing it's size(number of elements) and the array of pointers. 
Example of lisp 2 like object in C++ structures. In implementation the pointer points at the data (last field in the object). The data type is contained at a negative (-2 BYTEs offset on a PC) offset from the pointer, hiding the implementation data. A negative type value is a list. Positive values are atomic data elements. LISP 2 indexed list elements. 
struct LispTwoObject {
   ...         // data type dependent data. (integer fraction digits, object attribute data)
  short type;  // type>0 atomic element type, type== 0 nil(empty list), type<0 negative list length
  union data {   // An object pointer points here. -size short is type.
    void* elm[]; // list array of pointers
    BYTE  val[]; // numeric object type, integer, floating etc.
    char  str[]; // character object type: character, ASCIIZ string, symbol etc
    char* name;  // types having a string display name
}};
The most defining difference between arrays and lists is that an array contains elements of the same type. A list may contain elements of different types.  — Preceding unsigned comment added by Steamerandy (talk • contribs) 19:26, 6 October 2014 (UTC)
replies: text: In Haskell, lists are of homogeneous type, just like arrays. In Scheme, both lists and arrays ("vectors") are of heterogeneous type. QVVERTYVS (hm?) 21:36, 6 October 2014 (UTC)
thread_title:  list vs array 

message: An editor has asked for a discussion to address the redirect Flat list. Please participate in the redirect discussion if you wish to do so.  Hildeoc (talk) 19:46, 8 June 2019 (UTC)
thread_title:  Flat list listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: There is a move discussion in progress on Talk:Associative array which affects this page. Please participate on that page and not in this talk page section. Thank you.  —RMCD bot 00:32, 27 January 2022 (UTC)
thread_title:  Move discussion in progress