World: r3wp
[!REBOL3]
older newer | first last |
BrianH 14-Nov-2010 [6132x2] | 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. | |
Ladislav 15-Nov-2010 [6134x2] | 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. | |
BrianH 15-Nov-2010 [6136x3] | 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 :( | |
Ladislav 15-Nov-2010 [6139x3] | 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 | |
Gregg 15-Nov-2010 [6142] | +1 for consistency. |
Maxim 15-Nov-2010 [6143] | +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. |
Gregg 15-Nov-2010 [6144] | Yes, the none behavior makes sense, for USE as well, because you have told it you expect certain words to be used. |
Ladislav 15-Nov-2010 [6145] | USE3:USE2 = 7:0 |
ChristianE 15-Nov-2010 [6146] | 8:0 |
BrianH 15-Nov-2010 [6147x2] | 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. | |
GrahamC 15-Nov-2010 [6149] | Do we need an oid type? For instance this is my OID 1.2.826.0.1.3680043.8.1178. |
BrianH 15-Nov-2010 [6150] | What is that used for? And do you do math with it? |
GrahamC 15-Nov-2010 [6151x2] | it's like an ip address but it's used for real world objects |
http://en.wikipedia.org/wiki/Object_identifier | |
BrianH 15-Nov-2010 [6153x2] | 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. | |
GrahamC 15-Nov-2010 [6155x2] | and that is? |
And yes, you will want to do some math on it | |
BrianH 15-Nov-2010 [6157] | 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. |
GrahamC 15-Nov-2010 [6158] | get syntax? |
BrianH 15-Nov-2010 [6159x2] | 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. | |
GrahamC 15-Nov-2010 [6161] | no, don't think it's needed |
BrianH 15-Nov-2010 [6162] | So we don't need to do an OID type, but having support for OID would be helpful. Good catch :) |
GrahamC 15-Nov-2010 [6163x3] | 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 | |
BrianH 15-Nov-2010 [6166] | We can do that now with names and usernames. Who uses OIDs? |
Andreas 15-Nov-2010 [6167x4] | more or less arcane protocols do :) |
like snmp | |
or x.509, or ldap | |
and most likely some super complex healthcare standards do, which is where graham enters the picture :) | |
GrahamC 15-Nov-2010 [6171] | yeah ... the CDC uses OIDs for everything now |
BrianH 15-Nov-2010 [6172] | So, sounds like a good idea for a community utility module :) |
GrahamC 15-Nov-2010 [6173x2] | I had to get an OID for my medical app |
so I can report anthrax cases :) | |
BrianH 15-Nov-2010 [6175] | Are they objectifying you at work, Graham? |
GrahamC 15-Nov-2010 [6176] | this is object identifer programming |
BrianH 15-Nov-2010 [6177] | Nevermind, bad pun :) |
GrahamC 15-Nov-2010 [6178x3] | for instance , Y means yes according to the following code system 2.16.840.1.113883.12.136 |
which is in the HL7 directory | |
If you want a free OID, you can apply for one from IANA http://pen.iana.org/pen/PenApplication.page | |
Pekr 15-Nov-2010 [6181] | IIRC OID is used for snmp (simple network management protocol), and this one is really big and important ... |
older newer | first last |