World: r3wp
[Core] Discuss core issues
older newer | first last |
Andreas 16-Mar-2011 [1070x3] | >> first 'a/b == a >> second 'a/b == b |
Which is why just APPENDing a path! to a block! separately appends each component of the path, just as for other series: >> append t: copy [1 2] [3 4] == [1 2 3 4] >> append t: copy [1 2] 'a/b == [1 2 a b] | |
If you want to append a series as a whole to another, you use the /only refinement: >> append/only t: copy [1 2] [3 4] == [1 2 [3 4]] >> append/only t: copy [1 2] 'a/b == [1 2 a/b] | |
Rebolek 16-Mar-2011 [1073] | I think that the help for append should be corrected from: /only -- Only insert a block as a single value (not the contents of the block) to /only -- Only insert series as a single value (not the contents of series) |
Andreas 16-Mar-2011 [1074] | Absolutely! |
Gregg 16-Mar-2011 [1075] | Not sure on that Bolek. It might then be confusing in the other direction, where appending a string without /only could be expected to append the individual chars. Since path! is any-block! the existing help is OK IMO. |
ChristianE 16-Mar-2011 [1076] | Seems like it's neither block!s alone nor all series! values, seems like it's any-block! values which append/only inserts as a single value only. |
Gregg 16-Mar-2011 [1077] | Yes. I guess it could say "Appends any block value as a single value" to be a little clearer. |
ChristianE 16-Mar-2011 [1078] | /only -- Appends any block value as a single value only (not the contents) Is that good enough english to probably suggest it for R3 in curecode and R2 rambo? |
Gregg 17-Mar-2011 [1079] | The English is fine, but is it really more meaningful? |
Endo 17-Mar-2011 [1080] | Why FORMing a datatype! removes the ! char? We cannot get it back to datatype without adding a ! to the end: to-datatype to-word form integer! ;not working to-datatype to-word join form integer! "!" ;ok is this a bug, if it is by-desing what is the reason to remove "!"? |
Rebolek 17-Mar-2011 [1081] | I think it's by design. FORM makes values "more readable". You'd better use MOLD for what you need. |
Endo 17-Mar-2011 [1082] | yes MOLD is better use, thank you. I just curious about why FORM removes ! char. I think it prevents to manually remove ! char in this kind of situations: a: 5 reform [a "is an" type? a] >> 5 is an integer |
Rebolek 17-Mar-2011 [1083] | Yes, I think this is exact user-case for FORM. |
Geocaching 17-Mar-2011 [1084] | Hello Just a basic question: when creating or resetting a string! or a block!, should we do a: "" b: [] or is better to do a: copy "" b: copy [] I tend to do the second way... Does it make a difference? If yes, which way is better. Thanks |
Ladislav 17-Mar-2011 [1085x3] | This is the difference: >> my-code-a: [a: "" append a #"x"] == [a: "" append a #"x"] >> do my-code-a == "x" >> my-code-a == [a: "x" append a #"x"] >> my-code-b: [b: copy "" append b #"x"] == [b: copy "" append b #"x"] >> do my-code-b == "x" >> my-code-b == [b: copy "" append b #"x"] |
Which one is better may depend on the application | |
usually, though, the latter is safer | |
Geocaching 17-Mar-2011 [1088x2] | Thanks ladislav |
The bahaviour of my-code-a is confusing... What could be the point to do a: "" then? | |
Ladislav 17-Mar-2011 [1090] | E.g. if you want such a behaviour, i.e. if the effect is desired. |
Geocaching 17-Mar-2011 [1091] | the statement a: "" is useless... You could obtain the same behaviour without repeating a: "" |
Ladislav 17-Mar-2011 [1092] | Certainly, I prefer the latter, like you do. |
Geocaching 17-Mar-2011 [1093] | ??? >> my-code-a: [a: [] append a 'x] == [a: [] append a 'x] >> do my-code-a == [x] >> do my-code-a == [x x] >> a: [] == [] >> a == [] >> head a == [] >> do my-code-a == [x x x] >> a == [x x x] what is the logic behind this? How could a be empty after a: [] and be filled will three 'x after just one call to do my-code-a |
Ladislav 17-Mar-2011 [1094] | :-D you need to consult the MY-CODE-A block contents |
Rebolek 17-Mar-2011 [1095] | Because oit's different A |
Ladislav 17-Mar-2011 [1096] | (or, be careful, and use the copy [...] construct) |
Geocaching 17-Mar-2011 [1097] | Rebolek: both calls to 'a are in the same context (root context) How could we have two different 'a in the same context? |
Ladislav 17-Mar-2011 [1098x2] | The variable is not different, Francois, but the blocks are |
it's like a: [] a: [1 2 3] how come? that after no insert at all I get three elements in an (originally empty block? ;-) | |
Geocaching 17-Mar-2011 [1100] | Sorry... i do not understand... >> a == [] >> a == [x x x] |
Ladislav 17-Mar-2011 [1101] | >> my-code-a: [a: [] append a 'x] == [a: [] append a 'x] >> do my-code-a == [x] >> do my-code-a == [x x] >> a: [] == [] >> my-code-a == [a: [x x] append a 'x] >> do my-code-a == [x x x] >> a == [x x x] |
Rebolek 17-Mar-2011 [1102] | The first A is defined inside MY-CODE-A block. And because you do not use copy [], it's not rewritten every time you call MY-CODE-A block. |
Geocaching 17-Mar-2011 [1103] | OK... it is a quiestion of pointer assignement in some way... |
Ladislav 17-Mar-2011 [1104x2] | why pointer? by doing my-code: [a: [x x]] I just assign the block that is the second in MY-CODE to A |
same? a second my-code == true | |
Geocaching 17-Mar-2011 [1106] | It looks to me like everytime you call my-code-a, you assign the block defined in my-code-a to the variable a which is globally accessible. When you write a: [] outside my-code-a, you assigne another block to a... a is a pointer and you swith the adresse it is pointed to. >> my-code-a: [a: [] append a 'x] == [a: [] append a 'x] >> do my-code-a == [x] >> a == [x] >> a: copy [] == [] >> append a 'y == [y] >> a == [y] >> do my-code-a == [x x] >> a == [x x] |
Ladislav 17-Mar-2011 [1107x3] | To explain it even futher, here is yet another example: >> my-code-c: [a: []] == [a: []] >> do my-code-c == [] >> append a 'x == [x] >> my-code-c == [a: [x]] |
hope, it is clear what is going on | |
just forget about pointers, please | |
Geocaching 17-Mar-2011 [1110] | sorry... C bad habits :) |
Ladislav 17-Mar-2011 [1111] | Example prolonged: >> my-code-c: [a: []] == [a: []] >> do my-code-c == [] >> append a 'x == [x] >> my-code-c == [a: [x]] >> a: [] == [] >> my-code-c == [a: [x]] |
Geocaching 17-Mar-2011 [1112] | thanks ladislav... i got it!!! |
Ladislav 17-Mar-2011 [1113] | An even longer one: >> my-code-c: [a: []] == [a: []] >> my-code-d: [a: []] == [a: []] >> do my-code-c == [] >> append a 'a == [a] >> my-code-c == [a: [a]] >> my-code-d == [a: []] >> do my-code-d == [] >> append a 'c == [c] >> my-code-c == [a: [a]] >> my-code-d == [a: [c]] |
Endo 17-Mar-2011 [1114x2] | Why core doesn't support clipboard port? |
Oh, I just find it is already in RAMBO. | |
BrianH 17-Mar-2011 [1116] | Consistency between OS platforms. On platforms other than Windows, /Core doesn't need X or any other kind of GUI, and so doesn't require the libraries (good for headless servers). When there is no GUI, there is no clipboard. The Windows version of R2 just inherited this. |
Gregg 17-Mar-2011 [1117] | you assign the block defined in my-code-a to the variable a In addition to not thinking in terms of pointers, the REBOLish view of the above would be "You set the word a to refer to the block defined in my-code-a"; words refer to values, values are not assigned to words. An important distinction. |
Ladislav 18-Mar-2011 [1118x2] | I would like to disagree in this case. Not that it is important, but, in my opinion, the expression a: [] can be considered "assignment", whatever that means. In that sense, the value is "assigned" to a variable. |
What is more curious in the "You set the word a to refer to the block defined in my-code-a" is the word "defined". The truth is, that MY-CODE-A is a block, that is created by the LOAD function at (roughly) the same time its contents, including the above mentioned subblock, come into existence. | |
older newer | first last |