r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

BrianH
14-Jan-2011
[7112x2]
reline: func [file] [write file enline read/string file]
(whoops, missed one)
Oldes
18-Jan-2011
[7114]
New bug: http://issue.cc/r3/1830
BrianH
18-Jan-2011
[7115x2]
Sorry, that one's intentional.
It's all part of the plan to make SELECT treat blocks, objects and 
maps more alike.
Maxim
18-Jan-2011
[7117]
I've always felt that doing so was dumbing down select.  now I can't 
use select with/within parse, cause the different types will not 
be identified.   

has switch suffered the same fate?
BrianH
18-Jan-2011
[7118x3]
Nope.
Now that I have internet again (it's been out for possibly a week) 
I'll check with Carl about this, but I remember code from 2007-2008 
that depended on this change, even from before SELECT was extended 
to objects and maps. It's used to make blocks that look like spec 
blocks for objects or maps act like objects or maps. SELECT does 
EQUAL? comparison, and SELECT/case does STRICT-EQUAL? comparison. 
So you can make it work by using SELECT/case. Note: Words now support 
case-sensitivity in blocks too, letting them be searched with FIND/case 
and SELECT/case.
>> select [a 1 :a 2] quote :a
== 1
>> select/case [a 1 :a 2] quote :a
== 2
Oldes
18-Jan-2011
[7121]
fine!
BrianH
18-Jan-2011
[7122]
I'll add this info to the ticket in a comment and dismiss it. It's 
actually more powerful than R2 :)
Oldes
18-Jan-2011
[7123x2]
but not perfect as the case-sensitivity may cause problems...but 
I can live with it.
but not perfect as the case-sensitivity may cause problems...but 
I can live with it.
BrianH
18-Jan-2011
[7125x2]
Not when you realize that this is consistent throughout R3, and just 
don't mix case when you don't need to.
The trick is that objects and maps are case-preserving rather than 
case-sensitive, so their fields get the same case as the first instance 
of the word. Plus, case-insensitivity is a little broken for a lot 
of languages right now (Unicode case is a complex problem).
ChristianE
19-Jan-2011
[7127x2]
Characters are case-sensitive

 is a pretty misleading description of the difference you've pointed 
 out between SELECT and SELECT/CASE, Brian. 


I would appriciate SELECT/STRICT over /CASE, /STRICT would even be 
usefull to imply case sensitivity, at least it seems better suited 
to express the semantic difference between the refined und the unrefined 
function call .
Same for 

>> find/case [a :a] quote :a
== [:a]
>> replace/case [a :a] quote :a quote a:
== [a a:]
>> alter/case [a] [:a]
== true


DIFFERENCE, UNIQUE and other "set-functions" obviously haven't been 
subject to change when the treatment of blocks, objects and maps 
converged:

>> difference/case [:a] [a:] 
== []
>> unique/case [a: a :a] 
== [a:]
>> union/case [a] [:a] 
== [a]
>> intersect/case [a] [:a] 
== [a]
>> exclude/case [a] [:a]
== []


In all cases, /STRICT would read at least as well as /CASE, if not 
better.
Andreas
19-Jan-2011
[7129]
Christian, please report the latter cases as bug.
ChristianE
19-Jan-2011
[7130]
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.
Andreas
19-Jan-2011
[7131]
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.
Ladislav
19-Jan-2011
[7132]
hmm, you should post it as a separate CC item (wish?)
Maxim
19-Jan-2011
[7133]
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.
Andreas
19-Jan-2011
[7134]
Well, if there's sufficient backing in the community, we really should 
manifest that in the form of a CC wish.
Ladislav
19-Jan-2011
[7135]
No problem with me
Maxim
19-Jan-2011
[7136x2]
I'd bet /CASE is not used that much for word comparison in the R3 
mezz code.
(if at all, maybe in r3gui)
Ladislav
19-Jan-2011
[7138]
do not think so
ChristianE
19-Jan-2011
[7139]
Already did (curecode that wish above).
Andreas
19-Jan-2011
[7140]
#1832
Maxim
19-Jan-2011
[7141]
already added my weight behind the /STRICT naming  :-)
BrianH
19-Jan-2011
[7142x5]
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.
Andreas
19-Jan-2011
[7147]
select/a-bit-more-than-case-but-a-bit-less-than-strict-but-definitely-not-equiv-or-same
BrianH
19-Jan-2011
[7148]
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.
Andreas
19-Jan-2011
[7149]
If we can neither remove nor superset /case, it is hardly worth talking 
about this at all.
BrianH
19-Jan-2011
[7150]
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.
Andreas
19-Jan-2011
[7151x2]
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.
BrianH
19-Jan-2011
[7153]
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.
Andreas
19-Jan-2011
[7154x2]
Orthogonal issues.
Or alternative solutions, rather.
BrianH
19-Jan-2011
[7156x2]
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.
Andreas
19-Jan-2011
[7158]
Since you are the one who dismissed it in the first place, feel free 
to go ahead and do as you deem right.
BrianH
19-Jan-2011
[7159x2]
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.
Maxim
20-Jan-2011
[7161]
pulled myweight.