World: r3wp
[!REBOL3]
older newer | first last |
Steeve 7-May-2010 [2882] | ok, I give it a try |
BrianH 7-May-2010 [2883] | I like to think that FOR works in indexes like AT, instead of offsets like SKIP. So that seems like good behavior to me. |
Ladislav 7-May-2010 [2884] | me too |
Steeve 7-May-2010 [2885] | Brian, ticket posted |
BrianH 7-May-2010 [2886] | And refined. |
Steeve 7-May-2010 [2887] | thanks |
BrianH 7-May-2010 [2888x2] | Sorry, I had to put in a dig about #574 - it's a pet peeve with a known, already-submitted mezzanine solution. |
(stupid profiler, including its own overhead in its results) | |
Steeve 7-May-2010 [2890x2] | uhuh |
It's not refined in my head yet enough but i think 'IN needs of a redesign. Especially this form allowed by the specs but throwing an error currently. >> in [obj1 obj2 ...] [a b c d] == Error! it could be powerfull, allowing to inherit properties from a hierarchy of objects (think about nested gobs with their own context) But it's not enough... I would like that the returned block discard the unbound words. It would be consistent with the single form. >> in context [a: 1] 'b == none I don't know if i'm clear... | |
BrianH 7-May-2010 [2892x3] | That has already been suggested before (don't remember the ticket), though without the "discard the unbound words" feature that would break the code that IN context block! usually works with. IIRC it was dismissed, because IN is supposed to be a low-level function and this would slow it down immensely. |
A big O slowdown, from O(n) to O(m * n). | |
So slow that we are better off not having such a feature, having to rewrite our code so we don't need to do that at all. | |
Steeve 7-May-2010 [2895] | well, if it's discard only the unbound word (words having no context at all) there will be no sideeffect I guess in context [a: 1] unbind [a b c] |
BrianH 7-May-2010 [2896] | Remember, IN whatever block! is usually preceded by DO. You don't want to remove words from code you are going to DO. |
Steeve 7-May-2010 [2897] | or just as an option |
BrianH 7-May-2010 [2898x4] | And lit-words and refinements also get bound, so removing them because they are unbound would be bad, since they have meaning beyond their binding. And adding options to IN will slow it down too; IN is supposed to be *fast*. |
>> a: [a] same? a in self a == true IN something block! is like BIND, not BIND/copy - IN modifies. Don't remove stuff from the original. | |
IN something word doesn't modify though. | |
I think words are immutable in R3, like integers, tuples and typesets. When IN or BIND binds a block I think they replace the words they bind with new words that refer to the same symbols, but a new context. So IN and BIND never modify words - they replace them. | |
Steeve 7-May-2010 [2902] | Words Immutable you say ? >> p: to-path 'a >> x: reduce [p p p p p p ] == [a a a a a a] >> p/1: 'b >> x == [b b b b b b] lol... |
BrianH 7-May-2010 [2903] | Those are the bindings that the words point to. I am actually talking about word!, lit-word!, ... values themselves. |
Steeve 7-May-2010 [2904] | Was just a joke |
BrianH 7-May-2010 [2905x2] | You can't change the binding of a word. You can't change the symbol of a word. Either will result in a new word. There isn't anything else that makes up a word. The only thing you can change is the value slot that the word points to, but you can't change *which* value slot the word points to, just the contents of the slot. |
And that value slot is not part of the word :) | |
Steeve 7-May-2010 [2907] | hey stop i'm in your front side :) |
BrianH 7-May-2010 [2908] | Sorry, it was just weird that I just realized this now :) |
Steeve 7-May-2010 [2909x2] | don't want to be hurt... |
I was in your brain just know, was weird enough... :) | |
Pekr 7-May-2010 [2911] | A99 released ... |
Steeve 7-May-2010 [2912] | A99 downloaded... |
BrianH 7-May-2010 [2913] | Wow, that was quick! :) |
Pekr 7-May-2010 [2914] | Carl also adressed my complaint to website - it was kind of difficult to get to changelog. Now A99 is propagated even to main page of rebol.com .... small changes, but helpful ... |
BrianH 7-May-2010 [2915] | Tested, it's good! |
GiuseppeC 7-May-2010 [2916] | It seems that the migration of GUI to the external host is more difficult that expected. |
Maxim 7-May-2010 [2917] | yes Carls is struggling, but by what I hear, he really is committed to doing it. he WANTS to do it... its just that he's realizing how deeply rooted the view code is... all kinds of tricks now have to be architectured and properly APIed. |
Terry 7-May-2010 [2918] | Anyway to return the key used in a map when using find values-of map! ? |
Paul 7-May-2010 [2919x4] | Carl is suddently on FIRE!!!! Go Carl Go!!!! |
Wouldn' t it be nice to do something like this: a: 5 b: a < 10 where b gets set to the value of a instead of true? | |
We may have to include a new keyword such as bool to the mix just to get true or false when desired. b: bool a < 10 | |
Just a thought. | |
Maxim 7-May-2010 [2923] | bool: func [val][not not val] ;-) |
Paul 7-May-2010 [2924x3] | :-) |
See wouldn't that be a better way to do things? | |
That seems to be in line with simple thigns should be simple to do. | |
BrianH 8-May-2010 [2927] | BOOL: :TRUE? |
Paul 8-May-2010 [2928] | Yeah forgot we have that in R3. But we still can't do as I showed above. |
Maxim 8-May-2010 [2929] | yay TRUE? is in R3 :-) |
BrianH 8-May-2010 [2930] | Oh, you are right Paul, I was looking at Maxim's code, sorry. You want Icon-style conditionals, not TRUE?. Not sure how to fake that. |
Paul 8-May-2010 [2931] | It's a feature I use in C# often. |
older newer | first last |