OpenEuphoria

Re: Discuss changing the behaviour of append()

• Posted by jimcbrown (admin) Jun 20, 2014
• 3392 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.