1. Discuss changing the behaviour of append()

• Posted by DerekParnell (admin) Jun 07, 2014
• 4686 views

Currently this is illegal ...

sequence x 
 
x = append(1,2) 

We get the error message ...

first argument of append must be a sequence 

sequence x 
 
x = 1 & 2 -- No error. Creates {1,2} 

In my current code, I ran across this case and had to code an explicit test to get around it. This is 'ugly' and makes the code a bit slower and larger.

function F(object A, object B) 
sequence x 
    if atom(A) then 
        x = append({A}, B) 
    else 
        x = append(A, B) 
    end if 
    return x 
end function 

3. Re: Discuss changing the behaviour of append()

• Posted by ghaberek (admin) Jun 07, 2014
• 4654 views

This seems like an innocuous and intuitive change. You have my vote.

-Greg

5. Re: Discuss changing the behaviour of append()

• Posted by gimlet Jun 07, 2014
• 4591 views

Simple answer: not such a good idea.

The function append is:

   fn(seq, obj) -> seq 

The proposed change would require that append be

   fn(obj, obj) -> seq 

It would seem that append is wanted most often when the first parameter is a sequence....

As to the code being 'ugly' ..

function F(object A, object B) 
sequence x 
    if atom(A) then 
        x = append({A}, B) 
    else 
        x = append(A, B) 
    end if 
    return x 
end function 

try

function F(object A, object B) 
    if atom(A) then 
        A = {A] 
    end if 
    return append(A, B) 
end function 

or, ditching the function

sequence x 
if atom(A) then 
    x = append({A},B) 
else 
    x = append(A,B) 
end if    

7. Re: Discuss changing the behaviour of append()

• Posted by PeteE Jun 07, 2014
• 4564 views

oops, double post

9. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 08, 2014
• 4561 views

IIUC this is only the case using the interpreter. The translator does not seem to check.

Well, in general having a human readable error message is quite helpful. But for this to happen (and this generally doesn't happen with the translator btw), something needs to check somewhere.

Agreed, the language itself should do that validation. Which is what actually happens.

11. Re: Discuss changing the behaviour of append()

• Posted by SDPringle Jun 08, 2014
• 4570 views

I believe among new users or infrequent users, if a user passes an atom as a first argument to append, it is probably because they are accidentally reversing the order of the parameters and not because they want to treat atoms as length-one sequences that contain that atom.

13. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 08, 2014
• 4535 views

Um, wow.

That's a pretty good argument.

It's better to fail early than introduce a logic error which may not be caught until much much later.

If you are right, then users could be confused as to why append is starting to act like prepend.

That said, I still think this is unlikely to happen. It'd be inconsistent with the order of parameters in the basic math operators (e.g. subtraction and division) and concatenation.

15. Re: Discuss changing the behaviour of append()

• Posted by petelomax Jun 08, 2014
• 4513 views

I was just going to say something similar, in particular str=prepend(ch,str) has been nicely caught for me a few times, but to be honest if I know I'm adding an atom, I'll use &, and if I'm adding a sequence, the extra type check helps not one tiny bit.

However, I would like to suggest appenda() [and prependa], see what people have to say about that. Or maybe appendany()/prependany() if you prefer.

Pete

Edit: "Why must append have a sequence as the first parameter and concatenate doesn't?"
That certainly hits the nail on the head. Apart from "trying to be helpful but not really managing it", I got no answer to that.

17. Re: Discuss changing the behaviour of append()

• Posted by gimlet Jun 09, 2014
• 4523 views

Derek,

I was aware of the (inconsistent?) behaviour of one element sequences. You can have append do what you want by calling append as:

     append(S[1..1], 2) -- coercing S[1] to a sequence 

Some clarification.

sequence S = {0,1,2,3} 
 
? length(S[1..0])     -- 0 
? sequence(S[1..0])   -- true 
? atom(S[1..0])       -- false 
 
? length(S[1..1])     -- 1 
? sequence(S[1..1])   -- true (slice coerces sequence type) 
? atom(S[1..1])       -- false 
 
? length(S[1])        -- 1 (odd!) 
? sequence(S[1])      -- false (odd!) 
? atom(S[1])          -- true 
 
? append(S[1..1],2)   -- {0,2} 
? append(S[1],2)      -- error 

19. Re: Discuss changing the behaviour of append()

• Posted by gimlet Jun 09, 2014
• 4463 views

I think the basic problem is that S[i] is not (fully) a sequence.

Every slice is a sequence,
S[i] has a length so it is a sequence,
Yet it can type as an atom.

It seems what you need here is an operator which 'converts' an atom to a sequence.

S[i] & {} -- would work as well as  
S[i..i]   -- but they are fixes 

but perhaps we need an explicit operator which minimises the cost of the operation.

I really don't think putting the burden on append is appropriate as you would need to do the same with other functions (prepend ..)
and
append has the right to expect a sequence as parameter
(otherwise why specify types at all?)

21. Re: Discuss changing the behaviour of append()

• Posted by ryanj Jun 09, 2014
• 4454 views

sequence x 
 
x = append(1,2) 

sequence x 
 
x = 1 & 2 -- No error. Creates {1,2} 

Why not just use & then? What's the advantage of append(), anyway? I don't think i ever use it.

23. Re: Discuss changing the behaviour of append()

• Posted by ArthurCrump Jun 09, 2014
• 4445 views

To suggest the same for prepend was not such a good idea.

There is unlikely to be any confusion appending a new object to an atom, but prepend has its operands in reverse order so that

x = prepend(1,2) 

would give x={2,1} if it was allowed.
That could be confusing

Arthur

25. Re: Discuss changing the behaviour of append()

• Posted by petelomax Jun 10, 2014
• 4390 views

flw

Erm, let's just agree that the arguments to prepend are in the same order as append, but of course the result is (sort of) the other way round

x = prepend(1,2) 

Hmm. You lost me there. Why exactly is that any more confusing than

x = prepend({1},2) 

giving x={2,1}?

Pete

27. Re: Discuss changing the behaviour of append()

• Posted by DerekParnell (admin) Jun 10, 2014
• 4396 views

S[i] & {} -- would work as well as  
S[i..i]   -- but they are fixes 

Unfortunately, this is NOT the issue. I'll restate the problem using different words.

Given an object X, I want to create a sequence by adding another object Y, such that the last item in the newly created sequence is Y, and all the other items in X are unaltered.

Examples ...

X = 4      Y = {8,9}  --Result is {4, {8,9}} 
X = {4}    Y = {8,9}  --Result is {4, {8,9}} 
X = {4,5}  Y = {8,9}  --Result is {4, 5, {8,9}} 
X = {}     Y = {8,9}  --Result is {{8,9}} 

In all but the first case, the append() function will suffice. But with the first case I need to convert X to a sequence first. That is what I'm hoping to avoid doing; the 'manually' conversion. Instead I'd like Euphoria to do it automatically.

The only suggestion so far that works in each of the case above is the 'concatenate a sequence' trick, but that has a performance hit of creating a temporary sequence and then disposing of it after the operation has completed. Something I'd also like to avoid.

object X, Y 
X = 4      Y = {8,9}  X &= {Y} --Result is {4, {8,9}} 
X = {4}    Y = {8,9}  X &= {Y} --Result is {4, {8,9}} 
X = {4,5}  Y = {8,9}  X &= {Y} --Result is {4, 5, {8,9}} 
X = {}     Y = {8,9}  X &= {Y} --Result is {{8,9}} 

So, if the change is made to Euphoria's append()/prepend() functions to do this, programs that now currently fail in this situation will no longer fail. Is that okay?

29. Re: Discuss changing the behaviour of append()

• Posted by kinzz Jun 10, 2014
• 4315 views

object X, Y 
X = 4      Y = {8,9}  X &= {Y} --Result is {4, {8,9}} 
X = {4}    Y = {8,9}  X &= {Y} --Result is {4, {8,9}} 
X = {4,5}  Y = {8,9}  X &= {Y} --Result is {4, 5, {8,9}} 
X = {}     Y = {8,9}  X &= {Y} --Result is {{8,9}} 

These append()/prepend() are for operations with sequences (in pure 20 years old EU).
So, if you do not have some sequence to operate with, just do not use append()/prepend().

Use & and be happy :)
Regards

31. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 10, 2014
• 4357 views

object X, Y 
X = 4      Y = {8,9}  X &= {Y} --Result is {4, {8,9}} 
X = {4}    Y = {8,9}  X &= {Y} --Result is {4, {8,9}} 
X = {4,5}  Y = {8,9}  X &= {Y} --Result is {4, 5, {8,9}} 
X = {}     Y = {8,9}  X &= {Y} --Result is {{8,9}} 

object X, Y 
X = 4      Y = {8,9}  -- what operation do I need to form {4, 8, 9}? 
X = {4, 5} Y = {8,9}  -- what operation do I need to form {4, 5, 8, 9}? 
X = "foo"  Y = "bar"  -- what operation do I need to form "foobar"? 

It's like this:

object X, Y 
X = 4      Y = {8,9}  X &= Y --Result is {4, 8, 9} 
X = 4      Y = {8,9}  X &= {Y} --Result is {4, {8,9}} 
X = {4}    Y = {8,9}  X &= Y --Result is {4, 8, 9} 
X = {4}    Y = {8,9}  X &= {Y} --Result is {4, {8,9}} 
X = {4,5}  Y = {8,9}  X &= Y --Result is {4, 5, 8, 9} 
X = {4,5}  Y = {8,9}  X &= {Y} --Result is {4, 5, {8,9}} 
X = "foo"  Y = "bar"  X &= Y --Result is "foobar" 
X = "foo"  Y = "bar"  X &= {Y} --Result is NOT "foobar" 

Basically, if you combine the concatenation operator with the new sequence operation, you've got a more expensive version of append.

33. Re: Discuss changing the behaviour of append()

• Posted by mindwalker Jun 10, 2014
• 4312 views

I don't have any horses in this race, but that has never stopped me from cheering.

Basically Derek states he has a need in some code he is writing to append an object to another object and that the append function currently is designed as a sequence operator requiring a sequence as the first parameter (from "4.1.4.9 Other Operations on Sequences" in the manual).

sequence x 
 
x = append(1,2) 

first argument of append must be a sequence 

Then he states.

function F(object A, object B) 
sequence x 
    if atom(A) then 
        x = append({A}, B) 
    else 
        x = append(A, B) 
    end if 
    return x 
end function 

His suggestion is to replace the append sequence function with an append object function which is essentially the F function that he discribed as "This is 'ugly' and makes the code a bit slower and larger". This of course saddles all OpenEuphoria programmers with this 'ugly', slower, larger functionality leaving his code no better off (except the code is hidden in the language now).

When I don't have any horses in a race I sometimes switch which horse I am cheering for (I cheer the underdog if there appears to be any chance).

In my opinion, one of the strengths of the Euphoria language is not having overloaded functions or multiple functions that all do the same basic thing but take different data types as parameters.

Viewed from that perspective, Derek's function becomes the appropriate append function which will work for all data types.

But the question is will this change break someone's program. Could someone have depended on the append function to detect when the first parameter is an atom and to stop the program in that case.

