World: r3wp

Tom, that wouldn't work with REBOL's evaluation rules. Native or 
not, you can't write a function that way.

picky  picky    
mth:  trim/lenght  month 3

trim/to perhaps

Cut
Keep
Fit
Clear-at
Constrain

Discard
Trim-length
Truncate
Lose
Lop
Trim/to

In this sense, CUT would mean split in two parts, I think. TRUNCATE 
is accurate, but TRIM/TO is a little shorter.

clear-at (its what it does)
truncate (its what it seems to do)

in that case, I would use trunc :)

One thing I do is to remove the outer characters eg. "[Something]" 
=> "Something"

Python has good tools for dealing with these functions.

That's where a range! datatype would come in handy:

copy/part "[Something]" 1..-1

Yep

this is Gregg's substr function


substring: func [
    [catch]
    source [string!]
    spec [block!]
    /local start stop rule
][
    rule: [set start integer! '.. set stop integer!]
    unless parse spec rule [
        throw make error! "Invalid range spec."
    ]
    copy/part skip source start stop
]

You could produce a 'truncate function that uses a pair! to similar 
effect...

truncate: func [string limit [pair! integer!]][
	if integer? limit [limit: 1x0 * limit]
	string: copy string
	case [
		negative? limit/x [remove/part string skip tail string limit/x]
		positive? limit/x [remove/part string limit/x]
		negative? limit/y [clear skip tail string limit/y]
		positive? limit/x [clear skip string limit/y]
	]
	string
]

the ".." is syntactic sugar.

the dialect doesn't cope with negative offsets it seems

; This works!:

truncate: func [string limit [pair! integer!]][
	if integer? limit [limit: 1x0 * limit]
	string: copy string
	case/all [
		negative? limit/x [limit/x: limit/x + length? string]
		negative? limit/y [limit/y: limit/y + length? string]
	]
	clear skip string limit/y
	remove/part string limit/x
]

>> truncate "[abc]" 1x-1 
== "abc"

cool

I think these sorts of series maniplulations should be native

Quite, except with range! instead of pair!

copy/part "[abc]" 1..-1
remove/part "[abcd]" 1..-1

They are native, just without any unnecessary extra syntax. This 
isn't Perl, you know.

but perl rulz!

the power of a language lies partly in it's ability to express things 
concisely

>> str: "[abc]"    
 
== "[abc]

>> copy/part skip str 1 back tail str

== 
abc"

str appears twice

it's annoying

three times, if you do 

str: copy/part skip str 1 back tail str

instead of 'truncate, how about 'peel ?

If you are removing characters from both ends of a string 'strip 
would appear to be a more precise description.

Hmm.  You can strip the inner lining of something, but normally you 
only peel the outer layers :)

If that's you definition of stripping it's no wonder you live in 
NZ.

However, my preference is to add some dialect to trim ...

rather than to keep adding words

Strip mining?

Stripping paint? stripping wallpaper?

strip a joint ... = remove the contents

so, peel has a more restrictive meaning being a subset of strip.

I hope we are both joking here :)

'trim is not good fo this?

>> trim/with "[Something]" "[]"
== "Something"

it would have to be trim/head/tail/with to avoid removing characters 
inside ...

but certainly I forgot about trim/with !

Hm, it doesn't work

>> trim/head/tail/with "[Some[]thing]" "[]"
** Script Error: Invalid path value: with
** Near: trim/head/tail/with "[Some[]thing]" "[]"

I'm not a big fan of the -n syntax to mean "from the end", but that's 
just me. It's convenient to type, but doesn't provide meaning. My 
BOUNDS/RANGE dialect supports .. notation via tuples so you can't 
use negative numbers.


For the trim/strip stuff, I ended up with a bunch of related funcs 
(begins-with?, ends-with?, enclose, etc.), and it works for more 
than single chars. Not as simple as a standalone func, but more robust 
and flexible for the general case.

Why can't we have functions that return a value to the calling function, 
but then continue to do something else ?  Is this because we lack 
multithreading?

If you're not looking for further return values, you could approximate 
this behaviour by using call or launch.

too expensive

but yes, that is what we have to do at present