AltME: REBOL3

Messages

Gregg
Hi Ladislav! Wouldn't it make more sense for the first example to return 1? This is because R3 allows more than block! values for the 'then arg, but it seems like it should not evaluate them if the condition isn't true.

Ashley
re MAP! bug. I use map! with APPEND / SELECT extensively and have never encountered an issue. The bug report highlights an issue with unique/skip on a block! (unique does not accept map! as an argument) ... so I fail to see what the issue with map! usage actually is. Can someone enlighten me?
Sunanda
I am not sure it is a bug - may be a difference between what UNIQUE does and what HF thinks it should do. His example:
    unique/skip [a "b" "c" a "d" "e" z "f" "g"] 3
    == [a "b" "c" z "f" "g"]
Produces the correct (or at least same) result under R2, Red, and R3.
Gabriele
Gregg, the paren is evaluated before being passed to IF.
Personally I don't think CASE should evaluate, but then again, I can see why evaluation might be desired.

Josh
You may want to reread the issue, and take a look at the source links/fix.   The point regarding the Map bug is that the C hashing function sometimes accesses invalid memory.  The unique/skip example as described in the issue is not demonstrating a bug but showing the hashing function does not always have the same width (2) . The issue is when hash misses occur and new indices are added into the hash, it ignores the width.

Josh
One example of the bug:
rebol3> union/skip [1 1 2 2 2 2] [] 2
== [1 1 2 2 2 2]
red>> union/skip [1 1 2 2 2 2] [] 2
== [1 1 2 2]
PeterWood
I'm not sure what causes the bug in your example but its seems that there are bugs in both union and intersect when used with the /skip refinement:
>> union [1 2 3][]
== [1 2 3]
>> union/skip [1 1 2 2 2 2 3 3][] 2
== [1 1 2 2 2 2]
>> union/skip [1 1 1 2 2 2 2 2 2 3 3 3][] 3
== [1 1 1 2 2 2 3 3 3]
>> union/skip [1 1 1 1 2 2 2 2 2 2 2 2 3 3 3 3][] 4
== [1 1 1 1 2 2 2 2 2 2 2 2]
>> intersect [1 2 3][2]
== [2]
>> intersect/skip [1 1 2 2 3 3][2 2] 2
== []
>> intersect/skip [1 1 1 2 2 2 3 3 3][2 2 2] 3
== []
>> intersect/skip [1 1 1 1 2 2 2 2 3 3 3 3][2 2 2 2] 4
== []
Ladislav
Hi, Gregg! You wrote: "Wouldn't it make more sense for the first example to return 1?" - that is certainly an interesting idea, but I am not sure if may be popular.
The first disadvantage is that it would introduce a new incompatibility with older interpreter versions (R2),
and the second one is transparency. It would mean that the TRUE-BRANCH argument would not be normally evaluated, i.e., the programmer would not be allowed to calculate it somehow "just in time".
Gabriele: "Personally I don't think CASE should evaluate" - yes, that is another alternative. However, I do not think the current behaviour is correct in that case.
Josh
Here's a fix for the other hash issue in /skip (intersect/skip examples above don't work for this reason)
https://github.com/metaeducation/ren-c/commit/5e2fa93b66b6d372b6564e4bda1d4fe5a7d87eed
Gregg
Good points Ladislav. For your original question, the help for CASE says that what follows a condition is only evaluated if the condition is true, which seems OK to me.

Ladislav
Hi, Gregg. Unfortunately, "only evaluated if the condition is true" does not specifiy the behaviour as precisely as one may think. The examples below demonstrate the problem.
blk: [1 +]
case [
    true append blk 2
]
versus
blk: [1 +]
case [
    false append blk 2
]
, or similarblk: [1 +]
case [
    true append blk 2
]
blk: [1 +]
case [
    true append blk 2
]
sorry, copy and paste problem
ignore the text following the comma, please
Gregg
So what is the actual behavior? That is, what does get evaluated and what doesn't? Clearly stating how each is intended to work seems to be the first step. For example, should CASE enforce that values following conditions must be block types?
I can see the problem, with free-ranging evaluation, so constructs like your latest example seem like a bad idea in any case.

Ladislav
Well, the first example (preceding the "versus" word) yields 3 in Rebol 3, as well as in Rebol 2, and I dare to guess that it was intended.
Ladislav
The behaviour looks as inspired by IF. However, the behaviour of the second example (following the "versus" word) does not look reasonable, and I dare to say that it is a design (or implementation) flaw.
Gregg
So, in the latter case 'blk should be [1 + 2] and CASE should return none.
What was the reason for allowing non-block values for the cases, for both IF and CASE? Your examples tell me that it can be abused and hurt readability. Are there scenarios where it helps?

GiuseppeC
MARCO:
How should I use the EAN 128 font in REBOL 3 ?

GiuseppeC
What is blocking me to fully integrate REBOL in a company:
ODBC driver with some errors
No BARCODE support
No way to print a label using it
No way to rapresent a sheet of data using a report and print it or send it as PDF
Maybe since the last time I have used REBOL 3 things have changed.
Have you some solution, even integrating rebol with other technologies/libraries ?

Last message posted 161 weeks ago.