I guess that depends on when/how the error is currently detected. Can one call append(obj1, obj2) and when obj1 has a sequence assigned to it the function works and when an atom is assigned it fails? Or does the processor realize (say in a first pass) that obj1 is defined as an object variable not a sequence and throws the error irregardless of what is ultimately assigned to the variable?

In the second scenario changing horses will have no ill affects since the error detection would have resulted in the programmer changing obj1 into a sequence variable in order to get the program to run.

But in the first scenario it is possible someone's code will be affected if they choose to migrate their program to using the newest version of OpenEuphoria. When a large program written several years ago gets update to a newer version of a language, the initial assumptions and dependancies aren't always remembered (may not even be the same programmer). So this makes this kind of a change possibly serious. If some programmer was foolish enough to depend on the append function to detect corrupt data, the down stream data could become further corrupted when the program starts "working" instead of aborting.

Of course other languages handle this by producing thousands of pages of release notes with a one liner buried somewhere in the middle that reads something like: The append function has been modified (see manual for details).

35. Re: Discuss changing the behaviour of append()

• Posted by _tom (admin) Jun 10, 2014
• 4276 views

Here is my first draft at documenting the proposed changes.

_tom

Sequence Manipulations

The length function "counts top level items and returns the count as a length value." Nested items are not part of the top level count. (Counting is as good as measuring a length. To get the width of a road count the number of steps you take to get across.)

? length( {} ) 
    --> 0 
? length( 4 ) 
    --> 1 
? length( {4,5,"hello"} ) 
    --> 3 

You can argue that an atom (a number or character) has no length. It is convenient to recognize that an atom adds one to the length of a sequence after a prepend, append, or concatenation.

You can not use length to distinguish an atom from a sequence.

There are various ways to increase the length of an object:

• The coarse-grained functions (prepend, append) increase length by exactly one.
• The fine-grained operator (&) increases length by the length of the object added.

In a few cases a function or the concatenation operator can be used to produce identical results. However, there are significant differences most of the time.

Number and text data behave the same way.

Length Increasing Functions

The prepend function "adds one entire object to the head of the target object." The append function "adds one entire object to the tail of the target object."

Coarse-grained means "the entire object is added as one item."

It is idiomatic in Euphoria to write these functions so the first argument is the target and the second argument is what gets added.

To change a target variable you have to explicitly assign the new value to it:

x = prepend(x, new_item ) 
 
x = append(x, new_item  ) 

? prepend(5, {})
-->  {{}, 5} 

? append(5, {})
-->     {5, {}} 

? prepend(5, 6)
-->   {6, 5} 

? append(5, 6)
-->     {5, 6} 

? prepend(5,{6} )
--> {{6}, 5} 

? append(5, {6})
-->     {5, {6}} 

?   prepend(5, {6,7})
--> {{6,7}, 5} 

? append(5, {6,7})
-->     {5, {6,7}} 

? prepend({4,5}, {})
-->   {{}, 4,5} 

?   append({4,5}, {})
-->        {4,5,  {}} 

? prepend({4,5}, 6)
-->    {6, 4,5} 

? append({4,5}, 6)
-->      {4,5,  6} 

? prepend({4,5},{6})
-->  {{6}, 4,5} 

? append({4.5}, {6})
-->      {4,5,  {6}} 

?  prepend({4,5}, {6,7})
--> {{6,7}, 4,5} 

? append({4,5}, {6,7})
-->      {4,5,  {6,7}} 

Length Increasing Operator &

The concatenation operator & "increases the length of the target object by the length of the object added."

Fine-grained means "all items are added."

? {} & 5
-->    5 

?   5 & {}
--> 5 

?  6 & 5
--> {6,5} 

?    5 & 6
--> {5,6} 

?  {6} & 5
-->   {6,5} 

?    5 & {6}
--> {5,6} 

? {6,7} & 5
-->  {6,7,5} 

?   5 & {6,7}
--> {5,6,7} 

? {} & {4,5}
-->    {4,5} 

?   {4,5} & {}
--> {4,5} 

?  6 & {4,5}
-->  {6,4,5} 

?   {4,5} & 6
--> {4,5,6} 

?  {6} & {4,5}
-->    {6,4,5} 

?   {4,5} & {6}
--> {4,5,6} 

? {6,7} & {4,5}
-->   {6,7,4,5} 

?    {4,5} & {6,7}
-->  {4,5,6,7} 

Idiomatic Concatenation

You can combine the concatenation & operator with the assignment = statement.

object x=5, y=6 
x &= y 
? x 
--> {5,6} 
 
x &= y    -- short form 
x = x & y -- long form  

One use for the &= shortcut is to make concatenation & behave like an append function:

object x, y 
x &= {y} 

x -->

x &= {y}

x = append(x,y)

x --> {5,{}}

x --> {5,6}

x --> {5,{6}}

x --> {5,{6,7}}

x --> {4,5,{}}

x --> {4,5,6}

x --> {4,5,{6}}

x --> {4,5,{6,7}}

Legacy Notes

