Adding an element to a list and then reverse it










1















I'm learning Haskell, and attempting to understand lists.



From researching, to add an element to a list, you would normally do:



let numbers = [4,8,15,16,23,42] 
numbers ++ [56]


but to quote this answer:




If you need to do this, there is usually a better way to structure
your algorithm. For example, you can build your list in reverse order
(adding elements at the beginning) and only call reverse at the end.




Code:



let numbers = [23,43,56]
let newNumbers = 69:numbers
reverse newNumbers


Output:



[56,43,23,69]


Question:



  1. Is the code I've written correct according to the quoted answer?

  2. I want to understand the terminology a little better, can I say I'm adding elements to the head of the list? From my understanding, every new element would be the first element, and the value returned when I write head newNumbers.









share|improve this question
























  • It doesn't mean "call reverse after you prepend each itme"; that's no better than using ++ to append the item. Instead, it means that if you want to build up a list by adding new items to the end, you should put them at the beginning instead, and call reverse once it is time to consume the entire list.

    – chepner
    Nov 15 '18 at 16:27











  • @chepner - So in this case, if I wanted to just add 69 to the list, have I done it correctly in accordance with the quote? Which also makes me wonder, how would you add more than one element to the beginning of the list? Guess that's another exercise to try out.

    – user10641593
    Nov 15 '18 at 16:30












  • It really depends on how you intend to use the list. See my answer for an example.

    – chepner
    Nov 15 '18 at 16:55











  • There are times you must definitelly append a list to another list and to make it worse you may need to append new lists to the resulting one several thousands of times. This will be a very costly operation. To overcome this cost difference list data structures are used. This question is all about that

    – Redu
    Nov 15 '18 at 17:06












  • This isn't really a question about haskell, it's a question about a stackoverflow question. Adding the tag makes it harder to find questions about haskell. It's also not a question about "add"

    – codeshot
    Nov 16 '18 at 8:56















1















I'm learning Haskell, and attempting to understand lists.



From researching, to add an element to a list, you would normally do:



let numbers = [4,8,15,16,23,42] 
numbers ++ [56]


but to quote this answer:




If you need to do this, there is usually a better way to structure
your algorithm. For example, you can build your list in reverse order
(adding elements at the beginning) and only call reverse at the end.




Code:



let numbers = [23,43,56]
let newNumbers = 69:numbers
reverse newNumbers


Output:



[56,43,23,69]


Question:



  1. Is the code I've written correct according to the quoted answer?

  2. I want to understand the terminology a little better, can I say I'm adding elements to the head of the list? From my understanding, every new element would be the first element, and the value returned when I write head newNumbers.









share|improve this question
























  • It doesn't mean "call reverse after you prepend each itme"; that's no better than using ++ to append the item. Instead, it means that if you want to build up a list by adding new items to the end, you should put them at the beginning instead, and call reverse once it is time to consume the entire list.

    – chepner
    Nov 15 '18 at 16:27











  • @chepner - So in this case, if I wanted to just add 69 to the list, have I done it correctly in accordance with the quote? Which also makes me wonder, how would you add more than one element to the beginning of the list? Guess that's another exercise to try out.

    – user10641593
    Nov 15 '18 at 16:30












  • It really depends on how you intend to use the list. See my answer for an example.

    – chepner
    Nov 15 '18 at 16:55











  • There are times you must definitelly append a list to another list and to make it worse you may need to append new lists to the resulting one several thousands of times. This will be a very costly operation. To overcome this cost difference list data structures are used. This question is all about that

    – Redu
    Nov 15 '18 at 17:06












  • This isn't really a question about haskell, it's a question about a stackoverflow question. Adding the tag makes it harder to find questions about haskell. It's also not a question about "add"

    – codeshot
    Nov 16 '18 at 8:56













1












1








1








I'm learning Haskell, and attempting to understand lists.



From researching, to add an element to a list, you would normally do:



let numbers = [4,8,15,16,23,42] 
numbers ++ [56]


