World: r3wp

I wanted a nice way to produce fragmented message strings that will 
be translated later, using a TRANSLATE function. So I made this function:

tell: func [blk /local out s] [
	out: make string! 10000
	parse blk [
		any [
			[
				set s string! (append out translate s)

    | to any-type! copy code [to string! | to end] (append out to string! 
    reduce [#"'" mold/only do code #"'"])
			]
			(append out #" ")
		]
	]
	join trim out #"."
]

>> file: what-dir
== %/c/program files/rebol/view/

>> tell ["File" file "cannot be found"]
== {File '%/c/program files/rebol/view/' cannot be found.}

>> append/only [] 'now/precise
== [now/precise]

interesting, thanks

Henrik, I don't think that's nice, because you can't really translate 
"File" and "cannot be found" separately. Don't expect all languages 
to have the same grammar structure etc.

Gabriele, probably not, but the language system, I'm working with 
works like this.

a better one would probably input the string like:

File %1% cannot be found.

Maybe I should do that...

What I did for the network detective was "File <file> cannot be found." 
See SUBSTITUTE in http://www.colellachiara.com/soft/libs/utility.r

ok, thanks

(I think that <filename> or %filename% etc. helps the translator 
a lot more than %1% or anything like that. Of course, Qtask uses 
%1%. :-)

how do you determine the order without referring to the tag twice?

ok, I see what you're doing....

Anyone got a suggestion on how to flatten the results of a SQL query.
Got [ [ "xxx" ] [ "yyy" ] [ "zzz" ]]
and want 
[ "xxx" "yyy" "zzzY ]

now
to-block form [ [ "xxx" ] [ "yyy" ] [ "zzz" ]]

does not work ... due to Rebol evaluating the contents

sure I could iterate over the whole lot and create a new block ...

>> collect [foreach item [["xxx"] ["yyy"] ["zzz"]] [keep item]]  
   
== ["xxx" "yyy" "zzz"]

Even simpler:
>> map-each item [["xxx"] ["yyy"] ["zzz"]] [first item]
== ["xxx" "yyy" "zzz"]

heh .. not used map-each or collect before .. are these in R2 ?

in 2.7.7 at least

Part of R2/Forward.

Ah... I'm using 2.7.6 and they're not there

Then just write the single line that is flatten :)

done that ...

I thought there might be some other trick I could use

well,  I will use the to-block form and if that errors out drop back 
to flatten

Try parse, it should be quick:


>> parse [["xxx"] ["yyy"] ["zzz"]] [(f: copy []) any [set b block! 
(append f first b)]]                                             
                           
== true

>> 
f
== ["xxx" "yyy" "zzz"]

Of course, it would be quicker using insert back tail but that would 
have made the one-liner longer ;-)

Nevermind, it's already verbose enough :)

parse it is then!

Speed, speed, speed! :)

well, I thought we should really have a native for this ....  where's 
Cyphre's JIT compiler??

Why should it be native?

cause its going to be A LOT faster and for things like database queries, 
this can become quite a bottleneck.

Give me some numbers. Show me scenarios where it's a bottleneck. 


I should have a second log in here. P.O., because I'm sure I Piss 
Off a lot of people by always questioning Premature Optimization. 
:-)

LOL

How about a LINE-NUMBER? function yielding a line-number of a string, 
would you want such a function to be a mezzanine?

(the function is available at

http://github.com/rebolsource/rebol-test

, BTW)

I want pretty much *everythihng* to be a mezzanine until we know 
the gains are worthwhile and will benefit enough people. That still 
gives us room to be subjective. ;-)

I am the author, so if somebody different from myself wants to have 
the function as a mezzanine, fill in a CC ticket

gregg. such simple functions cannot be optimized in rebol simply 
because the lowest-level loops are VERY slow.  this is a simple function 
which requires no special treatment.


for such a function, the moment its written as a mezz, we can't say 
"premature" optimisation... its done.   the only improvement is to 
make it 20 times faster.

You're missing my point Max. I'm saying it doesn't need to be optimal 
yet, because we have no idea if it's worth optimizing.

Heck, we don't even have it as a standard function. :-)

You are also missing another point. Graham's original statement was 
meant to be ironic :)

I missed the irony. My apologies.

Another potentially useful function: CATCH-ANY. Can be found at:

http://github.com/rebolsource/rebol-test

as well.

Post it to the idioms group in R3 chat #754, either the file, a link 
to the original, or as source in a message.

The CATCH-ANY function above catches almost all REBOL exceptions. 
One that it does not catch is HALT. Is HALT meant to be "uncatchable", 
or not?

(shall this question be CureCoded?)

My preferences are, that HALT should be catchable, since that would 
allow us to e.g. write a REBOL console in View.

catch halt could be a nice wish

Done