World: r3wp
[Core] Discuss core issues
older newer | first last |
BrianH 18-Apr-2010 [16383] | If the types aren't the same the datatypes are compared, by the arbitrary ordering they have in the type list (the datatype number). |
Gabriele 19-Apr-2010 [16384] | Henrik: it's the same as SORT |
Pekr 19-Apr-2010 [16385x2] | would it be possible to have more operators? In !Mikrotik group, I am trying do some stuff for MT routerOS API. Thanks to Anton, I can now proceed. When "studying" Python code, I found segment like: elif l < 0x4000: l |= 0x8000 1) they can directly compare 'l of integer type to binary value. But I might make wrong conclusion here. But 'l is really result of len('string here') operation. But - even if so, I don't miss such an automation, as I can always write if l = to-integer #{8000} 2) Second line is more interesting - I did not find precisely |=, but found e.g. /= ... and it translates like do some operation, and assign. In this regard, the only comparable operator of REBOL is ++ or --, but in R2 this is just mezzanine, in R3 native. But if I am right, their code: l |=0x8000 R3: l: (to-binary l) or #{8000} So, if I would assume 'l being of correct type already (binary here), would it be possible to have?: l |= #{8000} Hmm, that is not probably compatible with REBOL parser and REBOL's assigment operator, which is : |
If I am completly wrong, then please ignore me, I am not that much into the language design stuff :-) But why don't we at least have & for 'and, and | for 'or shortcuts? | |
Steeve 19-Apr-2010 [16387x2] | What's the gain ? |
Anyway, you can create your own alias. In R3 > |: :or &: :and In R2 > alias 'and "&" alias 'or "|" | |
Pekr 19-Apr-2010 [16389x2] | you could use the same (R3 way) aliasing aproach in R2 too, no? |
& and | are easy to add. The gain is to have apply & modify operation. Maybe there is no gain ... Simply instead of a = a + 10, you can write in python a += 10 in Python. | |
BrianH 19-Apr-2010 [16391x2] | User-defined operators are planned for R3, but for now you have to use one of the existing operators, possibly renamed. If you can switch to prefix ordering you are less limited. |
If R2 the built-in operators are special-cased in the DO function, so you can't do the renaming trick. | |
Pekr 19-Apr-2010 [16393] | Is there any bits converter in REBOL? Or not even in rebol? I mean - how do I get from 255 or FF to "11111111"? :-) |
BrianH 19-Apr-2010 [16394] | In R3: >> to-binary 255 == #{00000000000000FF} >> enbase/base to-binary 255 2 == {0000000000000000000000000000000000000000000000000000000011111111} >> enbase/base take/part/last to-binary 255 1 2 == "11111111" The to-binary part gets more difficult in R2 because of the aforementioned bugs in the semantic model. |
Steeve 19-Apr-2010 [16395] | R2: >> enbase/base #{FF} 2 == "11111111" |
BrianH 19-Apr-2010 [16396] | Steeve, the enbase isn't the problem in R2, it's the to-binary. |
Steeve 19-Apr-2010 [16397] | debase/base to-hex 255 16 |
BrianH 19-Apr-2010 [16398x2] | To do proper integer to binary conversions in R2 you can convert the individual octets of the integer to char and then convert them to binary. I'm sure Steeve has more solutions for that though. |
As he proved while I was waiting for the post to arrive :) | |
Pekr 19-Apr-2010 [16400] | thanks .... will try to mess with it. The bug in R3 preventing to join binarries is really bad ... |
BrianH 19-Apr-2010 [16401] | I just mentioned it in the a98 call for fixes blog. |
Pekr 19-Apr-2010 [16402] | ok, thanks. Hopefully Carl notices it .... |
BrianH 19-Apr-2010 [16403x2] | I really hope we go through the CureCode tickets soon and collect all of the ones that make minor changes to core semantics, so we can do a rip-the-bandaid-off fix-them-all release soon. Before too much code is written that might depend on the unfixed behavior. |
Not a98 though - we don't want to delay the new extension model. | |
Pekr 19-Apr-2010 [16405] | it depends on Carl. I hope we get to more frequent R3 releases again. And - A98 will contain only partial Extension model implementation ... |
BrianH 19-Apr-2010 [16406] | Yes, but enough to get the code into the hands of testers that can work out the kinks. |
Ashley 19-Apr-2010 [16407] | re:Python's operators. I've always liked AutoIT's assignment operators, some of which (especially concatenantion) would be quite useful in REBOL. = Assignment. e.g. $var = 5ΚΚΚΚ (assigns the number 5 to $var) += Addition assignment. e.g. $var += 1 ΚΚΚ (adds 1 to $var) -= Subtraction assignment. *= Multiplication assignment. /= Division assignment. &= Concatenation assignment.Κ e.g. $var = "one", and then $var &= 10ΚΚΚ ($var now equals "one10") |
Anton 19-Apr-2010 [16408] | Except for the concatenation, these are C language operators. |
BrianH 19-Apr-2010 [16409x2] | These make sense in C or Python syntax, or other languages where assignment is a syntax thing, but I'm not sure that it works that well with a language with word values, and assignment that doesn't use =. I don't see how they'd fit in REBOL syntax. That is not to say that the functions that these operators represent wouldn't be useful to have - just that they would fit in better in prefix form. Just an opinion though. |
We have &= already though, it's called APPEND. | |
Ashley 19-Apr-2010 [16411] | As long as the first argument is a series ... |
BrianH 20-Apr-2010 [16412x2] | All of the operators above are modifying, and the only things you can concatenate to in R3 are supported by APPEND. So yeah. |
Series, or map or object. | |
Maxim 23-Apr-2010 [16414x5] | is there a function which looks like find but return true here: Type desktop to start the Viewtop. >> a: ["111" "222" "111"] == ["111" "222" "111"] >> b: a/3 == "111" >> same? find a b b == false |
otherwise this HAS to be added to R3 | |
something like FIND/EXACT | |
or even better FIND/SAME | |
it would also be a hell of a lot faster :-D | |
Ladislav 23-Apr-2010 [16419] | no native of this kind is available yet AFAIK |
Pekr 23-Apr-2010 [16420] | or index? being extended, to return you a pointer to the originating series? But such information might not be available to interpreter after the assignment? |
Ladislav 23-Apr-2010 [16421] | (but I wrote a corresponding function to the Identity articticle) |
Maxim 23-Apr-2010 [16422x2] | its a shame cause looping a large list manually and comparing with same? is VERY slow :-( on a 10 million sized series. my fastest FIND-SAME loop is 20 time slower than FIND, which would be much faster, since all it would have to do is compare a pointer. |
did you time it vs find? maybe its faster than mine? | |
Ladislav 23-Apr-2010 [16424] | No way, I did not optimize for speed |
Steeve 23-Apr-2010 [16425] | can't you wrap the items of the list inside objects ? In that case, it will be a find/same |
Maxim 23-Apr-2010 [16426x2] | here's my fastest one yet... I tried two so far... ;----------------- ;- find-same() ;----------------- find-same: func [ series [block!] item [series! object!] /local s i ][ i: 1 repeat s series [ i: i + 1 if same? s item [ break ] ] unless i > length? series [ at series i - 1 ] ] using until was slower probably because REPEAT is faster than UNTIL (no exit condition or series index to increase). |
steeve no... its a database like flast list of labels with corresponding data items. | |
Steeve 23-Apr-2010 [16428] | Hey it's your choice, nothing is unchangeable :-) |
Maxim 23-Apr-2010 [16429x2] | its for the list style... hehe would you rather do fill my-list/aspects/list ["Steeve" 1 "Max" 2 "Lad" 3] or fill my-list/aspects/list reduce [context [label: "Steeve" data: 1] context [label: "Max" data: 2] context [label: "Lad" data: 3]] |
note the multi-column list will use the same data interface IMHO it gets even less fun if you are using DB queries to populate the list. it also generates a lot of useless & SLOW binding everytime you change the list | |
sqlab 23-Apr-2010 [16431] | How about combining find with a loop find-same: func [ series [block!] item [series! ] /local s ][ while [s: find series item] [ if same? first s item [return true] series: next s ] false ] |
Maxim 23-Apr-2010 [16432] | that's a hell of good a idea :-) |
older newer | first last |