but to quote this answer:




If you need to do this, there is usually a better way to structure
your algorithm. For example, you can build your list in reverse order
(adding elements at the beginning) and only call reverse at the end.




Code:



let numbers = [23,43,56]
let newNumbers = 69:numbers
reverse newNumbers


Output:



[56,43,23,69]


Question:



  1. Is the code I've written correct according to the quoted answer?

  2. I want to understand the terminology a little better, can I say I'm adding elements to the head of the list? From my understanding, every new element would be the first element, and the value returned when I write head newNumbers.









share|improve this question
















I'm learning Haskell, and attempting to understand lists.



From researching, to add an element to a list, you would normally do:



let numbers = [4,8,15,16,23,42] 
numbers ++ [56]


but to quote this answer:




If you need to do this, there is usually a better way to structure
your algorithm. For example, you can build your list in reverse order
(adding elements at the beginning) and only call reverse at the end.




Code:



let numbers = [23,43,56]
let newNumbers = 69:numbers
reverse newNumbers


Output:



[56,43,23,69]


Question:



  1. Is the code I've written correct according to the quoted answer?

  2. I want to understand the terminology a little better, can I say I'm adding elements to the head of the list? From my understanding, every new element would be the first element, and the value returned when I write head newNumbers.






list haskell reverse






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 16 '18 at 17:49

























asked Nov 15 '18 at 16:21







user10641593



















  • It doesn't mean "call reverse after you prepend each itme"; that's no better than using ++ to append the item. Instead, it means that if you want to build up a list by adding new items to the end, you should put them at the beginning instead, and call reverse once it is time to consume the entire list.

    – chepner
    Nov 15 '18 at 16:27











  • @chepner - So in this case, if I wanted to just add 69 to the list, have I done it correctly in accordance with the quote? Which also makes me wonder, how would you add more than one element to the beginning of the list? Guess that's another exercise to try out.

    – user10641593
    Nov 15 '18 at 16:30












  • It really depends on how you intend to use the list. See my answer for an example.

    – chepner
    Nov 15 '18 at 16:55











  • There are times you must definitelly append a list to another list and to make it worse you may need to append new lists to the resulting one several thousands of times. This will be a very costly operation. To overcome this cost difference list data structures are used. This question is all about that

    – Redu
    Nov 15 '18 at 17:06












  • This isn't really a question about haskell, it's a question about a stackoverflow question. Adding the tag makes it harder to find questions about haskell. It's also not a question about "add"

    – codeshot
    Nov 16 '18 at 8:56

















  • It doesn't mean "call reverse after you prepend each itme"; that's no better than using ++ to append the item. Instead, it means that if you want to build up a list by adding new items to the end, you should put them at the beginning instead, and call reverse once it is time to consume the entire list.

    – chepner
    Nov 15 '18 at 16:27











  • @chepner - So in this case, if I wanted to just add 69 to the list, have I done it correctly in accordance with the quote? Which also makes me wonder, how would you add more than one element to the beginning of the list? Guess that's another exercise to try out.

    – user10641593
    Nov 15 '18 at 16:30












  • It really depends on how you intend to use the list. See my answer for an example.

    – chepner
    Nov 15 '18 at 16:55











  • There are times you must definitelly append a list to another list and to make it worse you may need to append new lists to the resulting one several thousands of times. This will be a very costly operation. To overcome this cost difference list data structures are used. This question is all about that

    – Redu
    Nov 15 '18 at 17:06












  • This isn't really a question about haskell, it's a question about a stackoverflow question. Adding the tag makes it harder to find questions about haskell. It's also not a question about "add"

    – codeshot
    Nov 16 '18 at 8:56
















It doesn't mean "call reverse after you prepend each itme"; that's no better than using ++ to append the item. Instead, it means that if you want to build up a list by adding new items to the end, you should put them at the beginning instead, and call reverse once it is time to consume the entire list.

– chepner
Nov 15 '18 at 16:27





