World: r3wp

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

Everytime I'm writing (slow, but short) code like 

	>> unique append series 'value

or (very fast, but wordy)
 
	>> any [find series value insert series value]
	>> unless find changes 'weight [insert changes 'weight]


I'm wondering whether there's a nicer way to insert a value into 
a series only if it isn't in there yet. Something in the same line 
as ALTER.

This just reeks like the perfect situation for some Guru O'Brian 
or Gabriele D'Enciclopedia to point out that there's already a REBOL 
native which provides exactly that functionality ;-)


On a unrelated side note, I'm wondering if ALTER is missing an /ONLY 
refinement, too:

	>> alter series: [] [1 2] series
	== [1 2]
	>> alter/only series: [] [1 2] series
	** Script Error: alter has no refinement called only
	** Near: alter/only series: [] [1 2] series


Would that be worth adding to R3, I'm thinking about ticketing it 
as a wish in CureCode?

insert/not-found would be nice :-)

I've written such a function often.  its much more usefull than ALTER 
in my use... I'

I guess additional refinements to a function as fundamental as INSERT 
are a no-go for performance reasons. Probably ALTER/INSERT or ALTER/ONCE 
though:

	>> alter/once [] flag
	== [flag]
	>> alter/once [flag] flag
	== [flag]


See the dance REBOL/View's FLAG-FACE is doing to achieve something 
like that (and a little bit more):

	flag-face: func [
	    "Sets a flag in a VID face."
	    face [object!]
	    'flag
	][
	    if none? face/flags [face/flags: copy [flags]]

     if not find face/flags 'flags [face/flags: copy face/flags insert 
     face/flags 'flags]
	    append face/flags flag
	]

Agree, ALTER is definitivly useless.

Not the first time someone is asking to change ALTER in a better 
usefull behavior.

Carl uses ALTER in a few scenarios, for as a toggle mechanism.

Only him uses that, I guess...

Yes, from a logical perspective ALTER behaves like XOR, where often 
one only really needs an equivalent of OR.

I'd call the function include... and it could work on strings too, 
doing a find

once
 is good too, it's short, I like shorties

INCLUDE in R3 is not a global word, in the code im currently writing

	>> include package/changes 'weight


reads very nice. Sadly, it's signature wouldn't be compatible with 
EXCLUDE, which only allows series and sets as it's second argument. 

The two refinements /INCLUDE and /EXCLUDE though would make ALTER 
more usefull.

I am more in favor of finding a short name, it's a very common idiom.

Yeah, it is a common idiom. But some symmetry to REMOVE FIND FLAGS 
FLAG would be nice, and I don't expect Carl or anyone to be willing 
to replace REMOVE FIND by another native or mezzanine. That wouldn't 
be worth it.

For now, I've decided to go with 

	>> union package/changes [weight]
	>> exclude package/changes [address]

since speed is really nothing to worry about in my case now.

I thought ALTER was going to go away in R3, because nobody uses it. 


As an example of a func that operates conditionally, it's nice, but 
I can't remember ever *needing* it.

I would still like to set up metrics to see what funcs are used most, 
for both development and production (i.e. profiling), and set up 
a rating system. There have been some ad hoc analyzers in the past, 
but no reference system.

Yes, Graham, I know. I should just do it. :-)