World: r3wp

Lost me there.

This type of function is quite fast in native rebol.

it's just a pain to write.

the power of a language can be measured by how few symbols are required 
to perform a given task.

I don't think so. It all depends on the functionality you want.

Well you can create your on slice function.

don't want to :)

I want native handling that is expressive, and short

Graham, I don't think that's a very good measure. REBOL isn't Perl, 
you know, but that doesn't make it less powerful.

But also it assists in debugging programs.  It is well known that 
the number of errors per line is fairly constant.  You reduce the 
number of words you use with a powerful language, and this leads 
automatically to reduced number of errors since you need fewer lines.

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 can create your own dialects and grammar. But don't ask for everything 
to be written to your liking.

substring "abcd" [2 .. 3]

; 1-based indexing
slice: func [str start len] [copy/part at str start len]
; 0-based indexing
slice: func [str start len] [copy/part skip str start len]

Fill in with doc strings and [catch] attributes, but the algorithm 
doesn't have to be hard.

which is briefer ?

substring "abcd" [ 2 .. 3 ]

and "abcd"/[2 .. 3]

The first one, because you can tell what it's doing without having 
to remember more syntax.

I'm not saying that Rebol should be Python, just that it could be 
useful this way.

How about:  slice "abcd" 2 3

The '.. in my small dialect block is pure syntax sugar and un-necessary 
but easy to remember for some people.

[2 .. 3] hints that it is a range.

yeah

so, "abcd"/[ 2 3 ]

You don't need a dialect processor and its overhead for what is essentially 
a library function.

That could have more than many menings.

BrianH agreed. I'm just saying that if you want to use other language 
syntax you can always create a dialect.

what's the difference between

series/1

and 

series/[ 1 ]

I prefer to create a translator for those purposes. Syntactic sugar 
is nice, but I like my runtime code to be on a diet.

Rebol is the translator :)

Brian depends on who is coding and for what purpose? But I am with 
you.

series/1 has clear defined meaning under rebol. series/[1] is undefined.

looks like I'm outnumbered here ... so I'll just withdraw to my corner 
:)

No, REBOL is the runtime. A dialect processor only counts as a translator 
by my standards if the translation is only performed once rather 
than every time the operation is performed. Other languages can have 
tons of syntax because they are compiled.

For that matter, series/[1] violates REBOL data syntax for paths, 
AFAIK.

mere detail

Graham you want an enhance notation. I think you will do well with 
just a func.

If your dialect processor is a compiler, then cool. If it is an interpreter 
then its overhead should be as low as possible, at least in proportion 
to the overhead of what it is accomplishing. No dialecting for dialecting's 
sake, at least for production code.

Well, since I use pre-rebol, I guess it could be modified to turn 
the source into what I want.

See, now you're getting it! :)

But dialecting is good. Ask greg about it.

Some dialects are one time use only others are not for example DRAW

A lot of the time I do my dialect processing with functors, functions 
that create functions. Sometimes these functors run in pre-rebol, 
some at runtime function creation time. Then the actual work is done 
by the generated functions. This gives me the advantages of dialects 
without the drawbacks. On the other hand, dialects like draw are 
examples of my principle of low overhead in proportion to the that 
of the work performed - the dialect overhead isn't that much different 
to that of a series of function calls in the do dialect.

Adding things like this to path notation hides a lot of compuational 
complexity. Sometimes that's a very good thing, and sometimes it's 
not. And consider what should happen in the case that "my-block/[2 
3]" refers to a two-dimensional array, or a block of name value pairs; 
what should the result be? Something like that fits very well in 
a dialect where the power is leveraged, and the domain is tightly 
constrained. That's where we get power and safety combined.

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlGGHC

for shortness, we can use short function-names, sl: :slice  sl string 
2 4 .
If we play with extensions, i propose an operator '..
  s/2 .. 4

I suggest we just adopt the Python syntax for slicing strings, and 
accept that this is a dialect for handling string slicing, and not 
2 or more dimensional arrays.

And other one dimensional series.

Is there any way to send email in such a manner as to cause a window 
to pop up on the recepient's email client requesting confimation 
that they received the email?

Yes, and I presume that it is one of the X- type fields.

Do you have a link to some how to info?

nope .. do a google search.