World: r3wp

>> (1 * #"a") = (1 * to integer! #"a")
== true

Consistency between the behavior of = between characters and strings 
is really important. R3 is better than R2 in that regard.

= isn't "normal equal", it's approximate equal. All four of the equivalences 
are "normal", for different circumstances.

I guess, the question is, whether chars should be more number-like 
or more string-like. In R2, chars are number-like except in maybe 
PARSE, where they are string-like:

>> parse "a" [#"A"]
== true

even if:

>> #"a" = #"A"
== false


In R3, chars are somewhere in between being number-like and string-like, 
as I see it. We can still do much calculations with chars, but not 
all:

>> 2 * #"a"
== 194
>> 2 ** #"a"

** Script error: ** does not allow char! for its exponent argument


The last is possible in R2. If chars should be more string-like, 
then make them so, Carl! This is really confusing:

>> "a" > "A"
== false
>> #"a" > #"A"
== true

There was a big debate about this before we hammered down the current 
equivalence hierarchy, including the operators. There was even a 
suggestion to have ~= refer to EQUAL?, making = refer to EQUIV?, 
but we finally decided that the paying attention to binding and exact 
IEEE754 equivalence was too advanced for most uses, so = was assigned 
to the most forgiving form of equality. Many other languages with 
an equivalence hierarchy have made a similar choice, so it shouldn't 
be too surprising.

The last is only confusing, if chars are considered string-like, 
as in R3. In R2, #"a" being greater than #"A" makes good sense.

In general, doing math with char! values without explicitly converting 
them is kind of bad form; it leads to developer confusion. The main 
reason you'd do this is because of the awkwardness of combining operator 
and prefix expressions without parentheses. It's interesting that 
it still works in some cases, but not in others. Considering characters 
to be number-like is a bit weird, a bit too C-like for my tastes.

For instance:
>> 1 + #"a"
== 98
>> #"a" + 1
== #"b"


The latter looks alright to me, the former looks weird, like a to-integer 
is missing. Can't say why though. I know why the result is an integer! 
(the left side sets the datatype returned most of the time), but 
any math that treats a char! as a number rather than as a non-numeric 
ordinal value just seems weird to me.

Alright, not "most of the time", just in this case. For others:
>> 1 + 1.0
== 2.0
>> 1 + $1
== $2
>> 1 + 100%
== 2.0


Maybe that's why it seems weird. I guess that since R3 char! values 
are currently limited to the codepoints in the BMP they are 16 bits, 
so converting back to char! would be a potential loss of range. It 
could go either way, so I guess the datatype-on-the-left rule is 
a way for the developer to specify which they want. And that rule 
applies to string types too (for INSERT and APPEND), so it's not 
completely weird.

Now this looks completely weird:
>> #"a" + #"b"
== #"A"


Having ordinal values that you wouldn't think of being numbers act 
like numbers seems really weird to me. I can accept that #"a" > #"A", 
but treating them like numbers without explicit conversion seems 
strange to me. I get similarly creeped out by multiplying one money! 
by another; I have to remember that despite the "$", and "money!" 
name, they aren't really money (a measure of quantity), they are 
just another numeric encoding that enables more precise decimal math 
than decimal! (another name that seems off to me, since its values 
are floating-point binary, not decimal).

I don't like this inconsistency though:
>> "a" > "A"
== false
>> #"a" > #"A"
== true

Too bad we don't have a hierarchy of inequalities. Only two levels 
would be needed. Maybe a /case option to the functions that the the 
operators map to? Is it even possible to map an op! to a function 
that can take an option?

Perhaps the relative comparison functions could be made to all be 
case-insensitive (for datatypes that have case defined as a concept), 
and have additional STRICT-* case-sensitive functions which would 
combine the functions and STRICT-NOT-EQUAL?.

We have a ticket for an improved equality comparison hierarchy:
http://www.curecode.org/rebol3/ticket.rsp?id=1834

I think that would nicely fit with a inequality comperison hierarchy 
as well (strict vs non-strict).

Nicely fit with an inequality comparison hierarchy
, of course. Bad typing day, I guess.

The term "relative comparison hierarchy" may be better, since it 
wouldn't include NOT-EQUAL? and such.

The STRICT-* relative comparison functions wouldn't have operators, 
unless we could come up with some that don't look like line noise 
(or worse: Perl).

Andreas, given that Carl is one of the ones who was tripping over 
the equivalence hierarchy (that he helped decide on) that ticket 
looks pretty promising. The caveat is that Ladislav is the one who 
would likely be doing the work, and he seems to need some convincing. 
Plus, it would require a new R3 release, not just a host kit update.

Ladislav is the one who would likely be doing the work, and he seems 
to need some convincing

 - I do agree, that LESSER? etc. functions having two versions (or 
 a refinement, or something) would be useful.

I was talking about http://issue.cc/r3/1834but that's good to hear 
too :)

hello

hello

A test of SIZE-TEXT shows a bug in R2. This should hopefully not 
be present in R3.

The test to run:

f: make system/standard/font [name: "Verdana" size: 12]
g: make gob! []
t: import 'text
g/text: bind [font f bold true text "Boo"] t
probe size-text g				; I get 26x14 here
g/text: bind [font f bold false text "Boo"] t
probe size-text g				; I get 25x14 here


It's possible that the result may vary, but the bold version should 
produce a wider size than the normal one. if you can test this similarly 
to what you did for R2, that would be great. Thanks.

R3 2.100.110.3.1 on Win 7 gives 27x14 for plain and 26x14 for bold 
text (both 1x0 bigger than yours).

Really? So, the bold font is *smaller* than the plain font?

Not, but you've reversed the order of plain and bold in the test 
for R3  :D
So, it's 27x14 for bold and 26x14 for plain text, actually.

ok, good.

Nope, still post them here. We still work on R3, and some of us use 
it professionally.

wish for R3 / Topaz / Red / World:

Add possibility to extend "read" and "load" to let them transparently 
load also custom file types (.tiff, .mp3 etc.)
Use something like:
system/mime: context [
	JPG: context [
		extensions: [%.jpg %.jpeg ...]
		header: #{JFIF}
		open: func [...]
		read: func [...]
		load: func [...]
		save: func [...]
		write: func [...]
		close: func [...]
	]
	...
]

R3 has that (codecs), but we would welcome any suggestions you would 
have for making them easier to use.

There's no easy way to add an MP3 type yet, because there's no audio 
type concept in R3 yet. But .jpg is supported already.

wish for R3 / Topaz / Red / World:
Add common charsets and parsing rules to system object:
system/parse: context [
	digit: charset [#"0" - #"9"]
	upper: charset [#"A" - #"Z"]
	lower: charset [#"a" - #"z"]
	alpha: union upper lower
	hexdigit: union digit charset "abcdefABCDEF"
	bindigit: charset "01"
	space: charset " ^-^/"
	digits: [some digit]
	decimal: [opt digits "." digits | digits "." ]
	exponent: [ [ "e" | "E" ] opt ["+" | "-"] digits]
	float: [opt "-" [decimal | digits] opt exponent]
	email:...
	...etc.
]

No need to add them to the system opject in R3, just export them 
from a module and they'll be available. They should be made read-only 
for security, but this is a good idea.

R3 PARSE rules can reference charsets and rules from path references, 
so they don't even have to be exported as raw words.

The Rebol system object is a very nice thing. I would pack it with 
all sort of things, especially those that can be "global" to a program 
or even "global" to many Rebol programs.

Modules extend the system object, in particular system/contexts/lib 
(aka lib), and the per-task (as planned) context system/contexts/user 
gets its values from there. The system object is actually going to 
be per-task, referencing global objects through system/contexts/*.

The main global contexts are system/contexts/lib, system/contexts/lib 
and the module contexts. All non-private modules are just as global 
as lib and sys.

sorry, that second system/contexts/lib was supposed to be system/contexts/sys.

wish for R3 / Topaz / Red / World:

I wish that refinements would be totally reworked (not R2 compatible 
:( ).

Current situation with some examples:

view/new/title/offset/options win "Dialog" 20x20 'resize

remove_last: func [{remove last (n) element(s) of a series}
	serie [series!] /n num [integer!]
	][
	num: any [num 1]
	remove/part skip tail serie negate num num
]


append: func [{Appends a value to the tail of a series and returns 
the series head.} 
    series [series! port!] value /only
	][
    head either only [
        insert/only tail series :value
    ] [
        insert tail series :value
    ]
]

New situation with different syntax and default values:

view win /new true /title "Dialog" /offset 20x20 /options 'resize

remove_last: func [{remove last (n) element(s) of a series}
	series [series!] /n: 1 [integer!]
	][
	remove skip tail series negate n /part n
]


append: func [{Appends a value to the tail of a series and returns 
the series head.} 
    series [series! port!] value /part /only /dup
	][
    head insert tail series :value /part part /only only /dup dup
]


Note that append could also be redifined as: #macro append [] [head 
insert tail]

You might want to check out the way Topaz does function options - 
it's even better than that :)

Topaz options are nice but not nicer for my tastes.

Make your own then :)  I'm not blowing you off, it's a real suggestion.

Macros make a lot more sense in compiled languages like Red, Topaz 
(to JS) and World (to bytecode) than they do in interpreted code-is-data-at-runtime 
languages like R3, where most functions are like macros.

One thing you might have to consider with your refinement suggestion 
is that you would have to put a lot of parentheses around function 
calls, because otherwise your syntax would make it ambiguous which 
function the refinement applies to. This is similar to the situation 
with Smalltalk and Objective-C.

R3 operations that would be slower than R2:

- Bulk string handling, because strings are twice as big (Unicode).

- Word dereferencing for function-context words, because they are 
stack-relative, adding an indirection.

- The fixed overhead of LOAD (like header handling) because it does 
a lot more.
Any others?

(This is continued from #World, where it was a little off-topic)

I haven't compared operator evaluation yet, which was another major 
change between R2 and R3. Overall, R3 looks a little worse for C-like 
code than R2, though neither are really appropriate for that kind 
of thing. And yet in my tests (which I don't have the results of 
handy, so take that with a grain of salt) idiomatic R3 is faster 
than idiomatic R2 for REBOL-like tasks, and the R3 idioms are less 
awkward to write than the R2 idioms. How have the rest of you found 
the differences to be in your work?

AFAIK, R3 always has been faster or equal in the early tests I made, 
that's why I don't understand the current situation.

I tested the loop example given by Geomol.
Same speed more or less.in R2 and R3