| Type | Wish | Status | tested | Date | 30-Nov-2008 15:14 |
|---|---|---|---|---|---|
| Version | alpha 18 | Category | n/a | Submitted by | BrianH |
| Platform | All | Severity | major | Priority | urgent |
| Summary | Add /into option to REDUCE and COMPOSE. |
|---|---|
| Description |
A lot of REBOL's temporary memory overhead comes from intermediate blocks generated by REDUCE and COMPOSE. If we add an /into option to specify a destination block, we can reuse these intermediate blocks where appropriate. The /into option would make the functions work like INSERT: - The values would be inserted at the current position of the /into block argument. - The return position would be at the point after the insertion - otherwise you can't determine that position. This allows chaining. The destination parameter would be limited to any-block! arguments, including paths and parens. Typical usage would be to replace multiple appends or inserts. |
| Example code |
| Assigned to | n/a | Fixed in | alpha 56 | Last Update | 10-Jun-2009 01:56 |
|---|
| Comments | |
|---|---|
|
(0000263)
BrianH 9-Jan-2009 23:30 |
Refined the semantics of the proposal.
This might not be easy, but it would help a lot, and in use could help us reduce a lot of REBOL's overhead. We should consider implementing this soon after the public release. Discussions should continue in R3 chat (heading R3/Language/Options 1097). The /INTO option semantics are in message 1436. |
|
(0000862)
Carl 28-May-2009 00:34 |
Note: returns head position, not tail of insertion point.
The rationale is that the series-chaining coding style is rarely used and leads to substantial user-misunderstanding. If you disagree with this POV, please make your opinion known soon. |
|
(0000863)
BrianH 28-May-2009 01:01 |
All of the other /into option functions uses the series chaining style, and it is in common usage in REBOL code as chained INSERTs, which is the primary code pattern this proposal is meant to replace.
The main point of the standardized /into option is to encourage the series chaining style, since testing has shown that this reduces memory overhead. With COMPOSE/into in particular, it may be impossible to know what the tail position of the insertion is. The head position, the tail of the series, and the insertion point are all easy to determine - the tail of the insertion is not, except in the trivial case of inserting at the tail of the buffer. Though being able to generate other datatypes than block! is good too. |
|
(0000869)
Carl 28-May-2009 06:46 |
I have no argument with the idea of chaining, which is why I made INSERT and others work that way in REBOL. The question is if most users will understand how to use it here, and how many actually will use it in their code. (You don't see how many users tell us that they think INSERT has a bug due to this issue!)
Anyway, the reason it's important is that REDUCE is a primary, high-frequency native, so I like to keep them lean and fast. It is fairly easy to add chaining. |
|
(0000870)
BrianH 28-May-2009 06:56 |
True, it was easy to add chaining to the mezzanines that already have the standard /into option: COLLECT, EXTRACT and REWORD. As for the potential bug reports...
One great part about R3 is CureCode. It is easy to refer people reporting a particular bug to another bug report, or to have a nice description of why the behavior is intended if it is. Plus we have all that great documentation: manuals, wikis, chat. As long as we treat standard options consistently and document their behavior, people can learn pretty quickly. |
|
(0000876)
BrianH 28-May-2009 09:13 |
I have to give this a partial:
- The block argument just accepts block!, not any-block!. - The return value is at the head position, not the position after the inserted data. The rest works perfectly. Should I change this back to reviewed, or mark this as tested and make new tickets for the remaining changes? |
|
(0000919)
BrianH 10-Jun-2009 01:56 |
Complete and working in alpha 56, "Fixed in" changed accordingly. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 10-Jun-2009 01:56 | BrianH | Comment : 0000919 | Added | - |
| 10-Jun-2009 01:55 | BrianH | Status | Modified | problem => tested |
| 10-Jun-2009 01:55 | BrianH | Fixedin | Modified | alpha 55 => alpha 56 |
| 28-May-2009 09:17 | BrianH | Status | Modified | built => problem |
| 28-May-2009 09:13 | BrianH | Comment : 0000876 | Added | - |
| 28-May-2009 07:01 | BrianH | Comment : 0000870 | Modified | - |
| 28-May-2009 06:58 | BrianH | Comment : 0000863 | Modified | - |
| 28-May-2009 06:56 | BrianH | Comment : 0000870 | Added | - |
| 28-May-2009 06:46 | carl | Comment : 0000869 | Added | - |
| 28-May-2009 01:55 | BrianH | Comment : 0000863 | Modified | - |
| 28-May-2009 01:01 | BrianH | Comment : 0000863 | Added | - |
| 28-May-2009 00:37 | carl | Comment : 0000862 | Modified | - |
| 28-May-2009 00:35 | carl | Comment : 0000862 | Modified | - |
| 28-May-2009 00:34 | carl | Comment : 0000862 | Added | - |
| 28-May-2009 00:23 | carl | Status | Modified | reviewed => built |
| 28-May-2009 00:23 | carl | Fixedin | Modified | => alpha 55 |
| 26-Feb-2009 03:40 | BrianH | Priority | Modified | normal => urgent |
| 12-Feb-2009 22:20 | BrianH | Severity | Modified | not a bug => major |
| 11-Feb-2009 22:57 | BrianH | Comment : 0000263 | Modified | - |
| 2-Feb-2009 22:54 | BrianH | Comment : 0000263 | Modified | - |
| 20-Jan-2009 04:16 | BrianH | Comment : 0000263 | Modified | - |
| 9-Jan-2009 23:30 | BrianH | Comment : 0000263 | Added | - |
| 9-Jan-2009 23:30 | BrianH | Description | Modified | - |
| 5-Jan-2009 05:23 | Carl | Status | Modified | submitted => reviewed |
| 9-Dec-2008 07:36 | BrianH | Priority | Modified | none => normal |
| 9-Dec-2008 06:14 | BrianH | Severity | Modified | trivial => not a bug |
| 9-Dec-2008 06:14 | BrianH | Version | Modified | => alpha 18 |
| 2-Dec-2008 18:50 | Admin | Ticket | Added | - |