World: r3wp

numerous

I mean you have mulitiple outcomes in that code you have written 
but you're only checking for one

if mark: find myline "text" [
	... 

]

I don't follow what you mean.

if all [
	mark: find myline "text" 
	4 = length? mark

][
	case [

	]
]

the if isn't required here.

true

this is exactly the same:

all [
	mark: find myline "text" 
	4 = length? mark

	case [

	]
]

all [
	mark: find myline "text"
	4 = length? mark
	case [

	]

]

hehe

snap

the power of rebol will never cease to amaze me.

after a decade I still find new language tricks.  I call it the "temporary 
newbie moment" phenomenon... I've never had these moments in other 
languages.


its like finding a new trick to make your lego stuff stronger while 
having the same shape  ;-)

case [
	not mark: find myline "text" [none]
	4 <> length? mark [none]
	...

]

not so easily read  ;)

don't think so, matter of habit

is that less readable than a comnination of any/all/case/if ?
And you can align your code. 
CASE hase the most readable structure for complex tests
Why should have demonstrate such obvious thing ?
;-)

fail: [none]
case [
	not mark: find myline "text" 	fail
	4 <> length? mark 				fail
	...

]

*combination

and most of the time, it's the fastest way of doing tests

ALL is slow

Back in time digression...


I have often noticed that it is unemployed as a method for complex 
testings.

In general it's faster and more easily readable than a serie of nested 
if / else.

But to do such, the programmer must know how testings can be complemented 
and other simplification technics.

The novice programmers (whatever the language) often find it difficult 
to do it correctly.

This is probably a gap in computer education. We don't learn anymore 
the basics of Boolean algebra.

At least for me it is an important criterion to determine the general 
level of someone in computer sciences. 
If I see too many nested if / else in a program.
I think the personn lacks of solid foundations in programming.

other languages promote it based on the general suckyness of the 
case statement in most languages.

which act more like switch than rebol`s case

people often forget that IF, EITHER & UNLESS return values

such as 

val: either success? [blue][red]

instead of

either success? [ 
	val: blue
][  
	val: red
]

and either in a compose is very powerfull... cause it allows conditional 
serie content creation).

; when false, an empty block is returned and compose ignores it.

draw-blk: compose [ (either gfx? [ [pen black circle 30x30 ][    
[ ]   ])]


this example is simple but when creating very complex draw blocks 
on the fly, I often have a few cascaded compose blocks, and in some 
cases, the resulting draw block is an empty block even if it takes 
100 lines to get to that.  the language will skip the nested composes 
if an outer condition is false, so in fact, its VERY fast.

oops missing a "]" bracket in the above.

and if you optimize you can do other stuff, but it gets unreadable 
real fast.

It's not really my point here. There are advanced technics in Rebol 
to optimize the code. 
I don't  blame anyone to not know them all (me neither).

I was comparing nested (messy) testings structures vs. flat (readable) 
structures.

And the reason why people use the bad way and not the right way ;-)

of course i was talking about others not Rebolers ;-)

I know, I'm just providing other advanced rebol styles, where we 
can use the language's natural philosophy instead of applying learnt 
patterns. 


if you look at the compose example, its something completely alien 
to all other languages I have used.  Other functional languages probably 
share some of this style, but its not as elegent, or done as macros, 
or the syntax is so obscure as to make it just about impossible to 
understand in 2 mintues.

to have conditional data creation code INSIDE the data is not something 
you see in other languages.  its usually a mess of conditionals which 
try to cover all possible permutations, as you explain... 


here, there is no need since the data's structure itself will represent 
all conditions naturally and directly.


changing the structure of the data doesn't require code rewriting 
cause they are one and the same.

The optimization I really like is:

	if i = 1 [j: 2]

with:

	all [i = 1 j: 2]

when I'm reading code it seems to parse in my brain better:


 "if i equals 1 ... then ... j becomes equal to 2" vs "i equals 1? 
 j becomes equal to 2"

blocks seem to introduce a mental "pause" when I read code.

optimization ? it's slower

Faster according to Carl. I think he had a blog entry on this one. 
Something to do with "all block" being more efficient than "if cond 
block".

you're right, just tested

learned a lot :)

If 
length? none! 
returned none my code would have looked much cleaner
quite a good discussion though.... learning a lot. Thanks.

these are the tidbits we learn along the way.

there seem to be a few common milestones....  when you get to "grasp" 
that words aren't variables... that is usually one of the first big 
ones... and the big one is when you understand what/how binding really 
works.

realizing that a block can hold [ a a a ] and yet each 'a  is actually 
a different value.  ;-)

I think it was Gabriele, or maybe Ladislav that long ago posted an 
INDEX?? function that was "safe". i.e. it wouldn't crash given none. 
There's nothing stopping you from replacing LENGTH? with your own 
version, or creating a LENGTH?? func. 


There are tradeoffs of course. What may seem to make this particular 
piece of code cleaner may have a far reaching impact on other code. 
I don't always agree with Carl's design, but whenever I think he 
did something wrong, particularly early in my REBOL career, I later 
decided he was right. I still think he's wrong about a few things 
though. :-)

And in this case, it's easy to try and see if you like it.

length??: func [series [series! none!]] [
    all [series length? series]
]

also as a general learning experience.... code written by Carl and 
study it.


its very had to read, cause Carl optimised the word count so its 
ridiculously compact.. but there are a lot of little coding gems 
in some of the patterns he uses.  and it helps a lot to understand 
some of the ideas behind many functions which might look obscure 
or rarely used.

I personally prefer when a function accepts none value and doesn't 
stop with an error but returns none.

The code is more compact and I can write error handler only If I 
really need it.

AFAICT, this is the general direction which was taken in R3.   :-)

Not enough though. 

I complain too often that basic functions are sending too many errors 
instead of returning a default value (none is a good one). 
Which would allow a more compact code as you guys noticed.

why not just use ATTEMPT if you don't want errors?

errors are a good thing. forces you to tighten up your code.

R3 changed focus on errors.  indexes pop up less errors, datatypes 
pop up more errors

Thru the years I have come to the same conclusion as Henrik.  I have 
much less error trapping than I used to.  I'd rather have the crashes 
and fix them.
f