World: r3wp

Darn, I had to look at the types-of to be sure. It's #1509.

Thanks, Brian, That was quick -- you know your error codes!

Only the top dozen most important ones.

Ah, there will _always_ be a top 12.

Am I to understand, that some of the USE3/USE2 variants would do 
that?

Just a joke, because the talk here is awfully mathematic, while REBOL 
is based more on English

The words of REBOL are based on English. The semantics are based 
on math (though not always arithmetic).

Ah, so I was right that you would like REBOL to become Haskell

Haskell is based on some of the same math, but mostly different math. 
More lambda calculus, less (I don't remember the name for the math 
of languages with state modification).

Brian: "And if we are really concerned with initializing the values" 
- actually, I am not. I am more like one of those wanting to have 
it the same way in functions as well as in other locals. (like Henrik, 
Oldes, Anton, Andreas). That is currently the same in USE, which 
I do not object against. This way, only object (and module) fields 
are currently initialized to #[unset!], although in the newly proposed 
LET we can choose. BTW, it looks to me, that it is good, that LET 
can accept any-word!, i.e. be more flexible than USE.

On the other hand, I am not sure, whether it is a good idea to allow 
empty VARS block in LET - that looks like a user error to me.

(if I do not need any local variables, then I do not need to call 
the function creating them)

Empty vars or values blocks, like all of the other assignment-related 
characteristics of LET, serves the same purpose that they do in SET. 
Remember, a lot of the time LET will be used on data, not just inline 
words and values. Sometimes you want to screen for #[unset!], because 
being screened for is the whole point to that datatype, so setting 
it should be an option like it is with SET. Other times the words 
will be collected from the body, such as with COLLECT-WORDS/set. 
It is not necessarily an error if there are no words - it depends 
on the programmer's intention.

Doing a block with set-words set to a local context and initialized 
to none: let collect-words/set block none block. Still correct if 
there are no set-words.

Yeah, working with any-word! is good. I first read any-type!, so 
that is why I rehashed the unset argument, sorry.

My note to the "rehashed #[unset!] argument": I like the "The whole 
point of #[unset!] is to trigger errors" formulation. Nevertheless, 
it is broken in a big way by USE and function contexts. Only any-object 
contexts adhere to this convention now, so it is an error to write.:

context [
    print a
    a: 1
]

, while a corresponding

use [a] [
    print a
    a: 1
]

would be an error in R2, but not in R3 anymore, while

do has [a] [
    print a
    a: 1
]

was not an error even in R2.


Therefore,  "The whole point of #[unset!] is to trigger errors" is 
true, but, as demonstrated, the #[unset!] value is sneakingly losing 
its point to the extent, that it is becoming negligible. BTW, this 
is one more "arms race", which a protection measure is losing when 
confronted with the freedom of a programmer to write code he likes 
to write. The previous victim of this race in the datatype space 
seems to be the #[none!] value (at least to me).


I do not object, since due to the changes the #[unset!] value is 
becoming more of an annoyance, than a useful bug protection. And, 
there are other benefits, like increased compatibility between USE 
and functions, exactly as the discussion revealed, as well as the 
fact, that the protection was never as useful as it was planned to 
be.

What I see as the only problem of #[unset!] losing this arms race 
is the fact, that we will still have "debris" in programs like GET/ANY, 
SET/ANY, LET/ANY, even after the resons to have them become sneakingly 
nonexistent.

Yeah, but I'm still glad to have unset for exactly the reason it 
was intended for. Though the new unset in R3 is the unbound variable, 
which is even more useful.

I need some error to trigger to point me to my typos :)

I suppose you would consider the unbound variable errors to be the 
next round of the arms race though. It is getting to be a tiresome 
metaphor :(

Maybe I surprise you, but not. The reason why is, the unbound variables 
are not a "new datatype to enforce something", they are an existing 
datatype used for a reasonable purpose, and not starting a new round 
of "war" introducing some GET/WHATEVER.

But, being at it, there is one annoyance I perceive:


1) the variables bound to a function context don't cease to exist 
even when the function is not running
2) code like:
    f: func [/a]['a]
    block: [a]
    bind block f

do not work, while I can do such a bind on my own without needing 
any permission:
    change block f
So, this is clearly just an annoyance, and not a useful feature.

and, being at it, yet another annoyance of exactly the same kind 
is:

o: make object! [me: 'o]
error? try [bind 'self o] ; == true
bind [self] o; == [self]

, i.e. again, one can bind as wished, so the "feature" is just meant 
to be annoying, not useful

+1 for consistency.

+1 for consistency, as long as functions keep their implicit initialization 
to none.  


to me this is a feature, one which I have relied on in all my REBOLing.

Yes, the none behavior makes sense, for USE as well, because you 
have told it you expect certain words to be used.

USE3:USE2 = 7:0

8:0

Pleasantly surprised, thanks :)

About the annoyance, that is a side effect of two things combined:

- Starting with R2 we got direct binding, rather than dynamic binding, 
for a 30X speedup IIRC.

- Starting with R3 we got stack-relative contexts for functions, 
for security, task safety and better recursion safety.


You can't have the words in functions lose their bindings once the 
function returns because they will need those bindings the next time 
the function is called, and you can't rebind because definitional 
binding depends on the order of binding operations. So instead the 
context becomes invalid. It's an annoyance, sure, but it is more 
of an understandable side effect of some *extremely* useful features.

Do we need an oid type?  For instance this is my OID 1.2.826.0.1.3680043.8.1178.

What is that used for? And do you do math with it?

it's like an ip address but it's used for real world objects

http://en.wikipedia.org/wiki/Object_identifier

It sounds like we can use the same approach as with the IPv6 addresses: 
string syntax, binary data.

Datatypes aren't necessary as often as you think.

and that is?

And yes, you will want to do some math on it

Is it critical that they get syntax? It looks really ambiguous with 
tuple syntax. It looks like a user-defined datatype would help here, 
as they can do math with the actions but won't get syntax.

get syntax?

Be loaded in literal form by LOAD. That is the only advantage of 
a datatype! over a utype!.

The same could be done with IPv6 addresses. But both of those could 
have all of their support functions implemented in a module with 
regular functions and commands in it and you would have the same 
functionality now, before utypes start working.

no, don't think it's needed

So we don't need to do an OID type, but having support for OID would 
be helpful. Good catch :)

I guess the sort of operations you want to do are to compare oids, 
add leafs etc

Here's a possible example of use.  Carl could be assigned an oid, 
and then he could sub assign an oid from his root to Andreas.  Andreas 
can now uniquely identify each of his builds with an oid as can Carl 
with no overlap.  We can tell from the tree where they lie.

And likewise Henrik can release his own GUI builds with his oid set

We can do that now with names and usernames. Who uses OIDs?

more or less arcane protocols do :)

like snmp