World: r3wp

I say it again, you didn't give us the real output. Doing some assumptions, 
i got this.

varA: { \'hello\'s ^{Worlds \';}
varB: {
 'and ^{so "on';
}

print rejoin  [{<button onclick="alert('} varA {');">CLICK ME</button>} 
varB ]


<button onclick="alert(' \'hello\'s {Worlds \';');">CLICK ME</button>
 'and {so "on';

So where is the burden ? i don't see one

Should probably put this in rant.. but just spent the last hour wondering 
why my function wasn't working

result: sofp 'firstname'

the solution? change the single quotes to double.. aye carumba

Steeve, it's cumbersome.. I spend more time joining and escaping 
than anything else.

From all this, the easiest way would be to produce a dialect that 
does its own escaping, so you don't have to write JS at all.

rephrasing that: not "easiest way", but easiest to use in the end.

as anyone tried to run cheyenne or rebol on sheevaplug ( http://www.globalscaletechnologies.com/t-sheevaplugdetails.aspx
)

Good stufff

does anyone have a rebol based bracket checking tool? preferrably 
something that can be integrated into a diagnostic tool.

hey ?

e
	)

I have the code:
case equal? length? find myLine "text" 4 [...]
It fails on ==none
I can do it in more lines of code but was wondering the 
shortest way to get past this.
Any suggestions?
tia

what happens if you don't find the text ??  It gives none

yes that is correct

I'd like to ignore if it gets 'none'

so you have multiple conditions but you're only checking for one

yes have numerouse cases

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