World: r3wp

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.

(Just changes in the implementation of set, lesser?, greater?, equal?, 
etc.)

No change in syntax or parsing would be required. However, the DO's 
evaluation rules for the set-word expression *would* need to be changed. 
Note that these evaluation rules are *not* performed by a parser, 
so changing parsing would not be required, Paul.


However, this change to the evaluation rules of the DO dialect would 
be so fundamental that we would essentially be changing the semantics 
of the language to that of another language. And that other language 
would resemble Icon more than it would REBOL, semantically. And changing 
the behavior of the SET, LESSER?, ... functions would not be enough 
because DO doesn't actually call those functions directly - it calls 
internal code, which may or may not also be called by those functions.


But this is not a problem, because at least you wouldn't have to 
change the parsing. This means that all you would have to do is write 
your own evaluator and pass the code to that instead of DO. And create 
new versions of all the functions that call DO internally, behaving 
the same but calling your DO replacement instead. And create a context 
to reference those functions, and bind to that context instead of 
the standard system context. Basically, all you have to do is create 
a new dialect on the scale of the DO dialect, using the same REBOL 
parser, but different semantic rules.

`b: a - 3 > 11` is *not* syntactic sugar for `set 'b greater? subtract 
a 3 11`, instead it is sugar for the internal code that those functions 
call. So changing the meaning of those functions wouldn't be enough. 
To really make the change, you would have to replace DO. But not 
completely, because all of our code depends on DO remaining as it 
is - so you would need to make a new sort-of DO-like dialect that 
would be used in addition to DO, for those circumstances where you 
need this semantic model. Just like any other additional dialect, 
really.

On the other hand, if you want to change DO's behavior to this, then 
it would require you to create a *new* language, with the same parser 
as REBOL, or one that is completely compatible. Basically, an incompatible 
REBOL clone. It would be hard to use the same parser though because 
the existing runtime code depends on the current semantics, so you'd 
have to replace that code too.

So the reason that we were suggesting functions instead of core semantic 
changes is because the function solution is feasible, while the core 
semantic changes are not without remaking the language. And the function 
solution gets the job done, though not as efficiently as the existing 
function solution: IF.