World: r3wp

Ok, ticket's good. Thanks Brian.

That's funny :)

(Maybe add a blank linke before the - EQUAL? item.)(

I didn't even know there was a newline bit, though it seems obvious 
in retrospect. It would be lost in the transfer of the value to the 
stack frame for the function call I bet, because stack frames and 
value slots of contexts don't keep track of newlines. You'd have 
to pass in a reference to the block the value is stored in, I'm guessing.

wrong

Even more interesting. Say more.

written in http://www.rebol.net/wiki/Identity#The_new-line_attribute

I used to think that newlines in blocks were hidden values in the 
block itself. It makes sense to just have it be a bit in a value 
slot.

It is a value bit.

>> a: copy [1 2 3]
== [1 2 3]

>> new-line next a on     
== [
    2 3
]

>> b: copy []             
== []

>> append b first a   
== [1]

>> append b second a  
== [1
    2
]

>> append b third a   
== [1
    2 3
]

Guess it's in all value slots, not just the ones in block types, 
and just ignored when inapplicable.

At least that makes the value slot easier to implement. Good choice.

Well, it is not ideal this way, for two reasons:


- it does not affect all possible line break positions in a block 
(there are n + 1 such positions in a block of length n, as can be 
easily figured)
- it "pollutes" the values, affecting their identity, e.g.

Well, the latter is probably why same? does not respect this bit, 
no :) ?

It also makes the "immediate values aren't modifiable" argument a 
little more iffy.

But the differences are real, that is like putting our head into 
the sand pretending there is no danger nearby

{It also makes the "immediate values aren't modifiable" argument 
a little more iffy.} - I do not use the notion of "immediate values", 
neverheless, it does not, I would say

(the NEW-LINE attribute is immutable)

It's mutable with the NEW-LINE function :)

No, see my article

It is exactly as mutable as the sign of an integer is, when using 
the Negate function

(not at all)

Immediate values are a bit iffy concept in REBOL anyways, so it's 
probably for the best that you don't use the notion. Nonetheless, 
there is a documentary typeset in R3 called immediate!, which includes 
the values that are fully stored within a value slot, rather than 
referencing memory elsewhere.

That is what I meant by "immediate values".

Let's move this to !REBOL3, shall we.

Naw, let's let it go :)

Strangely enough, while there is no obvious operator for EQUIV?, 
we could use === for STRICT-EQUIV? and !=== for STRICT-NOT-EQUIV?.

EQUIV?   could be   ~
 its the actual math symbol for it.

http://en.wikipedia.org/wiki/Table_of_mathematical_symbols

This would solve the operator problem for developers who understand 
the limits of IEEE754, and still let regular developers expect 0.3 
to equal 0.1 + 0.1 + 0.1.

EQUIV? is more strict than EQUAL?, so it would go the other way around.

We considered ~= in the last round, but that would be even more approximate 
than =, so the hierarchy doesn't work unless ~= means EQUAL?.

Remove ALIAS: http://issue.cc/r3/1835. Thanks, Andreas, for discovering 
the absence of this ticket.

proposal for four very usefull series functions....

shorter?: func [a [series!] b [series!]][
	lesser? length? a length? b
]

longer?: func [a [series!] b [series!]][
	greater? length? a length? b
]

sortest: func [a [series!] b [series!]] [
	either shorter? a b  [a][b]
]

longest: func [a [series!] b [series!]] [
	either longer? a b  [a][b]
]

sortest == shortest

Is that so ?

huh?

I mean, usefullness

I'm thinking, what kind of code is it that one writes, when you have 
to compare series lengths?

I just used it 10 minutes ago again... checking if two series need 
to be synchronised.

(though they don't use the same values, they are interdependent)

we could also add EQUAL-LENGTH? just for completeness

ok

they could just be part of a delayed load series module.  there are 
many missing series handling/probing functions in REBOL.  we end 
up writing them over and over.

remove-duplicates, extract-duplicates, remove-same, prefix?, suffix?, 
etc   the list is long.

how does remove-duplicates work?

like unique?

this implementation is order safe, removing the duplicates from the 
end rather than those in the begining

remove-duplicates: func [
	series
	/local dup item
][
	until [
		item: first series
		if dup: find next series item [remove dup]
		tail? series: next series
	]
	series
]

remove-duplicates, does it in-place

prefix? and suffix? just return true if a series starts with the 
same items in the same order as the second one.  
the second argument is the prefix to compare

so you can easily do:

unless suffix? file-name %.png [append file-name %.png]

the reason these are usefull is that when you chain them within other 
series handlers, you don't need to always add darn ( ) around the 
operators.