Adding an element to a list and then reverse it
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 yourlistin reverse order
(adding elements at the beginning) and only callreverseat the end.
Code:
let numbers = [23,43,56]
let newNumbers = 69:numbers
reverse newNumbers
Output:
[56,43,23,69]
Question:
- Is the code I've written correct according to the quoted answer?
- I want to understand the terminology a little better, can I say I'm adding elements to the
headof thelist? From my understanding, every new element would be the first element, and the value returned when I writehead newNumbers.
list haskell reverse
|
show 1 more comment
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 yourlistin reverse order
(adding elements at the beginning) and only callreverseat the end.
Code:
let numbers = [23,43,56]
let newNumbers = 69:numbers
reverse newNumbers
Output:
[56,43,23,69]
Question:
- Is the code I've written correct according to the quoted answer?
- I want to understand the terminology a little better, can I say I'm adding elements to the
headof thelist? From my understanding, every new element would be the first element, and the value returned when I writehead newNumbers.
list haskell reverse
It doesn't mean "callreverseafter 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 add69to 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
|
show 1 more comment
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 yourlistin reverse order
(adding elements at the beginning) and only callreverseat the end.
Code:
let numbers = [23,43,56]
let newNumbers = 69:numbers
reverse newNumbers
Output:
[56,43,23,69]
Question:
- Is the code I've written correct according to the quoted answer?
- I want to understand the terminology a little better, can I say I'm adding elements to the
headof thelist? From my understanding, every new element would be the first element, and the value returned when I writehead newNumbers.
list haskell reverse
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 yourlistin reverse order
(adding elements at the beginning) and only callreverseat the end.
Code:
let numbers = [23,43,56]
let newNumbers = 69:numbers
reverse newNumbers
Output:
[56,43,23,69]
Question:
- Is the code I've written correct according to the quoted answer?
- I want to understand the terminology a little better, can I say I'm adding elements to the
headof thelist? From my understanding, every new element would be the first element, and the value returned when I writehead newNumbers.
list haskell reverse
list haskell reverse
edited Nov 16 '18 at 17:49
asked Nov 15 '18 at 16:21
user10641593
It doesn't mean "callreverseafter 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 add69to 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
|
show 1 more comment
It doesn't mean "callreverseafter 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 add69to 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
|
show 1 more comment
1 Answer
1
active
oldest
votes
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.
The sharp-eyed reader might notice I left out apeek :: Queue a -> afunction. Ensuring that a series ofpeekoperations 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 neitheraddToQueuenorremoveFromQueuecan 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
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
The sharp-eyed reader might notice I left out apeek :: Queue a -> afunction. Ensuring that a series ofpeekoperations 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 neitheraddToQueuenorremoveFromQueuecan 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
add a comment |
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.
The sharp-eyed reader might notice I left out apeek :: Queue a -> afunction. Ensuring that a series ofpeekoperations 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 neitheraddToQueuenorremoveFromQueuecan 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
add a comment |
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.
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.
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 apeek :: Queue a -> afunction. Ensuring that a series ofpeekoperations 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 neitheraddToQueuenorremoveFromQueuecan 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
add a comment |
The sharp-eyed reader might notice I left out apeek :: Queue a -> afunction. Ensuring that a series ofpeekoperations 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 neitheraddToQueuenorremoveFromQueuecan 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
It doesn't mean "call
reverseafter 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
69to 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