World: r3wp

You can sort of trick your way around things with ops in most cases. 
e.g.

	>> fn: func ['op a b] [op: get op  op a b]
	>> fn < 1 2
	== true


But I avoid doing that. It ends up not being worth it, IMO, when 
you start to reuse things, generate code, etc. Just use func alternatives.

heh but cool Gregg.

; Here's a thought:

	any-where: func [series [block!] test [block!]][
		foreach value series compose [if (test) [break/return value]]
	]

	probe any-where [1 2 3 4][value > 4]
	probe any-where [1 2 3 4][value >= 4]
	probe any-where [1 2 3 4][value < 4]


; I know it's a two block solution, but it's pretty language friendly. 
 You can recycle tests too:

	test: [value > 4]
	probe [1 2 3 4] :test
	probe [5 6 7 8] :test

Oops, forgot the function at the end there...

Very nice Chris!

It's kind of like an "apply-any".

simple problem:

>> a: [1 2 3 4 5]
== [1 2 3 4 5]
>> b: at a 3
== [3 4 5]
>> a
== [1 2 3 4 5]
>> b
== [3 4 5]
>> remove a
== [2 3 4 5]
>> b

== [4 5] ; I wonder if it's possible to make the index "sticky" at 
[3 4 5] in a relatively simple way. If it were, that would be very 
cool.

copy it first!  :)

nope, it has to be the same series

and if you copy the index? as well?

it must be the same series

Unless this is a feature request, you'll need an alternative to remove...

half a feature request and half trying to find a quick way to solve 
it. seems there is not an easy way.

can you just get around the problem by setting a: next a   ?

yes. that's janitoring of the index, which could be prone to bugs, 
etc.

yeah you'll definately have to be more judicial with your code but 
I'm thinking that the mechanics of it is the way it is intended to 
operate.

yes, it is. it would be too hard to track from inside rebol when 
an index should move.

(but if it were possible, some code would be greatly simplified)

>> a: make list! [1 2 3 4 5]
== make list! [1 2 3 4 5]
>> b: at a 3
== make list! [3 4 5]
>> a
== make list! [1 2 3 4 5]
>> b
== make list! [3 4 5]
>> remove a
== make list! [2 3 4 5]
>> b
== make list! [3 4 5]

Let's talk memory...

I that in the following the 10 represents 10 "bytes"?  a: make string! 
10

So how to we define those things in a block?

I know we can initilize the block with for example:

a: make block! 10 

But how do we determine what is in the block comprises a byte?

I know that in a string each character represents a byte but even 
then how much overhead is allocated merely by a: make string! 0?

These are the kinda things I wish Carl would go over so we can best 
optimize our use of memory.

interesting, dockimbel. thanks.

There is a lot of information about Rebol's memory usage in the mailing 
list archive. You culd start here: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-topic-index.r?i=memory

I have reassociated my scripts in windows with the new 2.7.6 core 
but I now get an error whenever I attempt to open them which is:

** Access Error: Cannot open /C/Documents
** Near: do/args script system/script/args

Any ideas?

It appears to see a broken path and sees the rest of the path as 
an argument.  Not sure where it is checking yet to get this information.

Fixed it.

I went into the registry and found the reference to rebview and deleted 
its registry keys and reassociated the .r extension with the rebol/view 
2.7.6 product.

; request for comments --

assert-all: func [cases [block!] /local value][
	until [
		set [value cases] do/next cases
		unless value cases/1
		cases: next cases
		any [not value tail? cases]
	]
	value
]

Usage:

	assert-all [
		a < 10 [print "a is more than 10"]
		a > 0 [print "a is less than 0"]
	]


It's the opposite of 'case really.  If any of the cases are false, 
the related block is evaluated and the function returns none/false. 
 If all cases are true, it returns the value of the last successful 
case.

Why would we need that as opposed to just changing the current evaluation 
of existing case?

I would like to see a good implementation of a function that performs 
a sequence of code blocks. If a code block is good, the next one 
is run. If the code block causes an error, a secondary code block 
that is either generic for all code blocks or specific to that particular 
code block is run. I'm thinking step-by-step code that either runs 
successfully or causes a generic or specific error.


I don't know if it makes sense to do that, but I sometimes miss that 
if I need to do something with user friendly network connectivity.

although I've recently switched to state machines for that kind of 
code.

all-nots ?

Paul: it's a common enough pattern, I'd like to find the most appropriate 
way to express it.  Actually, that's the principle behind QM (which 
of course, this is intended for).  The alternative case above would 
be:

	case [
		not a < 10 [print "a is more than 10"]
		not result: a > 0 [print "a is less than 0"]
	]
	result


Requires a 'not statement for each test, requires an extra word to 
track the result and does not return a meaningful value.  Consider 
this:

	if assert-all [

  user/has-role? 'editor [make error! "You do not have required permission"]
		article: get-param 'article [redirect-to %/articles/create]
		10'000 < length? article [make error! "Article is too long"]
	][
		save %article.txt article
		redirect-to %/articles/list
	]

Henrik, how does your scenario differ?  Do you have a sample of your 
solution at work?

I had a function that does this a while ago, but I have to dig it 
up

Graham, I'm still pondering naming.  'assert seems to evoke unit 
tests, that's not what this is.  'all-nots doesn't quite get the 
essence either.  'all-else is a possibility?  Until then, I still 
lean toward 'assert-all.

H: is this the type of problem you were addressing?

That is, I have a series of tests, each requiring a case for failure...

Chris, I guess it could work.

I'm curious re. approach, expression and naming...

found it, but I remember it being more elegant than the code I found 
here...

sorry, it does not work very well. I think I would build a new one 
from scratch if I needed it again.

I get that -- a sign of personal progress, perhaps?

well, I tried a single line of code with it, and it didn't do what 
I wanted. I guess I could ask myself if I would write that kind of 
code today. :-)

Chris - 'case is native so even adding a 'not statement is going 
to be faster solution I think.