World: r3wp

I'm thinking LOAD is not something I should use.  It is choking on 
records that don't conform to rebol datatypes

>> to-date form reverse parse copy/part at "*[YY-MM-DD=03-06-30]*" 
12 8 "-"
== 30-Jun-2003

Steeve,  should the last "-" be a "=" instead?

to-date form parse copy/part at "*[YY-MM-DD=03-06-30]*" 12 8 none 
 This gives the same results as above but the year is wrong 2030 
intead of 2003.

Break it down:
>> at "*[YY-MM-DD=03-06-30]*" 12
== "03-06-30]*"
>> copy/part at "*[YY-MM-DD=03-06-30]*" 12 8
== "03-06-30"
>> parse copy/part at "*[YY-MM-DD=03-06-30]*" 12 8 "-"
== ["03" "06" "30"]
>> reverse parse copy/part at "*[YY-MM-DD=03-06-30]*" 12 8 "-"
== ["30" "06" "03"]

>> form reverse parse copy/part at "*[YY-MM-DD=03-06-30]*" 12 8 "-"
== "30 06 03"

That's as far as I got on R3; I don't have R2 yet on this computer.

TO-DATE is more strict in R3. Let me see if I can figure out something 
that will work there too.

Steve's formula is really close, but I need some way to put "-" inbetween 
the yy mm dd

>> to-date map-each x reverse parse head insert copy/part at "*[YY-MM-DD=03-06-30]*" 
12 8 "20" "-" [to-integer x]
== 30-Jun-2003

>> to-date replace/all form reverse parse copy/part at "*[YY-MM-DD=03-06-30]*" 
12 8 "-" " " "-"
== 30-Jun-2003

Two solutions  -- Thanks!

Be sure to break them down as above so you know what they're doing.

And profile them to see which is better:


>> dp [to-date map-each x reverse parse head insert copy/part at 
"*[YY-MM-DD=03-06-30]*" 12 8 "20" "-" [to-integer x]]
== make object! [
    timer: 0:00:00.000023
    evals: 43
    eval-natives: 14
    eval-functions: 5
    series-made: 11
    series-freed: 0
    series-expanded: 0
    series-bytes: 731
    series-recycled: 0
    made-blocks: 6
    made-objects: 0
    recycles: 0
]


>> dp [to-date replace/all form reverse parse copy/part at "*[YY-MM-DD=03-06-30]*" 
12 8 "-" " " "-"]
== make object! [
    timer: 0:00:00.00004
    evals: 103
    eval-natives: 30
    eval-functions: 5
    series-made: 8
    series-freed: 0
    series-expanded: 0
    series-bytes: 530
    series-recycled: 0
    made-blocks: 2
    made-objects: 0
    recycles: 0
]

BrianH or Steve,   I have seen some example code showing the following:

x:	copy []
y:	[]

These are both equal right,  Why do one over the other?

They are not equal. The first makes a copy, the second references 
the original.

but the original is empty block.

Right, but it is the specific empty block. If x is modified it won't 
change the original, but if y is modified it will.

This matters more in code in a function. That function might get 
called again.

How to read the profiles above: The first is nearly twice the speed 
of the second, but creates more temporary memory.

Ok, I get the if x is modified it won't change the original,

What I don't get is that and empty block [ ] is just empty.  It is 
not like a word or anything is it?

Yes, i did see the performance numbers.  that is good to see!

The empty block is a value, even if it doesn't contain other values, 
and it is a value that can be modified.

I profile code patterns all the time, and when writing functions 
I use the best code patterns. This leads to better functions, even 
if you don't profile the whole function (which you can't always do).

Ok just so I have this. 
x:	copy [ ]    will copy an empty block that x is refered to
y:	[ ] 	   will be a reference to an empty block


how is it possible to modify an empty block without referencing it?

 y: [ ]		<-- ref empty
== []

>> append "hi" y	<-- changes that empty block
== "hi"

>> x: [ ]			<-- X is now that same empty block
== []			But I don't see the "hi" value.  -- What am I missing?

OOOOOOHHHHHH

