Preserving starting and ending brackets for a block.....

[jfdutcher]

How can the code below (which is inside a (300) cycle  loop) be altered  so as to place an open beginning bracket before the 1st 'regnbr' and a final ending closing bracket after the last  date value ('now')  in the 'sortBlock' which was established earlier in the script and is the object of the 'append' & 'repend/only'  functions  ? (Each non-quoted variable in the block 'repended' is a nested block itself ).
Now the 1st 'regnbr' is NOT preceded by an open bracket...and the final date value ('now') is NOT followed by an ending closing bracket after the one which closes 'sortBlock'. I presume to want these in order for the functions 'find' and 'select' to work as expected.

if (regnbr <> "XXXX") [
    append sortBlock regnbr
    repend/only sortBlock [lname fname minit docpa respdietary unitaddress        diettype dietdesc1 dietdesc2 sex race "trayvals" tray "allergies" allergys "utensils" utensils "brkbevs" brkbevs  "dinbevs" dinbevs "supbevs" supbevs "brksupps" brksupps "dinsupps" dinsupps "supsupps" supsupps "brkmenu" brkmenu "dinmenu" dinmenu "supmenu" supmenu "brkdislks" brkdislikes "dinsupdislks" dinsupdislikes "thertechs" thertechs "nourments" nourments now] 
   ]

save %/c/vetssrc/dietsys/rebdsysmst.txt sortBlock

[PeterWood]

I'm not sure that I fully understand the problem, I can see that regnbr is not included in the "data" block but it looks as though 'now will be inside the block. Regnbr should be separate from the data block if you want to use select.

Does this help?

Code:

>> blk: copy []                   
== []
>> a: [1]                         
== [1]
>> b: [2]                         
== [2]
>> c: [3]                         
== [3]
>> reg: "0123"                     
== "0123"
>> append blk reg                 
== ["0123"]
>> repend/only blk [a b c "fourth" now]
== ["0123" [[1] [2] [3] "fourth" 31-Jan-2007/8:25:59+8:00]]
>> reg: "0124"                         
== "0124"
>> append blk reg                     
== ["0123" [[1] [2] [3] "fourth" 31-Jan-2007/8:25:59+8:00] "0124"]
>> repend/only blk [a b c "fifth" now]
== ["0123" [[1] [2] [3] "fourth" 31-Jan-2007/8:25:59+8:00] "0124" [[1] [2] [3] "fifth" 31-Jan-2007/8:26:48+8:00]]
>> probe select blk "0123"     
[[1] [2] [3] "fourth" 31-Jan-2007/8:25:59+8:00]
== [[1] [2] [3] "fourth" 31-Jan-2007/8:25:59+8:00]
>> probe select blk "0124"
[[1] [2] [3] "fifth" 31-Jan-2007/8:26:48+8:00]
== [[1] [2] [3] "fifth" 31-Jan-2007/8:26:48+8:00]
>> probe find blk "0124"
["0124" [[1] [2] [3] "fifth" 31-Jan-2007/8:26:48+8:00]]
== ["0124" [[1] [2] [3] "fifth" 31-Jan-2007/8:26:48+8:00]]
== ["0123" [[1] [2] [3] "fourth" 31-Jan-2007/8:25:59+8:00] "0124" [[1] [2] [3] "fifth" 31-Jan-2007/8:26:48+8:00]]

Peter

[jfdutcher]

Peter,
You have understood perfectly and strongly aided my solution. My own code duplicated yours......what I did not know was (because I am looking at the file written to disk)....  the starting and closing brackets I referred to are NOT there on disk...hence my puzzlement. It is apparently the 'probe' function itself which presents those brackets to me when I employ it. I guess I need not care that they don't actually exist on the permanent file as long as 'find' and 'select' can present any one of the individual records as I seek them when I do a 'load' of the file to a word variable and need to work with it.

Rebol, The Offical Guide,  uses a 'do' instead of a 'load' to bring in the persistant file.
Is there any practical difference in that situation ?
John d.

[jfdutcher]

Well...to update......'probing' the word to which the persistant file was 'loaded'
will find the sought after regnbr i.e. 

save %/c/vetssrc/dietsys/rebdsysmst.txt sortBlock

vetsdb: load %/c/vetssrc/dietsys/rebdsysmst.txt
probe select vetsdb "4667"

BUT......replacing 'select' with 'find' does not succeed  after saving the file to disk first and then 'loading'  it ,  or simply doing probe find sortBlock before saving.  I don't know why 'find' doesn't duplicate your own test but will pursue.

[jfdutcher]

O.K. I yield....your example was perfect as you knew. I didn't expect to see any record displayed except the object of the 'find'......I see now that it displays that object and all that follow it. Case closed.

Thank you,   John D.