World: r3wp

Paul, I don't understand your request. For the code:
      b: a < 10

and the request "where b gets set to the value of a instead of true?", 
there are at least two ways to interpret *why* b would be set to 
the value of a. Either you want the op < to return the value of a 
rather than true (Icon-style comparison behavior, which C# doesn't 
have) or you want the code to be equivalent to (b: a) < 10, different 
precedence levels for op evaluation (which C# does have), or something 
completely different that I don't get. Which interpretation is what 
you meant?

Claude, where is R3 getting the path %/home/ramcla/Téléchargements/ 
? And are you encoding é in Unicode or Latin1?

brianH in /etc/default/local i have  LANG="fr_BE.UTF-8"   (ubuntu 
lucid 10.4)

Brian I don't know Icon so I can't say if it is the same behavior. 
 However, what I was saying is that it would be nice to see if the 
expression is true then the value of the expression be assign to 
the set-word.   A change like this would have to happen at the parsing 
level of the code.  You couldn't just modify the operator.

Is there a word! limitation in R3?

yes, but it's much higher than R2.

so a map! using.. 
n/xyz: "value

is limited?

in other words, am i forced to use binary or strings as keys to avoid 
the limitation?

that is unknown to me. BrianH must know.

why  couldn't the number of available words in R3 have been limited 
to memory?

regardless, strings as keys are probably the way to go.

You couldn't just modify the operator.
 - actually, that is not true in R3

I can have such an "operator" even in R2, it just needs to be prefix

Or, if you insist, that it is impossible to have such an operator, 
you should at least try to specify it "thoroughly enough" for me 
to be able to know what are your requirements. (that is what BrianH 
was curious about too)

Yup. And the value of the expression *is* being assigned to the set-word: 
the value of the expression a < 10 is either true or false. Unless 
you mean a different expression, at which point you should be more 
specific. If we understand exactly what you want, perhaps we can 
rig something up using magic evaluation tricks.

I think Paul is asking for a short form of :

b: either a < 10 [a] [false]


If none is an acceptable value when the condition fails, it can be 
shortened to:
b: if a < 10 [a]

Yes Peterwood that is similiar to what I had in mind.  I don't see 
this happening as I believe it would be a MAJOR change.

Perhaps what I suggested will help even if it can't be shortened:

>> a: 10
== 10
>> b: either a < 10 [a] [false]
== false
>> a: 2

== 2
>> b: either a < 10 [a] [false]
== 2

b: either a < 10 [a][b]

Looks like   b: min a b

No because that could give the wrong answer, if b is greater than 
a and a is ten or greater.

; this works in R2 as well as in R3, since it is a prefix operator
combined-lesser?: func [
    :set-word [set-word!]
    value1
    value2
] [
    if value1 < value2 [set set-word value1]
]

; usage
a: 10
b: 'no
combined-lesser? b: a 10
b ; == no

a: 2
combined-lesser? b: a 10
b ; == 2

As you can see, in REBOL, MAJOR changes are in the power of the user.

(if you don't like the name of the operator, feel free to invent 
a better one, since that is a greater problem for me than to implement 
it)

if=

nice idea, maybe if< ?

What about a polymorphic function ?


if=: func [:sw :gw :op val][op: get op gw: get gw if (gw op val) 
[set sw gw]]

>>a: 1
>>b: 5
>>if= a: b < 10
== 5
>>if= a: b < 5
==none

aha, that is just for R3, as it looks

(and behaves in a little bit different way)

the same goes for R2, a little different though...

yes, it can be backported

but honestly i don't see the gain with that mezz.
if b < 5 [a: b] 
...is short enough and syntaxly less obfuscated.

Ladislav and Steeve, that wouldn't be the same.  Your ownly showing 
the same functionality.  What I'm talking about would require changing 
the tokenization and parsing to give the EXACT feature I requested.

Steeve also your last expression should this if your trying to capture 
the same mezz    if a < 5 [b: a]

But since I see no way that the exact expression capability that 
I desire will be implemented then I am like Steeve and say just leave 
it as is.

Paul, aha, you do not like the prefix form, and insist on the infix 
form you wrote. Then I have a surprise for you: it isn't REBOL Do 
dialect, since the Do dialect does not allow the infix op to take 
more than two arguments. Nevertheless, you are totally missing the 
point stating, that it would require changing the tokenization - 
that is patently wrong.

Sure it would be - just do a TRACE and you will see that it has to 
be changed.  Do evaluates - it has to be supplied the correct structure 
in order to evaluate correctly.

It cannot help you state that. I can prove you false if I decide 
to do so.

Prove me false ladislav.

I'm not Ladislav, but ...

Paul, you want `b: a < 10` to roughly behave like `b: either a < 
10 [a] [b]`, if I am not mistaken.

If so, such a change would neither affect tokenization nor parsing 
in any way:


That's immediately obvious when you consider that `b: a < 10` is 
just syntactic sugar for `set 'b lesser? a 10`. You surely will have 
no troubles to write appropriate `my-set`  and `my-lesser?` according 
to your desired behaviour. With that done, the only change necessary 
to implement this as default behaviour in REBOL is to use your set 
and lesser? (etc.) implementations instead of the current ones. Tokenization 
and parsing needs not be touched.

See that is NOT what I requested.  I didn't request to use another 
set.  I requested to use the current ones.

It isn't just limited to <

It could also be:
b: a - 3 > 11

Or get much more complex expression that involves logical evaluations.

Introducing other functions is not what is being requested.

Again it would REQUIRE new Parsing to accomplish the task.

Again, `b: a - 3 > 11` is syntactic sugar for `set 'b greater? subtract 
a 3 11`.

No parsing changes needed for that either.