I think eating in a restaurant is something that does not have a FIFO characteristic but we could

still effectively manage with a queue. For example, people might have made reservations at a
popular restaurant for parties or large gatherings, so at they are guaranteed to have the reserved
lunch spot at that reserved time. So even though others might be lining up for spots at the same
restaurant at around the same time, those reserved parties are given priority. Also, depending on
the individual people eating in the restaurant, some people just go in, sit and eat alone for a fast
lunch, yet some people have company and might take longer to finish up their meal (maybe to
talk about certain important business related issue). So in a restaurant, it’s not usually who goes
in first will come out first. It really depends on the individual situation. But we can still manage
it as a queue, as in- if people finish their food and leaves (it could be someone who just got here
for a quick lunch, or an entire party who finished after a long time), as long as a table frees up,
the waiter can take the next person inline to that spot and help them with their order. So
restaurant orders don’t usually strictly follow a FIFO pattern, but we can still manage it with a
queue.

As stated in the lecture, a list is an ordered collection of data items where all locations of data are
available for insertion and deletion. This is very different from either stacks or queues as for
stacks, we can only push and pop at the front, and for queues, we can only insert at the end, and
pop at the front. But here, a list can insert and delete everywhere. This is very helpful since we
have the freedom to insert and delete anywhere of a list, and there is no restriction on a specific
endpoint. We can also have sorted list, where the items are arranged in an ascending or
descending pattern. Any position we specify on a list is relative to the beginning of a list. This
could be very helpful, as it makes it easy for us to search through the list for a certain element.
I think a list ADT should not include hints or references to the list implementation. Because as
we have learned at the beginning of the semester, abstract data types are just the outside of the
black box- it doesn’t contain any information regarding the implementation (inside of the black
box). These list implementations include implementation of list as array or a linked list, and even
though the general list definition doesn’t include that much restriction- it’s only a very generic
definition, the implementations are what places restrictions on the list functions. As the lecture
pointed out, the list ADT have the standard insert and delete methods, and the data also include
the pointer to the start of the list. For example, for the array implementation, we are limited on
size, and we require the list to be homogenous, but we have random access that we can exploit.
And also, deleting in the array implementation of a list requires us to shift to close gap in the list
(or we can use flag values). And for linked list implementation, we have no size limits, we again
needed the list to be homogenous, and linked implementation requires sequential access. Now
these restrictions and limitation from implementations can be linked to the computation
complexity, and these things are not presented to the user.