World: r4wp

gab... oh yeah... copy isn't needed there.... it just evolved that 
way  :-)

Magnusson, have you looked at the REBOL manual that explains the 
parse grammar?

See also


http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse/Parse_expressions

Gregg, yes. Ladislav, I'll check that also. The example Maxim gave 
was more what I was looking for, I think. Haven't had time to test 
it yet. Thanks for the help..

There has to be something Rebol is doing beyond a simple language 
api to get level of security purported by Carl. 
What kind of pipes does it use?

What kind of pipes do you have in mind?

There's nothing much special in REBOL regarding security

My misunderstanding then. I do not even know what 'pipes' are. I 
am posing the question on behalf of another. The question started 
based on the understanding from a conversation with Carl concerning 
the security benefits of AltMe and the once pending contract with 
the CIA.

Pipes usually refer to network connections. The encryption that is 
usually employed there (SSL) is missing from many REBOL versions

Pipes can also refer to local connections between processes, but 
that's originally a Unix technology

AltME is secure for partly different reasons. We are told it employs 
encryption over the network, but we can't check that, because it's 
closed source

When AltME was introduces a decade ago, many communication systems 
were unencrypted, so it was good then. Like Lotus Notes at the time

It's also more secure because you run your own server, instead of 
handing your data to a provider. That's fundamental, as long as you 
keep the data safe on all AltME clients. Which is hard, because it's 
not encrypted on disk

Ah. Ok. Thanks so much

does anyone have time to sanity check / comment on the style of the 
following script: http://0branch.com/highlight/snippets/rfunc.r?

(i left in a couple of examples to demonstrate usage)

it's certainly quite clean looking. did not analyse the code yet.

as the title suggests, it's a fudge

One immediate note:


the RFUNC function as it is written actually modifies its SPEC and 
CODE arguments (that may be OK, but should be mentioned)

spec isn't modified

re: body, is "Function body to be augmented w/ recursion context" 
not clear? [if not, will add clarification]

Actually, the SPEC block *is* modified, but in a way that may not 
matter often

It might be better, though, to not modify it at all.

what are you referring to?

the USE function modifies its argument.

are you referring to shadowed bindings?

like, rfunc [ _recur_ ] [ _recur_ ] won't do what i expect?

it would do what you expect, but:

spec: [...]
body: [....]
rfunc [spec] [body]

would cause some modifications that may be unwanted.

sorry, I meant

rfunc spec body

hmm, i haven't considered that case

However, the USE function still (in R2) does not contain any warning 
it is modifying its BODY argument...

i just thought i was setting up a new lexical scope

You are OK, most probably, but not due to the fact that USE is not 
modifying, rather due to the fact that it most frequently does not 
matter.

i'm afraid i'm not clear on what's being mutated

THat is a complicated issue, but the principle is easy. USE modifies 
it BODY and should be treated as modifying. However, you can easily 
define a non-modifying version:

    USE words copy/deep body

...and, in most cases the difference does not matter (but still, 
I prefer to be warned)

aha, thanks

i just looked at the r2 and r3 docs, i see the issue now

so: conceptually, it shouldn't matter as you're supposed to be recursing 
rfuncs with 'recur'

but semantically it would be better to address this

updated: http://0branch.com/highlight/snippets/rfunc2.r

so, if i haven't overlooked anything else: think anyone would find 
this useful?

one more style-related:

I do not know why you used the

    do [func spec wrapped]

I guess that

    func spec wrapped

should suffice.

Marcs, It only works if the word 'recur appears at the end of your 
function (like in safe).
The code flow is never interrupted anywhere else.

You should have used the throw/catch technique instead of simply 
setting a state (true/false) to control the iterations.

Besides that, I think your code is a little convoluted (basically, 
you're just inserting the body of a function in a while loop.

ladislav: oh, d'oh -- thanks

steeve: right, the call has to be in tail position; thought i'd mentioned 
that in the docs but evidently not

[a] why would thow/catch be better here?

[b] why is it convoluted to convert to a loop?

because you could use recurse from anywhere in the function not only 
at the tail

[B] it's not by definition, it's just the way you do it ;-)