World: r4wp

another contribution:
	use [count inc start end op][
		count: inc: start: end: op: 0	
		in-range: func [
			[catch]
			'word [word!]
			start [number!]
			end [number!]
			/bump step [number!]
			/local result
			] [
			if inc = 0 [

    if step = 0 [throw make error! "step parameter cannot be = 0"]
				count: start

    either start > end [inc: -1 op: :greater-or-equal?][inc: 1 op: :lesser-or-equal?]
				unless none? step [inc: step]
			]
			set word count

   result: either op count end [count: (get word) + inc true][false]
			if not result [count: inc: start: end: op: 0]
			result
		]
	]
	i: 0 ; define a var
	while [in-range i 1 3] [print i]

about the Gregg's loop (on Rebol 2.7.8.3.1):
>>  probe cfor [num: 1] [num <= 3] [num: num + 1] [print num "a"]
1
2
3
4

??


>> probe cfor [num: 1] [num <= 3] [num: num + 1] [if num = 2 [throw 
make error! "what 2?"] "a"]
; nothing printed nor error report

what about this?:
	cfor: func [
		{General loop}
		[throw catch]
		init [block!]
		test [block!]
		inc [block!]
		body [block!]
		/local result
		] [

  do init while [do test] [set/any 'result do body do inc] get/any 
  'result
	]

The existing LOOP is used quite often, so any replacement for it 
won't go in R3 by default. However, the main reason LOOP is used 
is because it doesn't have the overhead that a lot of the other loops 
have, less than the other natives even. Its simplicity and definite 
form are its strengths - a loop with a more flexible form would be 
need to process that flexibility at runtime, which would add inefficiency 
that could easily be avoided by making that choice at development 
time by choosing the loop that meets your needs. And any loop construct 
that requires any kind of manual reducing of its arguments in order 
to have it take the result of an expression is a definite no-go. 
I just got rid of that in REWORD.


I like http://issue.cc/r3/884as a replacement for FOR. It keeps 
the local binding (unlike Marco's CFOR above, sorry) and is flexible 
in behavior without being flexible in form (it has a very simple 
implementation).

Watch out though, all mezzanine control structures that execute code 
blocks passed as parameters are be subject to http://issue.cc/r3/539
so they would need to be native until we have a solution to that. 
And not a command, because the necessary internal stuff isn't exported 
(purposely), so you couldn't do REWORD as a command.

In rebol 2.7.8.3.1 the #884 version has the same "strange behaviors" 
as the one that Gregg posted as a file here.

I just updated it to fix a couple more bugs; haven't read any of 
Gregg's comments so I don't know what those strange behavior are, 
but they might be fixed now. I am more a fan of its API style - we 
can fix any internal problems.

ok, much better now, just add [catch] at the beginning and it will 
catch also errors.

No need, because this is an R3 function and R3 doesn't have [catch], 
it has better errors with stack traces instead. Improvement.

Nice! I must try it sooner then later ;)

I had to get rid of [catch] in my first edit. And [catch] is a bad 
idea for loops because it hides where the real error is being triggered.

on Rebol 2.7.8.3.1 :
>> do [cfor [num: 0] [num <= 3] [num: num + 1] []]
** ERROR: ret has no value 
** Near: :ret

No, that's legit. The body was an empty block. The result of evaluating 
an empty block is #[unset!]. So, the return value is #[unset!].

on Rebol 2.7.8.3.1 :
>> do [cfor [num: 0] [num <= 3] [num: num + 1] [num]]
** ERROR: ret has no value 
** Near: :ret

Wait, R3 rules, :ret is get/any 'ret in R3. Change it to run in R2.

Why are you testing this in R2? It's written for R3.

I would have to change it for R2/Forward.

In R3:

>> cfor [num: 0] [num <= 3] [num: num + 1] [num]
== 3
>> unset? cfor [num: 0] [num <= 3] [num: num + 1] []
== true

Better to test it in R2 then to not test it at all. (By the way on 
R2 mine is a little faster).
I changed :ret to get/any 'ret and it works but in R3 :
>> do [cfor [num: 0] [num <= 3] [num: num + 1] [num]] ; works?


and why is it important to keep the local binding ?(I am not an expert 
of binding)

Yours is faster because it doesn't do the binding. That binding is 
necessary.

The entire difference between CFOR and WHILE is that local binding. 
If you didn't need the local binding you should use WHILE.

Benefits to the local binding:

- You define new words that go away when the function ends, *if you 
want them to*

- The context created is an object context, which makes word lookup 
faster (O(1) instead of O(n))

- The context created can be references safely after the function 
ends

- All series in the loop body are copied, which makes them safe to 
modify during and after the loop, making binding loops even more 
task and recursion safe than non-binding loops.

Sunanda, agreed on not export complexity. Words are supported directly, 
and we can look at making everything easy that it should support. 
Today, words are supported. e.g.:

a: 1
b: 5
loop [i a b 1] [print i]


Series values, as in your first bug report, are the thing I have 
to look into. Beyond that, should it just evaluate everything it 
gets?


Marco, FOR-STEP sounds too close to FORSKIP to me. Have to think 
about how FORSKIP fits in to the model. For that, and IN-RANGE, the 
main question is what their purpose is. On your first CFOR tests, 
I get these results:

>> probe cfor [num: 1] [num <= 3] [num: num + 1] [print num "a"]
1
2
3
4
== 4

>> probe cfor [num: 1] [num <= 3] [num: num + 1] [if num = 2 [throw 
make error! "what 2?"] "a"]
** Throw Error: ** User Error: what 2?
** Near: throw make error! "what 2?"

Brian, on efficiency, LOOP (right now) just does this at the top:

  either integer? spec [native-loop spec body] [...


So that's all the overhead there is to delegate to the native loop.

But, yes, the interface is the idea here. The current implementation 
is just to test that out.

@Gregg: >> probe cfor [num: 1] [num <= 3] [num: num + 1] [print num 
"a"]

for me it should print: 1 2 3 and give "a" as the result (as it does 
#884 NOW ;) )

Ah, yes. Thanks Marco.

I will let Ladislav correct me where I'm wrong, but it may just be 
due to him trying to keep CFOR simple. That is, it inserts the bump/incr 
block at the tail of the body, but doesn't want to return the result 
of that, so it returns the head instead, but what it should return 
is the result of the original body tail.

More clearly, it should return the last thing evaluated in the original 
body.

Can anyone solve the following bug  https://github.com/angerangel/r3bazaar/issues/3
?

q

Proposed fix for cc#1967, https://github.com/rebol/r3/pull/106

@BrianH, when you say "And any loop construct that requires any kind 
of manual reducing of its arguments in order to have it take the 
result of an expression is a definite no-go.", does "manual reducing" 
mean having the user do it? e.g., if I get a spec passed to my dialected 
LOOP func, and I REDUCE it or DO/NEXT internally, is that a no-go? 
If so, where should I look for the reasons and guidelines about it?

e.g., in order to support Sunanda's example:

    loop [i ser skip ser 5 2] [print mold i]

Can I do this in my func:

    spec: repend reduce [spec/1] next spec

Provisional SHA-2 implementation, https://github.com/0branch/r3/commits/sha2-experimental

I haven't committed an updated Makefile, so even if you're on Linux 
be sure to 'make make' first.

Tested on Linux and OSX, interested in hearing whether it functions 
correctly on Windows.

Usage,

>> checksum/method to-binary "A simple SHA-2 test." 'sha256

== #{E57EBDB51368F9A7ACE63E115193AEAD5E377742E0B4CD6B735CF5AAD49E67EB}

SHA2_Series could switch on width (224, 256, ... -- perhaps defined 
in an enum) rather than a symbol, but this made the logic in N_checksum 
cleaner.

Anyway, this is just a draft.

Thanks for your activity, Marc much appreciated.

No problem; thanks for saying so.

Arnold wrote (Red group): "R3 should follow this. " - I guess it 
might make sense to write it as a CC ticket (wish). Otherwise, I 
am neutral on this, not needing a shortcut for quit, but a user poll 
(opinions, please?) my reveal that preferences are against Q being 
a shortcut for QUIT.

Also, Marc, I think you can use Announce for your new pull requests. 
(but they can be here too, no problem)

Oh, sure; sorry if I've been misusing this room.

No, you have not, in fact (at least IMO).

MarcS: cool stuff! I planned to add SHA256 myself to enhance TLS 
scheme so your work will be useful, thanks!

Neat, glad to hear it. Again, this is just a test; feedback appreciated.

I use q in the console a lot.