Early versions (O[ 3.1 and before) of length did not recognize the length of an atom as one.

Early versions (O[ 4.0 and before) of prepend and append would not allow the target to be an atom.

See Also

insert, splice, remove

37. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 11, 2014
• 4236 views

Okay, what was the wrong logic bug?

It's still slower, as F() has to make the check for a sequence and then append() will that check a second time. Why not consolidate these two into a single check?

Let's remember, length() works on atoms. It's append() (and prepend()) that's inconsistent here.

39. Re: Discuss changing the behaviour of append()

• Posted by jaygade Jun 11, 2014
• 4170 views

Tom:

I think your documentation is a bit verbose. I like your simple explanation that append() and prepend() return an object whose length is exactly one greater than their first operand, whereas the concatenation operator & returns an object whose length is the sum of the lengths of its two operands.

The "fine grained" and "coarse grained" bits are confusing. Just call & the "concatenation operator". Then give a few (three) examples for each append(), prepend(), and &.

41. Re: Discuss changing the behaviour of append()

• Posted by kinzz Jun 11, 2014
• 4186 views

Yes, seriously, sorry...

There is no the normal append() call in your function now...

That bug was fixed thanks to old good append().
No?

Regards

43. Re: Discuss changing the behaviour of append()

• Posted by mindwalker Jun 11, 2014
• 4105 views

Since append currently works the way I thought I remembered it did, I disagree Pete with your statement. The proposed change could break a working program.

For example a program could be designed to read in a text file, one line at a time, where each line in the file is supposed to start with a sequence followed by 3 atoms. Think customer information followed by an item number, item count and the item price. The program might be intended to add the item number to the end of the sequence and then compute the total charge and add that to the sequence and then store that sequence to a data base as a transaction.

That program make use of an included, company developed, generic file read function designed to read files containing text strings that represent euphoria sequences and text strings that represent individual atoms. That function could return a sequence of objects based on what was read (some sequences and some atoms).

Of course someone using this generic read function would want to verify the returned line items were the right type and order. And a program such as the one I propose might be designed to just stop if the input doesn't follow the right format (the concept of "do no more harm" and let a human figure out how to fix the problem).

So some "slick" programmer may have realized that the first append would abort if the first object in the line wasn't a sequence. So said programmer may have skipped the separate sequence test and depended on the append function working as documented.

Five years of running this program every hour 24x7x365 and only 3 aborts when the input file was corrupted one way or another and the company decides to stop using Euphoria 2.4 and move to the latest and greatest OpenEuphoria.

At this point, the previously working as designed program would be broken. It would no longer be detecting and aborting if the first line item wasn't a sequence. That is unless the programmer migrating this just happens to remember/realize that the append function was providing this sequence check and modifies the program to now do its own check instead.

45. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 11, 2014
• 4090 views

Ok, I see the reasoning.

But, I disagree - append() is wrong, not the code.

Yes, he was forced to. Because append() is wrong.

Yes, indeed. You make a good point here.

47. Re: Discuss changing the behaviour of append()

• Posted by DerekParnell (admin) Jun 11, 2014
• 4076 views

You sir, are have a very effective trolling skill.
I didn't show you my failing code because I assumed you had the required Euphoria skills to see when the use of append() would cause the issue first described. My mistake.

Can you point out where there are any logic errors in this function or discussion of mine, please.

The code I posted earlier was the working code. My first attempt at this function used the append() function but that failed at times, due to it trying to append to an atom.

Instead of ...

S[I[1]] &= {X} 

my original function had

integer n = I[1] 
S[n] = append(S[n], X) 

This fails when the item at S[n] is an atom. I then changed my code to explicitly test for that condition ...

integer n = I[1] 
if atom(S[n]) then 
    S[n] = append({S[n]}, X) 
else 
    S[n] = append(S[n], X) 
end if 

At which point I posted my original question. I have now changed my function to use the concatenation operator to get around the shortcoming in append(), but my suggestion about changing the append() function's behaviour still stands.

49. Re: Discuss changing the behaviour of append()

• Posted by DerekParnell (admin) Jun 11, 2014
• 4094 views

Ugh! No, please.

We would have append()/prepend() when the first argument must only be a sequence and appenda()/prependa() when the first argument can be any object. That arrangement, I predict, would be more confusing and more likely to introduce errors in code, plus people would tend to just use the newer functions anyway.

51. Re: Discuss changing the behaviour of append()

• Posted by mindwalker Jun 11, 2014
• 4044 views

I wasn't arguing the merits of a particular programming choice. There probably are a thousand better ways to do this. I was arguing that the change could break a working program and gave a hypothetical program scenario to illustrate.

Actually for me Pete Lomax's suggestion is the one I would find least favorable. It is a step in the direction C and so many other languages have gone. The language becomes more complicated and harder to learn since there would be a sequence append and then a new objects append. Newbies would be trying to determine when each should be used, not realizing that they could use appenda in all cases and would never really need the old append.

I think in the end I like Derek's suggestion. But it does have the potential to break existing programs in subtle ways. I would suggest that the release notes should make a big deal about this change and maybe even the manual as well, so that anyone migrating from earlier versions has some chance of recognizing the potetial problem.

53. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 11, 2014
• 4122 views

But it's not a good idea to just label it that way. Agreed. This reminds me of Linus Torvald's rule: http://felipec.wordpress.com/2013/10/07/the-linux-way/

I.e. rare, unexpected cases. Gotcha. (Of course, you can simulate a power outage (pull the power cord out) or a network failure (unplug your hub/switch), but there's probably always something else that'll trip things up .. eventually. You can't think of everything.)

Yes, in the real world ppl sometimes take shortcuts. Agreed.

Agreed. Still, relying on a program to complete crash in an ungraceful way is kind of unusual and must be rare. I agree with you - it should be ok to make the change to append() (as you agreed), but we should document it well (like we did with the change to length()).

55. Re: Discuss changing the behaviour of append()

• Posted by gimlet Jun 12, 2014
• 4089 views

This can (and should) be applied to functions.

A[i] can be a sequence or an atom.\\ 
                 append(A[i],x) : sequence : OK\\ 
                 atom : How do you want to see it? (atom or sequence)? 

A[i..i] is a sequence
A[i..i-1] ditto
A{i..i-2] is rubbish

At some point here I am losing you.

57. Re: Discuss changing the behaviour of append()

• Posted by DerekParnell (admin) Jun 12, 2014
• 4075 views

I hold a contrary opinion. In the general case, a function should not be required to validate its arguments. I understand that this sounds almost heretical to many, but let me explain.

A function can not know if the values in its arguments originated from outside the program or internally. In a well-behaved program, data coming into the application will be validated prior to it being used, and usually at the point at which it can give the most meaningful error/warning message to the end user. Calling a function with arguments is defined as data usage. Also, in a well-behaved program, data generated by the program will be correct, and this will be proven by appropriate logic testing during the development stage prior to its live release.

I believe that a routine should assume that it is operating inside a well-behaving program. Thus it will not be required to ensure that its arguments, or any shared program data, are valid. The program will have already done that so there's no need to do it again. However, any data that a function creates and makes available to other code, should be validated by that function. This needs only to be done while in development mode.

At this point I need to talk a bit about "what is valid data?" In general terms, its the set of values that a routine can reasonably be expected to operate on.

For example, consider this function to calculate the real 'X' value for a quadratic equation, which is defined as ... aX² + bX + c = 0 . For any given quadratic equation, the X can have zero, one or two values which solves the equation. Thus the function should return a sequence of 0, 1, or 2 elements.

The formula that the function needs to evaluate is ...

X₁ = (-b - sqrt(b² - 4ac)) / 2a and X₂ = (-b + sqrt(b² - 4ac)) / 2a

The first thing to note is what should the function do if a=0? If it doesn't check then the program will fail with a divide-by-zero error. If it does check, then its also admitting that the calling program is trying to use the function in an illogical manner. By definition, if a=0 then the equation is no longer a quadratic one but a linear one, and this function is only supposed to be used for quadratics.

I maintain that it's the calling program's responsibility to do the checking of a before calling the function, because it knows when is the most efficient time to do that. The function would be nearly always be duplicating or wasting effort if always checked for a=0.

So, one version of this function could be ...

 
ifdef DEVEL_MODE then 
  include std/error.e 
  procedure fail_if(integer x, sequence t) 
    if x then 
        crash("** FAILURE DETECTED **\n" &  t & '\n') 
    end if 
  end procedure 
end ifdef 
 
-- Compares two floating point numbers allowing for a tolerance. 
function compare_real(atom f, atom g, atom e = 0.000_000_000_000_009) 
 
	atom r 
	r = f-g 
	if r > e then 
		return 1 
	elsif r < -e then 
	    return -1 
	else  
	    return 0 
	end if 
end function     
 
----------------------------------- 
public function solve_quad_eqn(atom a, atom b, atom c) 
----------------------------------- 
    sequence res 
 
    atom descrim 
 
    descrim = b * b - 4 * a * c 
    -- Adjust result for limitations in floating point math. 
    if compare_real(descrim, 0) = 0 then 
    	descrim = 0 
    end if 
     
    if descrim < 0 then 
        res = {} 
         
    elsif descrim = 0 then 
        res = {-(b / 2 * a)} 
         
    else 
        descrim = sqrt(descrim) 
        res = - { b - descrim, b + descrim } / (2 * a)  
         
    end if 
 
    ifdef DEVEL_MODE then 
    	-- Check that results are sane. 
        for i = 1 to length(res) do 
            fail_if(not atom(res[i]), "The results must be real numbers") 
        end for 
 
    	atom temp = compare_real( (b*b), (4*a*c) ) 
    	atom vx = -(b / 2 * a) 
    	atom vy = -( b*b - 4*a*c) / (4 * a) 
    	 
        if length(res) = 0 then 
           fail_if(temp >= 0, "Should have one or two Real results") 
           fail_if(a > 0 and vy <= 0, "Vertex too low") 
           fail_if(a < 0 and vy >= 0, "Vertex too high") 
            
        elsif length(res) = 1 then 
           fail_if(temp != 0, "Should have zero or two Real results") 
           fail_if(compare_real(vy , 0) != 0, "Vertex Y should be zero") 
           fail_if(compare_real(vx , res[1]) != 0, "Vertex X should be result") 
            
        elsif length(res) = 2 then 
           fail_if(temp <= 0, "Should have zero or one Real results") 
           fail_if(compare_real(-(b / a), res[1] + res[2]) != 0, "Invalid symetry") 
           fail_if(a > 0 and vy >= 0, "Vertex too high") 
           fail_if(a < 0 and vy <= 0, "Vertex too low") 
            
        else 
           fail_if(1, "Only a maximum of two results are allowed") 
        end if 
 
    end ifdef 
 
    return res 
 
end function 
 
ifdef UNIT_TESTING then 
procedure test_solve_quad() 
	for i = -20 to 20 do 
	for j = -4 to 4 do 
	for k = -5 to 5 by 0.3 do 
 
	if i != 0 then 
		solve_quad_eqn(i/10, j, k) 
	end if 
	end for 
	end for 
	end for 
end procedure 
test_solve_quad() 
end ifdef 

So only during development would the results of the function be validated. Once in production, the function is known to be behaving as specified so we no longer have to make sure its results are good; they will be. And we don't check its arguments because the calling program should have already checked those.

Yes, that you have.

59. Re: Discuss changing the behaviour of append()

• Posted by kinzz Jun 12, 2014
• 3999 views

jimcbrown, append() worked as expected in that Derek's original wrong code.
It signalled about Derek's bug.
Same as it worked 20 years in thousands of EU programs, without any claims from users.

Do you know just one claim?

Derek had to use &, not append(). Period.

And he do use & now, and his new function works ok (as he says) and looks good.

If you wanna another append(), it is yours choice and it is totally another story.

Regards

61. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 12, 2014
• 3922 views

This reminds me of an argument I had a while ago about PS/2 connections.

You have serial mice, and maybe there were serial keyboards at one point in time too.

Now, like USB, the original serial line cable was designed so you could unplug and replug devices back in. You could unplug your serial mouse from the computer and plug it back in and it'd work again.

Then I was told that PS/2 is actually derived from serial. And yet, with PS/2, if you unplug your mouse or keyboard, you generally have to reboot to get things working again. I wonder why PS/2 actually lost functionality, compared to the older serial protocol.

Anyways, I was told that this was "by design." That's right, PS/2 was designed to lose functionality compared to serial. I don't know if that's actually true or if the person I was holding this conversation with was just pulling my leg, but this brings up a good point I'd like to make.

Just because something works as designed, doesn't mean that everything's perfect - the original design might have been bad (as imvho PS/2 lack of hotplugability is), thus making improvements necessary.

I still have a lot of old PS/2 keyboards around (and even one DIN keyboard), and a few older desktops that still have PS/2 ports on them. But I got a bunch of USB/PS2 converters and connect everything via USB now. Life's just easier that way.

63. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 12, 2014
• 3933 views

S[I[1]] &= {X} 

integer n = I[1] 
S[n] = append(S[n], X) 

I started to respond to this, then I realized that it was more-or-less identical to http://openeuphoria.org/forum/m/124582.wc, which I already responded to.

Perhaps we should take a different tack. What is the compelling original reason for append() to have refused to accept atoms as the first parameter in the first place?

65. Re: Discuss changing the behaviour of append()

• Posted by gimlet Jun 12, 2014
• 3932 views

Derek,

We agree that a function's parameters should be validated before entering the function. This is why I have said:

The real problem is not append but A[i] being an atom.

My point with the various slices is that every slice is a sequence but A[i] is possibly not.

It would seem reasonable (to me at least) that A[i] and A[i..i] ought be interchangeable. Therefore I am inclined to say the difficulty with append is with the (ambiguous) nature of A[i].

I don't think that append shoud be changed as restricting the target type to sequence is a good restriction.

67. Re: Discuss changing the behaviour of append()

• Posted by petelomax Jun 13, 2014
• 3925 views

    integer n = I[1] 
    
    return S[1 .. n - 1] & {deep_append(S[n], I[2 .. $], X)} & S[n + 1 .. $] 
end function 

Would this not help?

    integer n = I[1] 
    S[N] = deep_append(S[n], I[2 .. $], X)    
    return S 
end function 

As others might have said, I think you meant

the previously broken as designed program would no longer be properly broken. 

Agreed, that was certainly not one of my better suggestions.

Absolutely. When Derek said something similar, it completely changed my mind, and 4 days later I still cannot think of a valid answer to that one.

Pete

69. Re: Discuss changing the behaviour of append()

• Posted by _tom (admin) Jun 13, 2014
• 3926 views

Still trying to make sense of this topic. Here is a summary of a few ideas I see in this thread.

• Is change going to happen?
• How do I describe these chagnes?

_tom

From Euphoria 1.0 Documentation from 1993:

Concatenation of Sequences:

The & operator will concatenate two sequences into a longer sequence. e.g. {1, 2, 3} & {4, 5, 6} is {1, 2, 3, 4, 5, 6}. Atoms can also be concatenated: 6.5 & 9 is {6.5, 9}. {1, 2, 3} & 4 is {1, 2, 3, 4}.

Operations on Sequences:

	i = length(s)          -- length of sequence 
	s = repeat(x, a)       -- repeat x a times 
	s2 = append(s1, x)     -- append x to end of s1 
	s2 = prepend(s1, x)    -- prepend x at beginning of s1 

Twenty years later...OpenEuphoria wants to look like:

Concatenation of Objects:

The & operator will concatenate two objects into a longer sequence. e.g. {1, 2, 3} & {4, 5, 6} is {1, 2, 3, 4, 5, 6}. Atoms can also be concatenated: 6.5 & 9 is {6.5, 9}. {1, 2, 3} & 4 is {1, 2, 3, 4}.

Operations on Objects:

	i = length(x)          -- length of object 
	s = repeat(x, a)       -- repeat x a times 
	s2 = append(x1, x)     -- append x to end of x1 
	s2 = prepend(x1, x)    -- prepend x at beginning of x1 

1. Keep things the way they were
2. Extend Euphoria

Keep Things

• change is bad
• some suble changes in program behaviour if append is changed?
• append was optimized for speed; do not sacrifice this speed
• & is a "sequence creation" operator; therefore it makes sense that you can concatenate two atoms
• append is a "sequence modifying" function; therefore it makes sense that you can not start with an atom

Extend Euphoria

• length has already been changed
• a complementary change given that length is now different
• fits the existing pattern that & already has
• promoting an atom a to a sequence {a} is a convenience that is expected because of the flexibility of Euphoria
• usability is more valuable than interpreter speed
• thinking in terms of objects is more powerful than thinking in terms of just sequences

71. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 15, 2014
• 3815 views

Ok, I've now implemented a prototype implementation at http://scm.openeuphoria.org/hg/euphoria/rev/b49d88483f04

There may be room to improve upon this, but at least it's a starting point. If we still want to do this, that is.

73. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 16, 2014
• 3751 views

Agreed. The same is true of all the changes to execute.e in this branch. However, this is a prototype branch. The point is that users can check it out and immediately experiement with it.

So, all the changes are made to execute.e with the idea that they should run on the default branch while being able to demonstrate the new functionality.

(Well, that's part of it. The other part is that it's easier to prototype the changes in Eu in execute.e, get some test code running to validate the changes, then redo the changes in C afterwards and make sure that both versions produce the same output from the test code.)

75. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 16, 2014
• 3748 views

if atom(val[a]) then 
    val[target] = val[a] & {val[b]} 
else 
    val[target] = append(val[a], val[b]) 
end if 

I didn't. Should I change it to this? Is it better than append({val[a]}, val[b]) ?

77. Re: Discuss changing the behaviour of append()

• Posted by DerekParnell (admin) Jun 16, 2014
• 3719 views

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.

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().

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

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}?

79. Re: Discuss changing the behaviour of append()

• Posted by SDPringle Jun 17, 2014
• 3711 views

Derek, Thank you for taking the time to explain your rationale. As you pointed out everything about a language is learned after all. So, this is not about belief or facts but rather about feelings.

I feel that append should continue to be a function where the first argument is a sequence and the second an object. I have never written a EUPHORIA program and wished that append could accept() a character as the first argument. I sincerely believe you are the only person who has ever wished they could pass an atom to the first argument of this function.

Shawn

81. Re: Discuss changing the behaviour of append()

• Posted by SDPringle Jun 18, 2014
• 3609 views

I believe Derek is saying if we don't have this change, map:put with the APPEND argument will have to handle more cases specially in order to behave as intended. I am saying routines have this kind of strictness to data-types to help users. Especially new users who are learning the language. A new user who misuses this builtin currently gets a helpful error. I feel the if in doubt give an error is more in the spirit of EUPHORIA. Instead of garbage in - garbage out. It is garbage in - give a helpful error. Like I said before, it is subjective which is better.

I think there are better ways to improve EUPHORIA's performance.

Maybe we can handle the case specially where a variable is passed to a user defined function and the result of that function is assigned to that variable. It really shouldn't add a reference at all but just leave the reference count alone in this circumstance to avoid unnecessary copying. Another thing, what is the bottle neck that motivates library wrapping developers to create shims for libraries? Is it the cost of the allocate/poke/peek cycle? Is c_func too slow?

Shawn

83. Re: Discuss changing the behaviour of append()

• Posted by euphoric (admin) Jun 18, 2014
• 3633 views

If we look at the term append(), there's no obviousness, innately or on the surface, about what it should accept as parameters. The only thing we can draw from it is that we will get a sequence of items, whereby the needle is added to the end of the haystack. This needle can be sequence or atom, and the haystack can be sequence or atom, so long as the result is a sequence.

If it matters, I'm not against modifying the behavior of append() to accept (object,object).

85. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 20, 2014
• 3514 views

-- CASE III 
 
    elsif isEven( list[1] ) then 
       return  append( list[1..1] ,   extractEvens3( list[2..$ ] ) ) 

This is non-sensical. This has the effect of creating a new sequence, even if list[1] is already a sequence. It is equivelant to:

    elsif isEven( list[1] ) then 
        if atom( list[1] ) then 
            list[1] = { list[1]} 
	else 
            list[1] = { list[1]} 
        end if 

-- CASE III 
sequence s3 = extractEvens3(s) 
include std/sequence.e 
s3 = stdseq:flatten(s3) 
? s3 
--> {2,4,6,8,10} 

But this indirect way works for case IV as well.

-- CASE IV 
sequence s4 = extractEvens4(s) 
include std/sequence.e 
s4 = stdseq:flatten(s4) 
? s4 
--> {2,4,6,8,10} 

3.1 --- a/source/execute.e	Tue Jun 10 20:31:17 2014 -0400  
     3.2 +++ b/source/execute.e	Sun Jun 15 18:33:11 2014 -0400  
     3.3 @@ -2965,7 +2965,11 @@  
     3.4  	a = Code[pc+1]  
     3.5  	b = Code[pc+2]  
     3.6  	target = Code[pc+3]  
     3.7 +	if atom(val[a]) then  
     3.8 +	val[target] = append({val[a]}, val[b])  
     3.9 +	else  
    3.10  	val[target] = append(val[a], val[b])  
    3.11 +	end if  
    3.12  	pc += 4  
    3.13  end procedure  

Yes, and (assuming I did it right) the change to the C runtime works identically.

Agreed.

Explaining how it works is simple. Justifying the reasons behind it is not so easy.

If someone things that explaining away the reason for this behavior is easy, then please explain why, in original instance (i.e. before we have code and have to deal with backwards incompatibilities), should append() only allow the haystack to be a sequence?

extractEvens() seems to naturally fit better with concatenation, not append, regardless.

87. Re: Discuss changing the behaviour of append()

• Posted by _tom (admin) Jun 20, 2014
• 3468 views

Whats left is to make sure that append, prepend, and insert are consistent.

I can't figure out a way to "break" the expanded viewpoint for append. As Jim Brown shows, non of the attemps are convincing.

As Mindwalker suggests, it makes more sense than the old way.

_tom

89. Re: Discuss changing the behaviour of append()

• Posted by gimlet Jun 21, 2014
• 3491 views

Just a question:

Assuming that appending/prepending to atoms is on
we have:

? append(1,{})  -- {1,{}} 
? append({},1)  -- {1} 
? prepend(1,{}) -- {{},1} 
? prepend({},1) -- {1} 

I'm not saying it's wrong but don't you find the difference strange?

91. Re: Discuss changing the behaviour of append()

• Posted by DerekParnell (admin) Jun 21, 2014
• 3346 views

-- given 
sequence s = {1,2,3,4,5,6,7,8,9,10} 
 
-- want 
--> {2,4,6,8,10}  that is reduce s to all even items 
--> use a recursive function to do this 

Tom,
the append() function is not the appropriate functionality to use in this case because it appends the second argument as a single element to the result, and if the extract function is returning a list of things, then using its returned object in this manner is not what is required. The concatenate operator is a better choice for this exercise. To use append(), the extract function would have to return only a single element from the original list each time it was called.

93. Re: Discuss changing the behaviour of append()

• Posted by DerekParnell (admin) Jun 22, 2014
• 3358 views

  append(1,{})  -- {1,{}}  
  prepend(1,{}) -- {{},1}  

Ahh... I see what you were trying to get across now.

However, "you have added nothing" is not accurate. The append()/prepend() functions add the second argument as a whole to form the new sequence element. An empty list is still a list; it is a something; an object. The append()/prepend() functions do not add the contents of a list to the first argument, but the entire object itself. For example ...

  append({1},  {1})  --> gives {1, {1}} and not {1, 1} 
  prepend({1}, {1})  --> gives {{1}, 1} and not {1, 1} 
--thus-- 
  append({1},  {})   --> gives {1, {}} and not {1} 
  prepend({},  {1})  --> gives {{}, 1} and not {1} 

In all cases, append(X,Y) is identical in result to X & {Y} and prepend(X,Y) is identical in result to {Y} & X so that gives ...

  object X, Y, Z 
 
  X = {1} 
  Y = {} 
  Z = append(X,  Y)  --> gives {1, {}} 
  Z = X & {Y}        --> gives {1, {}} 
  Z = prepend(X,  Y)  --> gives {{}, 1} 
  Z = {Y} & X        --> gives {{}, 1} 

{} append A   ==   A append {}  -- == equivalence 

If append(1,{}) were to give {1}, then it must follow that append(1, {2,3}) should give {1,2,3}, and that is not what it is intended to do. Likewise if prepend(1,{}) were to give {1}, then it must follow that prepend(1, {2,3}) should give {2,3,1}, and again, that is not what it is intended to do.

There is effectively nothing different between an empty slice and an empty sequence.

95. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 22, 2014
• 3347 views

Other than one lapse, the term concatenation is used consistently.

Agreed.

Well, I think this is not so strange. Lots of functions lack an identity. f(x) = x + 1 lacks an identity. Logical NOT lacks an identity.

Furthermore, this has nothing to do with the proposed change. Even without it, append lacks an identity. To demonstrate this with the most likely canidate, append({}, {}) does not return {}.

append also lacks associativity. append(1, {}) and append({}, 1) return different things. Again, this is nothing to do with the proposed change - append({1}, {2}) and append({2}, {1}) also return different things. Other mathematical functions, like division or subtraction, also lack associativity.

97. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 22, 2014
• 3340 views

   a + b == b + a 
   a + 0 == 0 + a 

Are you?

To borrow your example,

   a + b = b + a 
   a + 0 = 0 + a 

Also see that,

   a / b = b / a 
   a / 1 = 1 / a 

Oh, wait a minute....

Actually, you contradict yourself. You state,

   a + b == b + a 
   a + 0 == 0 + a 

as well as

but you also say

These (lack of associativity and lack of identity) are two different things.

99. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 22, 2014
• 3362 views

I didn't say that - but it's true: http://en.wikipedia.org/wiki/Semigroup

Haskell has a list concatenation operator that has both of these properties, as does Euphoria's own concatenation operator. Euphoria's append has neither. I don't find this state of affairs particularly strange - concatenation naturally has these properties, but the function we define as append (which can be simulated by concatenation) does not.

Since you contradict yourself, it's very hard to determine what you are saying.

You keep comparing append to concatenation. If you are trying to state that append should behavior identically to concatenation, please state so explicitly, not in this roundabout way.

If you disagree that append should behavior identically to concatenation, I'd like to see some examples where you believe they ought to behave differently.

Hardly. Appending is basic operation involving any kind of list structure. I can't think of a single programming language that lacks a function or method to implement this functionality. (Maybe Haskell.)

This is implicitly an ad hominen argument and can be dismissed as such.

I'll restart my original argument for clarity: Since there are many mathematical functions which lack both the associativity and identity properties, I do not find it at all strange that Euphoria's append routine lacks these properties as well.

101. Re: Discuss changing the behaviour of append()

• Posted by DerekParnell (admin) Jun 22, 2014
• 3345 views

LOL ... how's that working out for you?

In what ways do "the monoid makes it easy reasoning about functions"?

Oh well ... c'est la vie.

Euphoria's append() works, its useful, and it's used. I've got no problem with the concept behind it. Should I have?

103. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 22, 2014
• 3377 views

More ad hominen attacks and now a Loaded Statement ...

This post lacks any new facts or a valid logical argument. I think we've crossed the line into personal attacks here.

Another post like this, and I'm placing you under "extraordinary measures". If you can't play nice, then don't play at all.

105. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 22, 2014
• 3329 views

I think Shawn hit it on the nail when he said ( http://openeuphoria.org/forum/m/124652.wc ) that it wasn't about facts but feelings. Changing append to be monoid (whatever that would look like) is one of these (unlike the original topic, where the change is backed up by facts about performance optimization and code/algorithm simplication by removing edge cases).

107. Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 22, 2014
• 3330 views

Exactly. append and concatenation are two different things, two different functions. The same way that f(x) = x + 1 and g(x, y) = x + y are two different functions. They simply do different things and therefore do not behavior similarily.

The fact that concatenation is slower (in the general case only) is irrelevant. Even if it were faster than append, the two functions still are two different functions. (Incidently, when concatenating an atom and a sequence, concatenation is implemented by calling either append or prepend (in the later case swapping the arguments), depending on the order of the arguments. So concatenation is not always slower.)

That append is not strange, as you originally posed:

I'd like to say good riddance, but I have a feeling that this wouldn't be the case: http://openeuphoria.org/forum/m/118296.wc http://openeuphoria.org/wiki/view/forum-msg-id-124160-edit.wc