World: r3wp

The #1832 ticket needs its summary line changed accordingly.

select/a-bit-more-than-case-but-a-bit-less-than-strict-but-definitely-not-equiv-or-same

We can't remove /case. So the new option would not have to be a superset 
of /case, it would be additive. What would you call an option that 
made it consider datatypes? Keep in mind that this option would only 
apply to block types, so would be overhead for other types that implement 
the FIND and SELECT actions.

If we can neither remove nor superset /case, it is hardly worth talking 
about this at all.

If we called the option /type then /case would check case, /type 
would check types, and /case/type would check both. That is what 
I meant by additive.

Understood. And for me that's hardly worth talking about.

Instead of inflicting the pain of having to type /case/type just 
leaving the current /case behaviour as-is and updating the doc strikes 
me as more sensible.

I'm OK with having the current behavior of FIND and SELECT, and extending 
it to the set functions. But if others have problems with that and 
want /case to just be case, then we may need the extra option. All 
of this is really a complaint about #1830 being dismissed.

Orthogonal issues.

Or alternative solutions, rather.

Checking SELECT, it's clear that its behavior is not consistent among 
different classes of value types either. The simplest solution would 
be to change #1830 into something that can be undismissed, and then 
dismiss #1831 and #1832.

That means expanding the complaint of #1830 and giving it a different 
justification.

Since you are the one who dismissed it in the first place, feel free 
to go ahead and do as you deem right.

Depending on how #1830 is resolved, #1831 and #1832 will either need 
to be dismissed or rewritten. I'm going to have to defer them until 
#1830 is decided upon.

Done. Check out the new http://issue.cc/r3/1830for the whole issue.

pulled myweight.

I do not want to use the "immediate value" notion, since it is an 
"implementation detail" in the sense, thant e.g. Doc's attempt implementation, 
while attempting to be compatible, has drawn the line differently.

And, if done properly, you would not be able to discern

So if the new-line attribute is immutable, is that observable?

Yes, the immutability *is*

And would that mean that calling the new-line function creates a 
new copy of the value, toggles the new-line bit, and places that 
new value in the appropriate slot?

I may not follow what you are after, but is a sign of integers immutable, 
and is that (according to your opinion) observable?

In theory the immediate values are supposed to be immutable, and 
not have multiple references. In practice the value slots are mutable, 
and the containers of the value slots can have multiple references 
to them, so the difference is not as cut and dried as that.

Nonetheless, the newline attribute is no more mutable than tuples 
or typesets.

I guess that the sign of an integer would be immutable, and probably 
observably so.

The simplified gist of what I'm after is:

Does new-line modify the 128-bit value slot? I assume so.

How do then have come to conclusion regarding the immutability of 
the new-line attribute?

In theory the immediate values are supposed to be immutable
- three objections:


- immediate values are not definable in Rebol (you can define such 
a typeset, but that does not mean, every compatible interpreter would 
need to implement them the way they are implemented in one specific 
case)

- the sentence is uninformative ("are supposed" does not mean "are")
- "in theory" is uninformative as well (what theory?)

But I think I know where I am going wrong.

Andreas, I can define a function modifying a 128-bit slot so, that 
only the sign of an integer is changed. Would you consider that relevant?

I was using the English idiomatic meaning of "in theory", not the 
scientific jargon meaning.

("define a function" == "define a function in rebol") in my above 
statement

Ladislav, if you can do that in pure REBOL, I would consider it very 
interesting at least.

Ah, thanks :)

And despite that, you maintain that the sign of an integer is immutable 
in REBOL?

Sure

My definition of mutability does not depend on that

Yes, I'm starting to understand that.

I consider the new-line attribute to be an attribute of the value 
slot, that just gets copied over to new value slots when the value 
is copied. But you could consider it to be part of the value that 
doesn't affect anything other than display. It's mutable if the value 
slot is not protected, but the mutation doesn't get carried over 
to the copies, so it's what we generally call "immutable" in REBOL: 
It's just assigning a new value to the value slot.

Well, my POV is expressed in the article, and it differs from yours, 
as you may have spotted, Brian.

Ladislav, wouldn't changing the sign bit in-place affect the "numeric 
representation" attribute, and therefore make that attribute volatile?

I guess that's where I was going with the "observable".

And here it's getting a bit philosophical, so I leave it at that.

Hmm, actually, not. That is exactly where my POV differs from yours, 
as well as from Brian's. Let's consider a value 1 being "stored" 
in a block B (whatever that means). Now, if the block B is not protected 
in some way, I am able to replace the value by, say #[none] e.g. 
Does that mean I mutated the value 1, mutating the slot? Actually, 
what I mutated was just the block B, replacing 1 by #[none], but 
I did not even attempt to mutate 1, if you are still with me.

Yes, I follow.

far that matches what I said above.

So far

So, while "directly mutating the 128-bit slot", I did not mutate 
the value it contained before.

In another reality, you of course did mutate the value.