World: r3wp

I am surprised it doesn't

how can you do more with dates than just add days to them?

So why doesn't someone write a .r file you can run that adds common 
functions for other languages (i.e. basic.r would have 'substr,

I guess there are several ways it could be implemented

user.r ?

putting it in user.r?

Someone (or a group of someones) should write a .r file for the common 
languages (i.e. basic.r would include 'substr, 'peek, 'poke, etc.; 
rexx.r would include 'mid, etc.).  That way, new users from other 
languages could move into Rebol with the knowledge they already have. 
 Of course, the script flow would be different, but their favorite 
functions would be available, and they could see how to implement 
their favorite functions natively using 'source.  There could also 
be a %c.r for those coming straight from C. :-)

and things like .. cd, dir and other common dos functions

Ah, but to implement dos.r, you would have to remove about 90% of 
Rebol's functionality ;-)

Just kidding...I was being mean about how bad DOS really is as a 
scripting language. :-)

Jarod...I guess you are asking about how to add to dates.  Here is 
an example:

>> b: now/date
== 27-Mar-2006
>> b/month: b/month + 6
== 9
>> b
== 27-Sep-2006

that adds months, what about weeks?

hmm

>> week: 7 ;Defining a "constant" here
== 7
>> b/date: b/date + (6 * week)
== 8-Nov-2006

hmm

I guess I didn't need to use 'b/date, just 'b would have worked.

>> b: b + (6 * week)
== 8-Nov-2006

yeah, but I mean, let's say I took two dates, and I wanted to know 
the number of months between them, the date/month thing doesn't work

maybe if I take the number of days and divide by 12

use 'difference to get the difference between two dates

A pretty close estimate is the following: date2 - date1 / 365.25 
* 12

interesting

difference

so that returns results in hours?

Difference returns the difference in hours.

yeah, and I could continue converting that

hmm

>> ( difference now/date 1-Jan-2006 ) / 24:00 / 30
== 2.86666666666667

still dividing by 30 isn't exactly accurate

all still very interesting, though

rebol still has better date management, than say perl for example

Over a period of time, dividing by 365.25 and multiplying by 12 is 
pretty accurate.

365.24 is more accurate, though  ^.-

Thanks, Izkata.

I start with 2 dates:
>> d1: now/date
== 28-Mar-2006
>> d2: 1-1-08
== 1-Jan-2008
To calculate the number of months between them:
>> months: (d2/year * 12 + d2/month) - (d1/year * 12 + d1/month)
== 22
>> if d1/day > d2/day [months: months - 1]
== 21
To calculate the number of remaining days:
>> d1/month: d1/month + months
== 24
>> d1
== 28-Dec-2007
>> d2 - d1
== 4


So there are 21 months and 4 days between the 2 dates (if I calculated 
right).

The situation with REBOL is, that you can do almost anything with 
it. If someone should document that, she could start now and not 
be finish, before she turned 100 years old. I saw myself as a very 
competent programmer with many years of experience in many different 
languages, before I discovered REBOL. It took me a year or so do 
'get' REBOL, because it's so different. I could very fast write simple 
things, but to get in under the skin of REBOL takes some time. In 
some way REBOL is a bit hard at first, and it takes some time to 
'get' it, then suddently it become very easy.

As a function:

monthdiff: func [d1 d2 /local months days] [
	months: (d2/year * 12 + d2/month) - (d1/year * 12 + d1/month)
	if d1/day > d2/day [months: months - 1]
	d1/month: d1/month + months
	days: d2 - d1
	reduce [months days]
]

Nice...

Also, WRT language docs, there is the online dictionary and the Word 
Browser in Viewtop.

As far as what is included, this is tough because everybody coming 
to REBOL will want different things, and including all of it would 
make REBOL a complete mess. Is a substring function a good idea? 
Sure; I've written a lot of them. :-) I'm still working on a whole 
*bunch* of functions that might be useful, but they are hard to design 
well, so they are easy to use, flexible, and intuitive.

Fore example In the case of "substring", that's a bad name IMO, because 
you can use the same concept on any series, not just strings. Is 
"subseries" a good name? Does it read well? Not so much. It could 
mean different things to different people (e.g. are you looking for 
nested series values?). What about "extract", ah, that's used already, 
and what are the implied semantics if we do override it and add behavior? 
I like EXCERPT myself, but it's not a nice short word that's easy 
to guess if you're not sure what it might be called. Whatever the 
name, should there be a /REMOVE refinement, or should there be a 
separate function for that?


OK, so let's assume we have a good name now, how do you define the 
bounds? There is no range! or bounds! type in REBOL. Do you just 
use lower and upper bounds, or should it take an offset and length? 
Should we define a dialect for this? If so, how flexibile should 
it be? Can you get multiple "pieces" all at once? Can you handle 
2D extractions easily and clearly? Should you? Can you specify reverse 
extractions (e.g. from the tail)? Should it return the elements in 
reverse in that case, or should it throw an error if the lower bound 
is higher than the upper bound? etc.

So, you have to do this:
	COPY/PART AT xxx 5 10
instead of
	SUBSTRING xxx 5 14
	(or maybe SUBSTRING 5 10) 


Yeah, it's a few extra characters, but it's actually pretty expressive 
and clear.

And maybe someday we'll have one, who knows.

substring is easy one ... give me easy 'pad oneliner :-)

Sorry, mine is way more than a one-liner. :-)

never mind ... it is just it makes me think each time I need it. 
The same goes for float conversion to number based, not that 1-E 
ble format ....

IIRC Carl had once some formatting functions in his mind, maybe those 
would be good to have included into Core at mezzanine level?

I can give you mine, and I do have some one-liner versions around 
I think, but I assume you already have some, and are just talking 
about having a standard one.

I think FORMAT is on many lists. That's a *really* hard one to design 
though. So many ways it could go.