World: r4wp

Is this a bug?

>> val: [a b c]
== [a b c]

>> val = [a b c]
== true

>> switch val [[a b c] [1]]  
== none

The 'swtich doc string doesn't indicate any restriction on the type 
whch can be used as the switch value.

Looks a bit odd.....

In R2 it doesn't work if the val is a block! but it does with hash!
In R3, block! doesn't work but map! does

Test code:
   val: make map! [1 2 3 4] switch val reduce [val [print 1]]

Should I add it to curecode?

%new-loop.r updated with Ladislav's latest examples.

BTW,

    for i 1 1 0 [print i]

is an infinite cycle both in R2 as well as in R3

BrianH: I used 'for quite a bit in R2.  But I used it simply when 
I needed access to a counter.

Ladislav, you are not getting that I am applying an *additional* 
termination condition before the start of the first loop, in addition 
the normal termination condition applied after every iteration of 
the loop, before the bump. Please don't mistake an intentional constraint 
for confusion.

I am not at all confused by your argument, I just don't agree with 
it.

Proposed fix for http://curecode.org/rebol3/ticket.rsp?id=1979- 
https://github.com/0branch/r3/commit/5bc79f6812a67f28ccd79372361c7fad7f3a6ea0

The linear search isn't ideal, though it means that existing structures 
can be re-used without further allocation.

Now https://github.com/rebol/r3/pull/105

'Ladislav, you are not getting that I am applying an *additional* 
termination condition before the start of the first loop, in addition 
the normal termination condition applied after every iteration of 
the loop, before the bump. Please don't mistake an intentional constraint 
for confusion.'  a couple of notes:


- you still don't get that if you are not consistent producing a 
lot of exceptions your code will be full of bugs and arbitrarinesses 
(there is absolutely no escape from this)

- you still don't get that there are concrete examples above demonstrating 
the problems you did not even consider yet

And I am not mentioning other problems I did not even discuss yet.

Also, saying that a cycle runs exactly once (which is, thus, independent 
on the cycle body) is too inflexible to not be considered just a 
bug  when knowing that the cycle varialble may be adjusted in the 
cycle body

Brian, on CC, your latest note links to #864, which I think should 
be #884.

Brian and Ladislav, how can we resolve this? Maybe you could both 
look at %new-loop.r and it would unite you against my incorrect and 
overly complex attempt. :-)

:-)

Meanwhile, you can check this to compare:


https://groups.google.com/forum/?fromgroups#!topic/Rebol/appT3TV5urY

>> for i 10 5 -1 [print i]
** Math Error: Math or number overflow
** Where: for
** Near: either max-int - bump <

needs correction, as it looks, checking

Seems to be the same for all negative steps (quick test).

aha, I swapped the condition, try with either negative? bump, please

disregard, needs something else...

aha, it should have been max-int + bump

I shall put the code here

I'll test it when you do.

done

At a quick glance, I believe for FOR and my LOOP have the same behavior, 
though I didn't address overflow as an initial goal.

Yes, that is what I guessed

(but I did not test your LOOP, to be honest)

And your approach with the bump overflow check is much cleaner.

You can just run it, and it will dump tests and output to the console.

And mine uses CFOR as the internal loop handler. As I noted briefly, 
it's just a dialect wrapper over CFOR.

That is no problem with me, but I know that CFOR does not need to 
handle overflow leaving that to the programmer if needed

(the important thing is that it is not needed in the great majority 
of cases)

However, FOR does not have this luxury

(which leads to slowness and overhead)

Why can't you just convert FOR args to CFOR rules?

Internally.

I do not think it could spare any effort

You mean the time to implement it?

My tests are actually "preconditions" at least in the specification, 
but due to the overflow possibility I converted them to one precondition 
and one postcondition to be able to handle the arithmetic issues 
before they occur.

once the condition allows another evaluation, I already know that 
the overflow does not occur and I can increment without taking any 
risk

You lost me. Do you mean CFOR can't spare the effort to do the checks, 
or you can't spare the effort to create a version of FOR that uses 
CFOR?

If Brian is OK with your new FOR, I think I am as well. I am also 
happy to refine my new LOOP func more, if people think there is value 
in it; as an alternative.

And I assume you will add support for other datatypes back into your 
FOR, beyond integers.

You lost me.
 - sorry, this looks to be caused by my bad English this time
 Do you mean CFOR can't spare the effort 

 - actually, CFOR (its implementation) does not need to handle such 
 issues leaving that to the programmer to handle only when needed


regarding the "I do not think it could spare any effort" - the sentence 
should probably look as follows: "I do not think it (implementing 
FOR using CFOR) could save any effort"

Thanks for clarifying. And rememeber how much better your English 
is than my Czech. :-)


My LOOP, using CFOR, is slower to set up, but much faster in the 
loop than FOR (incl your new FOR), so I thought it might be worth 
it.

aha, interesting, did not make any measurements