World: r3wp

is there a port scheme for trie:// ?

Graham, look at the filter function in LIST-VIEW.

filter-list ?

no, FILTER.

sorry, FILTER-ROWS.

I guess it's been split in several parts now, so it may be too hard 
to read.

Graham, I did that recently, where you get choices as you type. I 
had ~1000 strings though, so not sure how much it scales. I just 
indexed by the first two characters.

It seems to be working not too bad for me without a hash .. but I'll 
need to test it on a slower PC ( test inside a VM I guess ) ...

video of my current implementation http://screencast.com/t/ZGI5ZTJkOTct

Very nice Graham! Thanks for posting. 

How did you end up doing the matching?

search each one from the start :)

rebol seems fast enough

Cool. Yeah, there are times we need to use advanced algorithms, and 
times we don't.

Carl has a character by character search in Rebodex.  Not sure if 
that is any better than what you have done.

G raham a suffix tree may be what tou want for trem compleation

suffix tree?

a forest of trees where the words are on the path from root to leaf 
so at any interior node the possible compleations are the subtree 
the node you are on is the root of

if not clear blame it on post op drugs... I'm recovering from bad 
 cellulitus

It's a type of denormalised trie:
   http://marknelson.us/1996/08/01/suffix-trees/

It clearly has affected your typing!

I guess you didn't get the necrotizing fasciitis version!

So, all I need is to write a function that takes my data and builds 
the tree ...

it has affected my typing in that I have time to spend here

Since my data is also invariant ... I could save the data structure 
and send it to my users :)

if your controlled vocab chantes much it will be expensive

this is why controlled vocabularies are good

There aren't that many new drugs added to the pharmacopaiea on a 
monthly basis

The FDA makes sure of that!

sounds ideal

so how are the nodes represented?  blocks?  objects?

http://www.mail-archive.com/[list-:-rebol-:-com]/msg07839.html

if you can get away with blocks it should be cheaper , since you 
only decend,  parent is not needed just child blocks and value may 
work

Maybe Carl can add this as a native for find/deep :)

also look at prefix trees, may be a simpiler  variant for word compleation

Is there a case to be made for use/only ?

>> use [a][a: 1]
== 1
>> use/only [a][a: 1]
== [a: 1]

Replaces having to 'double bag' -
>> use [a][[a: 1]]

Am I missing an obvious equivalent?

I would say, that your equivalent is fine. Since it is not that hard 
to use the "double bag", I doubt it justifies the refinement, since 
the refinement expression isn't shorter than the expression it is 
supposed to replace.

You get longer line lengths in the standard style:

use [a][
    [
	a: 1
    ]
]

; picture a: 1 being slightly more code

vs.

use/only [a][
    a: 1
]


Partly it's aesthetics - but this is a language, aesthetics can be 
important.

It still is possible to introduce just a special "double bag style", 
which is aesthetically acceptable, IMO (I have seen it somewhere, 
so it is not my invention):

use [a] [[
    a: 1
]]

>> f: func [] [[
[        a: 1
[        b: 2
[        ]]
>> f
== [
    a: 1
    b: 2
]
>> source f
f: func [][[
        a: 1
        b: 2
    ]]

I've got diplopia!

The disadvantage of [[ is that it can be difficult to notice sometimes, 
but otherwise it seems acceptable in cases like this.

If I'm using that, I usually double-indent the surrounded code, to 
help make it easier to notice

Gab: right, it's more difficult to visually parse, and it's ugly 
(two different issues, I'd say).  Perhaps I need to use a 'double-bag 
function.

It's also mentally uncomfortable - it feels like there should be 
a way to do use/only [a][a: 1]

parse "this" use/only [mk][opt "t" mk: to end (probe mk)]

Any reason not just pull the 'use outwards?

use [mk][
   parse "this" [opt "t" mk: to end (probe mk)]
]

In that case, no.

alternatively... one could think of extending WITH (not sure if we 
ever decided if we wanted that built-in)

(hmm, no, same problem, WITH still evaluates)

The current USE does:
1. Create context of specified words.
2. Bind body.
3. Evaluate.
Chris wants to be able to remove the evaluation.

In a perfect world with no legacy issues to worry about, I would 
prefer USE to do only steps 1 & 2, and USE/DO to do all three steps.

Or, a new function could be introduced (which I might name ENCLOSE 
or COOP) which does only steps 1 & 2.


Alternatively, if there was a function which returned a context created 
from a block of words, eg:


 CONTEXTUALIZE: func [words [block!]] [ ... ]  ; Returns a new context 
 containing words without evaluation.


then you could imagine using an idiom to get steps 1 & 2, or all 
three steps. eg:

	bind body contextualize words  ; Steps 1 & 2.
	do bind body contextualize words   ; All three steps.

So Chris' example would be:


 parse "this" bind [opt "t" mk: to end (probe mk)] contextualize [mk]

(<sigh> If only BIND had its argument order reversed...)