World: r3wp

Christian, please report the latter cases as bug.

I'm not sure if it isn't by design, at least I wouldn't be surprised 
if being told so. Anyways, I'd prefer it being a bug, so, added it 
to CureCode.

Given the above discussed behaviour, I would very much prefer /STRICT 
instead of /CASE as well. But I fear the chance for such thorough 
naming improvements has long passed.

hmm, you should post it as a separate CC item (wish?)

yes, using /CASE for strict word comparison is VERY ugly. the only 
reason I can think of is that Carl didn't want to add a refinement 
just for this.

Well, if there's sufficient backing in the community, we really should 
manifest that in the form of a CC wish.

No problem with me

I'd bet /CASE is not used that much for word comparison in the R3 
mezz code.

(if at all, maybe in r3gui)

do not think so

Already did (curecode that wish above).

#1832

already added my weight behind the /STRICT naming  :-)

The /strict option sounds interesting, and would solve those inconsistencies. 
However, it would need to be an additional option; /case would need 
to remain for compatibility reasons.

I'm not sure it's completely OK though, since there is one part of 
strict comparison that SELECT/case doesn't cover: binding.
>> select/case reduce [use [a] ['a] 1 'a 2] 'a
== 1
>> strict-equal? use [a] ['a] 'a
== false

Nor do we want it to, because SELECT, FIND and other functions to 
which /strict would apply would generally not be applied to data 
which could be guaranteed to have the same binding as the value you 
are searching for.

Christian, REPLACE and ALTER are mezzanines that call FIND. You don't 
need to include them in the examples.

A new refinement for considering datatypes would be a good idea (if 
a bit overhead-inducing), but probably not the name /strict. We have 
to keep the /case refinement because of the legacy naming rules, 
but those don't prohibit adding new refinements.

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