It doesn't mean "call reverse after you prepend each itme"; that's no better than using ++ to append the item. Instead, it means that if you want to build up a list by adding new items to the end, you should put them at the beginning instead, and call reverse once it is time to consume the entire list.

– chepner
Nov 15 '18 at 16:27













@chepner - So in this case, if I wanted to just add 69 to the list, have I done it correctly in accordance with the quote? Which also makes me wonder, how would you add more than one element to the beginning of the list? Guess that's another exercise to try out.

– user10641593
Nov 15 '18 at 16:30






@chepner - So in this case, if I wanted to just add 69 to the list, have I done it correctly in accordance with the quote? Which also makes me wonder, how would you add more than one element to the beginning of the list? Guess that's another exercise to try out.

– user10641593
Nov 15 '18 at 16:30














It really depends on how you intend to use the list. See my answer for an example.

– chepner
Nov 15 '18 at 16:55





It really depends on how you intend to use the list. See my answer for an example.

– chepner
Nov 15 '18 at 16:55













There are times you must definitelly append a list to another list and to make it worse you may need to append new lists to the resulting one several thousands of times. This will be a very costly operation. To overcome this cost difference list data structures are used. This question is all about that

– Redu
Nov 15 '18 at 17:06






There are times you must definitelly append a list to another list and to make it worse you may need to append new lists to the resulting one several thousands of times. This will be a very costly operation. To overcome this cost difference list data structures are used. This question is all about that

– Redu
Nov 15 '18 at 17:06














This isn't really a question about haskell, it's a question about a stackoverflow question. Adding the tag makes it harder to find questions about haskell. It's also not a question about "add"

– codeshot
Nov 16 '18 at 8:56





This isn't really a question about haskell, it's a question about a stackoverflow question. Adding the tag makes it harder to find questions about haskell. It's also not a question about "add"

– codeshot
Nov 16 '18 at 8:56












1 Answer
1






active

oldest

votes


















3














