World: r3wp

given that to and thru do "more" in R3, it probably is not bad to 
consider it a bug. (maybe it should be considered a bug in R2 as 
well, given that FIND does work with charsets...)

Carl seems to think that he can add TO or THRU QUOTE value to block 
parsing too.

this works 


extract-dates: func [ txt 
	/local months dates days month year
][
	dates: copy []
	months: copy []
	digit: charset [ #"0" - #"9" ]
	digits: [ some digit ]
	nondigit: complement digit
	nondigits: [ some nondigit ]
	foreach mon system/locale/months [
		repend months [ mon '|  copy/part mon 3 '| ]
	]
	separator: [ #" " | #"-" ] 
	remove back tail months

 date-rule: [ copy days 1 2 digit separator copy month months separator 
 copy year digits (
		?? days ?? month ?? year
		append dates ajoin [ days "-" month "-" year ] 
		)
	]
	parse txt [
		some [
			any nondigits [ date-rule | any digits ]
		]
	]
	dates
]

extract-dates "asdf sdfsf 1 11 Jan 2008 12-January-10 fasdfsaf asdf 
as 11 2 3 3  13-Feb-08 asdfasf "
days: "11"
month: "Jan"
year: "2008"
days: "12"
month: "January"
year: "10"
days: "13"
month: "Feb"
year: "08"
== ["11-Jan-2008" "12-January-10" "13-Feb-08"]

ahh... correction, it works under R3 and locks up in R2 :(

and finally a parse rule that works under r2 and r3

	parse/all txt [
		some [
			[ end | any nondigits ] [ date-rule | some digits  ] 
		]
	]

Parse help needed here:

  http://stackoverflow.com/questions/2631125/change-part-doesnt-work-as-expected-with-parse

His style looks strange

(looks like he never read Parse doc)

He does ask a lot of simpler questions :)

I am against using change on parse input (never did it)

That operation is too slow to be serious

(I mean seriously usable)

I can understand why you would want to, though, as an advanced search/replace 
tool.

no way, you certainly cannot talk me into that

Classical...
ending: (ending: change/part start "mystring" ending) :ending

yes, that is his trouble

Ladislav, On short strings parse replacements is faster than anything 
else

especially within R3

Your statement cannot be verified, since you did not specify,what 
you mean by "short strings"

It's simple to understand, it's faster until it's not anymore, depending 
the use cases, do your own tests

Yes, "it's faster than anything else, until it's not" is a perfect 
statement, and you got my agreement :-p

:)

a short string is one that is not long. :-)

ladislav, Remark changes the input on the fly to implement function 
html unfolding, and using that improved speed by 50 times, when compared 
with traditional series manipulations.

so yes its seriously usable   ;-P

Now, I can make a bold statement: for any method distinct from the 
one using PARSE and CHANGE/PART combo holds, that it is faster than 
the above method, until it's not :-p

its not a single change/part which is the issue, its managing the 
stack, allocating all those blocks over and over... the sheer speed 
of the parse loop, blows away all the other looped/recursive algorythms 
in my usage so far.

Nevertheless, I pointed him to http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse#Modifying_the_input_series

And here I thought yesterday, wow I finally understood Parse and 
gosh it's awesome. And now I read change/part, which I used, is not 
the way to do things unless it is. I am confused! Generally, but 
also now specifically.

I think change/part is as fast as Rebol's change/part native, and 
hence usable, unless Ladislav proves such pov being somehow fundamentally 
wrong :-)

my take on "speed" is as follows - ppl sometimes object, that you 
use "interpreter". And my answer is - why should I care? The thing 
is either fast enough for me, or it is not fast enough for me. If 
you will try to edit video using REBOL level pixel manipulation, 
you surely will not be happy. But - if your app behaves real-time 
or generally time results are acceptable for you - why to worry at 
all?

Unless Ladislav proves...

 - I did too many times to not feel repeating myself. Read the above 
 reference, please.

Petr, it may be more than fast enough for small cases, or where you 
don't need maximum performance (which is most of the time). The inefficiency 
comes from REBOL having to move things around when you insert things 
into a series (list! being a possible exception).

try this way, with one replace  change may be more efficent , with 
2 replaces bith would need to be in the sccond half of the file , 
with three in the last third ,with 4 the last quarter ...so although 
there may exist pathological cases where it is more efficent it is 
best not to cater to them.  there  may also be an argument  for not 
allocating twice as much memory but iby the time your file is that 
large you are already running into problems (in r2 at least)

I updated the above mentioned Rebol wikibook section - the speed 
discussion subsection added. So, read, it, please (the latest, i.e. 
yet unsighted version!) and see also the CureCode ticket #1570, which 
is related to this issue.

the unsighted version of the article can be found here: http://en.wikibooks.org/w/index.php?title=REBOL_Programming/Language_Features/Parse&stable=0

Please, if somebody finds a good refinement name, let us know.

BTW, re #1570 - I would like to know, what BrianH thinks about the 
necessity to keep the backward compatibility in this case?

Not being a native speaker I think you "change somthing in something", 
so that gives >> CHANGE/TO "ABC" "123" == 123

(sorry, I've hit <RETURN> too early)

The above should've read 

>> head change/to "abc" "123" 2
== "12c"
>> head change/part/to "abc" "123" 1 2
== "12bc"

But it doesn't communicate very well the idea of changing to only 
a part of the second argument.

Probably better:

>> head change/take "abc" "123" 2
== "12c"
>> head change/part/take "abc" "123" 1 2
== "12bc"

Of course that has other semantics than

>> head change/part "abc" take/part "123" 2 1
== "12bc"

and may lead to new confusion.

thanks, your suggestions look sensible, although I am not sure about 
the /take one

i think, it might make more sense to actually implement the often 
talked about series-range! type. Or, have copy-on-write semantics 
for the results of COPY. (the latter would also help multithreading 
IMHO)

/take is a new very usefull function in R3, it's a good idea to use 
it as a refinement to... IMHO

Gab  YESSS!!!


it would also be nice if we could actually just set a soft-range 
to ANY series, removing the need for a specific datatype.

Re the series-range! type: did Carl already say he would like to 
have it?