World: r3wp

we could even use this within source code, so that when it loads 
an application, shared strings are pre-linked without needing to 
do init code.

In all cases, it will be a wast of space for all the small series.

I mean in the source

but mold/ doesn't have to add surrogates if they aren't being shared. 
 The internals have reference counters to data, so it alerady knows 
if a value is shared.

you're right

it could even go a step further and check if the shared serie is 
used in the block of code being molded, but that would hamper speed 
a little bit... a /compact refinement could be used to switch this 
extra verification.

perhaps...

it sounds like an easy thing for carl to implement... it only modifies 
a very small subset of natives.

don't know :-)

Would be cool if REBOL interpreter could generate some form of symbol 
file for encapped scripts.

Not the interpreter per say but the REBOL encapsulator.

Even if we can't get that it would be cool to at least to get a some 
form of symbol file for the core.

Just think of how much more bugfixes could be made if that were the 
case.

The serialised would be acceptable, if that were the literal form 
too, instead of - make map! []


It's too bad there's no succinct way left to represent that (and 
objects for that matter)

MOLD/all generates the serialized form, and LOAD reads it. You can 
even write the serialized form literally in your scripts. For map! 
there is no problem with using the serialized form. For objects and 
functions, you'll have binding issues.

I understand that, I use that notation in some work - it's just a 
case where Rebol notation is a little less economical.

I also understand that at a point, you have to say that it's good 
enough. I use Rebol a lot and at times think, it would be great if... 
Many times I get this with apparently trivial details - but then 
perhaps I overly obsess over details.

I do wonder if as the serialized notation used an almost valid Rebol 
sequence #[] (actually, that may well have been valid at one point?) 
you could take a similar approach with regard to maps?  ![] @[]

=[] |[] - not pretty, and perhaps not as graphically immediate as 
other types, but an improvement over make map! [] perhaps?

Stackoverflow question:

     >  Is it possible to know the script/object/function that is executing 
     ?
     > If not will this be possible in R3 ?
            http://stackoverflow.com/questions/1585603


I've given an R2-ish answer.....Perhaps R3 has a better way via stack, 
debug or other guru trick

hehe, found-out Carl started to address bitsets, as new doc starts 
to appear here - http://www.rebol.com/r3/docs/datatypes/bitset.html
:-)

He also restructured a bit main R3 Doc page ....

2.100.91: PARSE: adds DO and ACCEPT. Adds COMPLEMENT on bitsets (first 
draft.)

Pekr, could you describe find/first?

Yes, although I don't know much. You can find it in Carl's own priority 
list - http://rebol.com/r3/docs/project.html, described as - "FIND 
/first with list of targets", priority high. I do remember Carl planned 
to add it because of GUI? You simply want to check on multiple targets, 
and it returns first match ...

I wonder if it has something to do with templates. Can't still see 
what exactly it does.

Same a finding a charset, except it's a set of longer values than 
single characters. Position of the first in the set found returned.

Basically the same as PARSE TO multiple (and might use the same code).

oh, so this would be possible:

find/first string ["steeve" "brian"]
== "steeve came first, brian came second"

Yup. And like TO multiple, the alternative is exponential time and 
tricky to program.

find/first/all would be cool :-)

FIND/first/all would be FIND/all.

I guess it would be. Considering that, what about find/into?

Use PARSE.

or maybe it's just as fast to:

append str copy find str2 "something"

I was thinking about the /into for appending the result to a different 
series.

I think that FIND/all would just return true/false, not a block full 
of positions.

I would hate that.

If so, I understand Steeve's suggestion for using parse instead.

I may misunderstand the proposal.

I think he means both. He just talks about TRUE/FALSE for bitsets:


One possible justification would be if FIND/all is useful for other 
series. For example, a FIND/all on a block might return a block of 
results.

FIND/all would definitely return true/false if searching bitsets.

find/first string ["steeve" "brian"] ??? I expected more of find/first 
[str1 str2 str3] value

I thought that it would serve to do lookup on multiple different 
targets ("series" switching) ....

>> find/first "foobarbaz" ["baz" "bar"]
== "barbaz"
Order doesn't matter in the values yo are searching for.

That could perhaps be useful. Generally there has been some level 
of index concurrency control with multiple series missing in R2, 
like being able to do a FORALL on multiple series simultaneously. 
I can't remember if R3 solves any of that, because it's been discussed 
quite a long time ago.

This is difficlt to do efficiently.

I know. I just want less plumbing :-)

FIND/all and FIND/first could save tons of time - exponential time.

So let's be sure to push on Carl in that regard, to get those two 
implemented. I am not sure Carl will implement stuff by the project 
plan.

so, FORALL is native in R3. that might make it harder to change. 
Otherwise I would suggest, since it uses a word for input series 
to use a block for multiple series:


forall [series1 series2 series3] [print [index? series1 index? series2 
index? series3]]
1 1 1
2 2 2
3 3 3
...