Re: Discuss changing the behaviour of append()
- Posted by DerekParnell (admin) Jun 16, 2014
- 3601 views
Seriously, this continued treatment of atoms as one-member sequences in more and more instances will only add to confusion. Changing behavior of things is low lying fruit. In some cases this will break new users. In EUPHORIA 5 != {5} but the standard library and builtins more and more treat them as if they are the same.
I understand your concern, Shawn. I can see why one might come to this conclusion. So please indulge me to explain where I was coming from.
My proposed change is based around function-centric rather than data-centric thinking. Of course an atom is never a sequence. These datatypes are by definition mutually exclusive. However, I was thinking more along the lines of the activity that append()/prepend() is trying to do, the end result of its endeavours. Namely, add a single object to something to form a list. Currently that 'something' must be an existing list, and all I want to do is expand its usefulness to allow 'something' to be any object. The functionality of append()/prepend() would remain identical.
For example: If you do a match_replace with 'a' you will replace 'a' in a word without complaints but if you are purposely replacing one character in a string you ought to use find_replace and this kind of distinction should be taught everywhere for consistency.
This is a good example ... but maybe not of what you were trying to show. To me this is a good example of poor function naming. The difference between 'find' and 'match' in English is extremely subtle and most people would actually use them interchangeably. Maybe its just me, but I've been burned by this a number of times until I finally learned the Euphoria meanings off-by-heart.
Maybe they should have been named like "locate_an_item_and_replace" and "locate_a_tuple_and_replace" ... well you get the picture ...
The find_replace() is problematic on a few levels anyway. Consider ...
result = find_replace('a', "This is a list of characters", "A") --> {'T','h','i','s', ' ', 'i', 's', ' ', {'A'}, ' ', 'l', 'i', 's', 't', ... etc }
find_replace() can be used to find a character and replace it with a word! Probably not was intended. And similarly with match_replace().
When you try to replace a word in a list of words using match_replace, you would get burned. The lazy conversion here causes people to use a function wrong and learn it wrong. The word wont be replaced in the word because it is comparing the word with lists of words. One might argue good programmers would never make this mistake, however.
Hmmm ... not so sure about that.
object word = "abc" object word_list = {"def", "abc", "ghi"} object new_word = "xyz" result = match_replace(word, word_list, new_word)
Of course, if word_list was initialized to "def,abc,ghi" then it would fail. But I'd argue (taking the data-centric view point), that is a list of characters and not a list of words 
If you are using a data structure which contains a list of numbers, you are not going initialize the list to one number. If you know what you are doing, you might initialize it to 0 to signal it is not yet setup and later initialize it with a sequence of numbers. Setting this list to a single atom is an accident and changing append such that it hides this kind of problem is a mistake.
Again, a good example. Especially of breaking the good programming design principle of never using a single data item to represent multiple concepts. A better design is to use two variables - one to indicate the state of the list and another for the actual list. But I digress ... ok, given this scenario, we have a program that doesn't check the state of the list before using it. That is to say, the program has a bug in it. Now consider, what if instead of append(), the program was using concatenate when using the list (because it needed to add multiple items rather than just one). In that case, the bug would still remain hidden. So should we consider changing concatenate to only add to sequences? It could be that, until learned, a new Euphoria programmer could assume that 1 & 2 & 3 gives 123 rather than {1,2,3}?