You need to distinguish between the linked list data structure and whatever list-like data type you are implementing with the linked list. You can do exactly two things to modify a linked list: prepend a new head to the list, and remove the current head (if the linked list isn't empty).



The use case the quote talks about is common for a queue data type: you can add to one end and remove from the other end. You can implement this using two linked lists, by adding new elements to one list and removing elements from the other. The implementation of the queue takes care of reversing as necessary to ensure that you never remove an item before every other item inserted previously is removed.



data Queue a = Queue [a] [a]

-- Put new elements on the incoming list.
addToQueue :: a -> Queue a -> Queue a
addToQueue x (Queue incoming outgoing) = Queue (x:incoming) outgoing

-- Take elements from the outgoing list, whose elements are stored
-- in the reverse order that they were added to the incoming list
-- previously.
removeFromQueue :: Queue a -> (a, Queue a)
removeFromQueue (Queue ) = error "Cannot remove from empty queue"
removeFromQueue (Queue incoming (x:xs)) = (x, Queue incoming xs)
removeFromQueue (Queue incoming ) = removeFromQueue (Queue (reverse incoming))


(We're not concerned with good ways to deal with removing from an empty queue here; just call it an error and leave it at that.)



Adding to the incoming list and removing from the outgoing list is easy. The tricky part is how and when we transfer items from the incoming list to the outgoing list. We only do so when the outgoing list is empty, and when it is, we transfer the entire incoming list at once, reversing it in the process. In other words, we're building up the incoming list in reverse,
but only ever reverse it when necessary, not after each and every single item is added.



Amortized analysis can be used to show that although reverse could be slow, it is balanced by the number of fast operations that precede and can follow it.






share|improve this answer

























  • The sharp-eyed reader might notice I left out a peek :: Queue a -> a function. Ensuring that a series of peek operations doesn't have to repeatedly scan through the incoming list when the outgoing list is empty complicates the other two functions in ways I didn't want to deal with for this answer. The solution is to ensure that neither addToQueue nor removeFromQueue can return a queue whose outgoing list is empty.

    – chepner
    Nov 15 '18 at 17:06












  • (Unless the queue itself is empty, that is.)

    – chepner
    Nov 15 '18 at 19:56











  • The amortized analysis of that queue only holds up when the queue is used ephemerally. In a persistent application, the rotations need to be done somewhat differently.

    – dfeuer
    Nov 15 '18 at 21:28










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53323747%2fadding-an-element-to-a-list-and-then-reverse-it%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown
























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














You need to distinguish between the linked list data structure and whatever list-like data type you are implementing with the linked list. You can do exactly two things to modify a linked list: prepend a new head to the list, and remove the current head (if the linked list isn't empty).



The use case the quote talks about is common for a queue data type: you can add to one end and remove from the other end. You can implement this using two linked lists, by adding new elements to one list and removing elements from the other. The implementation of the queue takes care of reversing as necessary to ensure that you never remove an item before every other item inserted previously is removed.



data Queue a = Queue [a] [a]

-- Put new elements on the incoming list.
addToQueue :: a -> Queue a -> Queue a
addToQueue x (Queue incoming outgoing) = Queue (x:incoming) outgoing

-- Take elements from the outgoing list, whose elements are stored
-- in the reverse order that they were added to the incoming list
-- previously.
removeFromQueue :: Queue a -> (a, Queue a)
removeFromQueue (Queue ) = error "Cannot remove from empty queue"
removeFromQueue (Queue incoming (x:xs)) = (x, Queue incoming xs)
removeFromQueue (Queue incoming ) = removeFromQueue (Queue (reverse incoming))


(We're not concerned with good ways to deal with removing from an empty queue here; just call it an error and leave it at that.)



Adding to the incoming list and removing from the outgoing list is easy. The tricky part is how and when we transfer items from the incoming list to the outgoing list. We only do so when the outgoing list is empty, and when it is, we transfer the entire incoming list at once, reversing it in the process. In other words, we're building up the incoming list in reverse,
but only ever reverse it when necessary, not after each and every single item is added.



Amortized analysis can be used to show that although reverse could be slow, it is balanced by the number of fast operations that precede and can follow it.






share|improve this answer

























  • The sharp-eyed reader might notice I left out a peek :: Queue a -> a function. Ensuring that a series of peek operations doesn't have to repeatedly scan through the incoming list when the outgoing list is empty complicates the other two functions in ways I didn't want to deal with for this answer. The solution is to ensure that neither addToQueue nor removeFromQueue can return a queue whose outgoing list is empty.

    – chepner
    Nov 15 '18 at 17:06












  • (Unless the queue itself is empty, that is.)

    – chepner
    Nov 15 '18 at 19:56











  • The amortized analysis of that queue only holds up when the queue is used ephemerally. In a persistent application, the rotations need to be done somewhat differently.

    – dfeuer
    Nov 15 '18 at 21:28















3














You need to distinguish between the linked list data structure and whatever list-like data type you are implementing with the linked list. You can do exactly two things to modify a linked list: prepend a new head to the list, and remove the current head (if the linked list isn't empty).



The use case the quote talks about is common for a queue data type: you can add to one end and remove from the other end. You can implement this using two linked lists, by adding new elements to one list and removing elements from the other. The implementation of the queue takes care of reversing as necessary to ensure that you never remove an item before every other item inserted previously is removed.



data Queue a = Queue [a] [a]

-- Put new elements on the incoming list.
addToQueue :: a -> Queue a -> Queue a
addToQueue x (Queue incoming outgoing) = Queue (x:incoming) outgoing

-- Take elements from the outgoing list, whose elements are stored
-- in the reverse order that they were added to the incoming list
-- previously.
removeFromQueue :: Queue a -> (a, Queue a)
removeFromQueue (Queue ) = error "Cannot remove from empty queue"
removeFromQueue (Queue incoming (x:xs)) = (x, Queue incoming xs)
removeFromQueue (Queue incoming ) = removeFromQueue (Queue (reverse incoming))


(We're not concerned with good ways to deal with removing from an empty queue here; just call it an error and leave it at that.)



Adding to the incoming list and removing from the outgoing list is easy. The tricky part is how and when we transfer items from the incoming list to the outgoing list. We only do so when the outgoing list is empty, and when it is, we transfer the entire incoming list at once, reversing it in the process. In other words, we're building up the incoming list in reverse,
but only ever reverse it when necessary, not after each and every single item is added.



Amortized analysis can be used to show that although reverse could be slow, it is balanced by the number of fast operations that precede and can follow it.






share|improve this answer

























  • The sharp-eyed reader might notice I left out a peek :: Queue a -> a function. Ensuring that a series of peek operations doesn't have to repeatedly scan through the incoming list when the outgoing list is empty complicates the other two functions in ways I didn't want to deal with for this answer. The solution is to ensure that neither addToQueue nor removeFromQueue can return a queue whose outgoing list is empty.

    – chepner
    Nov 15 '18 at 17:06












  • (Unless the queue itself is empty, that is.)

    – chepner
    Nov 15 '18 at 19:56











  • The amortized analysis of that queue only holds up when the queue is used ephemerally. In a persistent application, the rotations need to be done somewhat differently.

    – dfeuer
    Nov 15 '18 at 21:28













3












3








3







You need to distinguish between the linked list data structure and whatever list-like data type you are implementing with the linked list. You can do exactly two things to modify a linked list: prepend a new head to the list, and remove the current head (if the linked list isn't empty).



The use case the quote talks about is common for a queue data type: you can add to one end and remove from the other end. You can implement this using two linked lists, by adding new elements to one list and removing elements from the other. The implementation of the queue takes care of reversing as necessary to ensure that you never remove an item before every other item inserted previously is removed.



data Queue a = Queue [a] [a]

-- Put new elements on the incoming list.
addToQueue :: a -> Queue a -> Queue a
addToQueue x (Queue incoming outgoing) = Queue (x:incoming) outgoing

-- Take elements from the outgoing list, whose elements are stored
-- in the reverse order that they were added to the incoming list
-- previously.
removeFromQueue :: Queue a -> (a, Queue a)
removeFromQueue (Queue ) = error "Cannot remove from empty queue"
removeFromQueue (Queue incoming (x:xs)) = (x, Queue incoming xs)
removeFromQueue (Queue incoming ) = removeFromQueue (Queue (reverse incoming))


(We're not concerned with good ways to deal with removing from an empty queue here; just call it an error and leave it at that.)



Adding to the incoming list and removing from the outgoing list is easy. The tricky part is how and when we transfer items from the incoming list to the outgoing list. We only do so when the outgoing list is empty, and when it is, we transfer the entire incoming list at once, reversing it in the process. In other words, we're building up the incoming list in reverse,
but only ever reverse it when necessary, not after each and every single item is added.



Amortized analysis can be used to show that although reverse could be slow, it is balanced by the number of fast operations that precede and can follow it.






share|improve this answer















You need to distinguish between the linked list data structure and whatever list-like data type you are implementing with the linked list. You can do exactly two things to modify a linked list: prepend a new head to the list, and remove the current head (if the linked list isn't empty).



The use case the quote talks about is common for a queue data type: you can add to one end and remove from the other end. You can implement this using two linked lists, by adding new elements to one list and removing elements from the other. The implementation of the queue takes care of reversing as necessary to ensure that you never remove an item before every other item inserted previously is removed.



data Queue a = Queue [a] [a]

-- Put new elements on the incoming list.
addToQueue :: a -> Queue a -> Queue a
addToQueue x (Queue incoming outgoing) = Queue (x:incoming) outgoing

-- Take elements from the outgoing list, whose elements are stored
-- in the reverse order that they were added to the incoming list
-- previously.
removeFromQueue :: Queue a -> (a, Queue a)
removeFromQueue (Queue ) = error "Cannot remove from empty queue"
removeFromQueue (Queue incoming (x:xs)) = (x, Queue incoming xs)
removeFromQueue (Queue incoming ) = removeFromQueue (Queue (reverse incoming))


(We're not concerned with good ways to deal with removing from an empty queue here; just call it an error and leave it at that.)



Adding to the incoming list and removing from the outgoing list is easy. The tricky part is how and when we transfer items from the incoming list to the outgoing list. We only do so when the outgoing list is empty, and when it is, we transfer the entire incoming list at once, reversing it in the process. In other words, we're building up the incoming list in reverse,
but only ever reverse it when necessary, not after each and every single item is added.



Amortized analysis can be used to show that although reverse could be slow, it is balanced by the number of fast operations that precede and can follow it.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 15 '18 at 17:00

























answered Nov 15 '18 at 16:52









chepnerchepner

258k34249343




258k34249343












  • The sharp-eyed reader might notice I left out a peek :: Queue a -> a function. Ensuring that a series of peek operations doesn't have to repeatedly scan through the incoming list when the outgoing list is empty complicates the other two functions in ways I didn't want to deal with for this answer. The solution is to ensure that neither addToQueue nor removeFromQueue can return a queue whose outgoing list is empty.

    – chepner
    Nov 15 '18 at 17:06












  • (Unless the queue itself is empty, that is.)

    – chepner
    Nov 15 '18 at 19:56











  • The amortized analysis of that queue only holds up when the queue is used ephemerally. In a persistent application, the rotations need to be done somewhat differently.

    – dfeuer
    Nov 15 '18 at 21:28

















  • The sharp-eyed reader might notice I left out a peek :: Queue a -> a function. Ensuring that a series of peek operations doesn't have to repeatedly scan through the incoming list when the outgoing list is empty complicates the other two functions in ways I didn't want to deal with for this answer. The solution is to ensure that neither addToQueue nor removeFromQueue can return a queue whose outgoing list is empty.

    – chepner
    Nov 15 '18 at 17:06












  • (Unless the queue itself is empty, that is.)

    – chepner
    Nov 15 '18 at 19:56











  • The amortized analysis of that queue only holds up when the queue is used ephemerally. In a persistent application, the rotations need to be done somewhat differently.

    – dfeuer
    Nov 15 '18 at 21:28
















The sharp-eyed reader might notice I left out a peek :: Queue a -> a function. Ensuring that a series of peek operations doesn't have to repeatedly scan through the incoming list when the outgoing list is empty complicates the other two functions in ways I didn't want to deal with for this answer. The solution is to ensure that neither addToQueue nor removeFromQueue can return a queue whose outgoing list is empty.

– chepner
Nov 15 '18 at 17:06






The sharp-eyed reader might notice I left out a peek :: Queue a -> a function. Ensuring that a series of peek operations doesn't have to repeatedly scan through the incoming list when the outgoing list is empty complicates the other two functions in ways I didn't want to deal with for this answer. The solution is to ensure that neither addToQueue nor removeFromQueue can return a queue whose outgoing list is empty.

– chepner
Nov 15 '18 at 17:06














(Unless the queue itself is empty, that is.)

– chepner
Nov 15 '18 at 19:56





(Unless the queue itself is empty, that is.)

– chepner
Nov 15 '18 at 19:56













The amortized analysis of that queue only holds up when the queue is used ephemerally. In a persistent application, the rotations need to be done somewhat differently.

– dfeuer
Nov 15 '18 at 21:28





The amortized analysis of that queue only holds up when the queue is used ephemerally. In a persistent application, the rotations need to be done somewhat differently.

– dfeuer
Nov 15 '18 at 21:28



















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53323747%2fadding-an-element-to-a-list-and-then-reverse-it%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







這個網誌中的熱門文章

What does pagestruct do in Eviews?

Dutch intervention in Lombok and Karangasem

Channel Islands