You are missing reuse. It doesn't matter from the console, it matters 
in reused code, i.e. in functions.

I have a typo in my example.  Now I see

x is not the same empty block, it is a new block.

>> a: does [append copy [] 1]
>> b: does [append [] 1]
>> a
== [1]
>> a
== [1]
>> b
== [1]
>> b
== [1 1]

>> source a
a: make function! [[][append copy [] 1]]
>> source b
b: make function! [[][append [1 1] 1]]

This is in R3, but the rules are the same in R2.

These examples are good to see

a: does>> a: does [append copy [ ] 1]
>> b: does [append [ ] 1]

>> c: does [append x: [ ] 1]         ;<--   is this the same as b?

Is C the same as B except that you can reference that memory pointer 
by using X -- is that right?

Ok so back to my question.

A will reference a specific memory and each time it is eval, a new 
empty block is setup.

B will reference a different memory place, and each time it is eval, 
that same memory can be modified.

C will reference a different memory place, that can also be modified 
by either using C or changing X.


But is there any significant difference to the following, if both 
reference a NEW memory location that is empty?
x:	copy [ ]
y:	[ ]

Sorry, I am really trying to understand

I think I understand now Brian,

In terms of just initializing a value, both of these are only done 
once, then they are essentially the same,

But if at any time you eval X or Y a second time, then you get different 
results!!!

Thank you for explaining it to me!

(after you have modified some values into x and Y, I mean)  -- hope 
I didn't confuse others out there.

with pattern matching

>> attempt [to-date replace/all form reverse parse copy/part find/tail 
"*[YY-MM-DD=03-06-30]*" "YY-MM-DD="  8 "-" " " "-"]
== 30-Jun-2003

I have a question about the APPEND function.

>> loop 10 [x: "a" append x "b"]
== "abbbbbbbbbb"


I would have expected the the final result to be just "ab" (after 
the 10th iteration).


But in this example, X has been assigned to the string "a" and then 
"b" is appended to it 10 times.

If X has been "reset" to the letter "a" again in each interation, 
why doesn't the previous "b" also go away since X has been reinitialized 
to just the letter "a"?

you fell into the copy trap :-) x is not reset by assigning "a" to 
it.

x: copy "a" would solve that. that's why it's called the copy trap.

You mean like this:

>> loop 10 [x: copy "a" append x "b"]
== "ab"

with this, you can provide some interesting tricks to building series 
without assigning them to words:

loop 10 [append "a" "b"]
== "abbbbbbbbbb"

beware of this when making objects with series or just series that 
are copied. if you find that your series are changing in funny ways, 
it may be that you forgot to copy them.

Effectively, you are making x the _same_ as the string "a" so when 
one changes, they "both" do. as Henrik says, you want to initialise 
x to the _value_ of the string "a" instead.

It may be clearer like this
     A: copy "a"
    loop 10 [

        x: A    ;; x is the _same_ as A ... you want [x: copy A] to get its 
        value instead 
        append x "b"
    ]

as a rule of thumb, REBOL tries to reuse series as much as it can.

use SAME? to detect whether two series are the same one:

>> a: ""
>> b: a
>> same? a b
== true

>> b: copy a
>> same? a b
== false

>> loop 10 [x: "a" append x "b"]

And yet, if I repeat the exact same comand 10 times, I do NOT get 
the same result

x: "a" append x "b"
=="ab"
x: "a" append x "b"
=="ab"

no, because every time you make a new line, you are making a new 
string. in the loop, you are reusing the same string.

If you type:

>> ""
== ""


you are making a string, but you are also immediately losing it again. 
you can't use it again.

By doing this:

>> ""
== ""
>> ""
== ""

You are therefore creating two separate strings.

Ok, so the same as the loop would be:

x: "a" append x "b"
x: "ab" append x "b"
x: "abb" append x "b"  etc    right?

This means also that doing this:

>> x: "a"
== "a"
>> x: "a"
== "a"


you are creating two separate strings, both assigned to 'x and the 
last assignment overwrites the first one.

nope. :-)

The same would be:

x: "a"
append x "b"
append x "b"
append x "b"...