| Type | Issue | Status | dismissed | Date | 28-May-2010 21:49 |
|---|---|---|---|---|---|
| Version | alpha 99 | Category | Native | Submitted by | meijeru |
| Platform | All | Severity | not a bug | Priority | normal |
| Summary | COMPOSE with empty paren! does not give unset! as could be expected |
|---|---|
| Description | See code; is this a bug or a feature? |
| Example code |
>> type? first compose [()] == none! ;; looks like the paren! is not evaluated to unset! as below >> type? () == unset! ; The behavior of COMPOSE >> compose [()] == [] ; the paren is evaluated to #[unset!], and the #[unset!] is interpreted as nothing >> compose [(())] == [] ; same as above |
| Assigned to | n/a | Fixed in | - | Last Update | 8-Jun-2010 17:40 |
|---|
| Comments | |
|---|---|
|
(0002379)
Ladislav 31-May-2010 08:01 |
Right, this property looks inconsistent. As far as I am concerned, I would like the http://www.rebol.net/wiki/Replacement to be taken seriously, since it explains, why Compose is not optimal. |
|
(0002380)
Ladislav 31-May-2010 08:15 |
Regarding #[unset!] - the behaviour of this value is not "stable", I would say (there are changes between intepreter versions). Currently, it is quite "first class" (gettable, settable, obtainable as expression result, having a source-code representatation #[unset!], returnable, passable), although that might have been unintended.
Just for the record, the other alternative is to keep it as "non-value", meaning, that no REBOL expression would be allowed to yield it as its result. This property would certainly improve its usefulness for protection against user typos in variable names. |
|
(0002381)
Steeve 1-Jun-2010 14:25 |
In the first alpha releases, compose [()] returned [unset!].
But it made a big fuss during that time, because of the lost of a VIP feature of R2: the ability to build blocks with optional tokens. I use compose in this way a lot in my scripts (as a macros builder) and I'm not the only one, I can ensure it. So, don't reopen this old debate. |
|
(0002382)
BrianH 1-Jun-2010 23:22 |
Meijeru, the paren is evaluated to #[unset!], but any #[unset!] is interpreted as nothing when returned from the paren in COMPOSE. Not #[none], nothing at all, as if the paren is not there. It's one of the better features of COMPOSE.
Ladislav, COMPOSE is good for what it is currently used for. As Steeve notes, its current behavior works quite well for many people. If it isn't optimal for someone, the best thing to do is for someone to create a new function that *is* optimal for them, as you did on that page you linked, which we take seriously. The purpose of that page was to generate suggestions for new functions. Documenting the strengths and limitations of the existing functions was a bonus, to help us see where there were needs for more stuff. It's too bad that people stopped making suggestions - I hope that more will come someday. Steeve, I remember the old debate; too bad it predated CureCode. I guess that this ticket will have to serve as the documentation of this particular design choice. |
|
(0002390)
Ladislav 7-Jun-2010 16:37 |
"COMPOSE is good for what it is currently used for" - I reserve my right to disagree, as noted above.
"its current behavior works quite well for many people" - are you sure everyone of COMPOSE users would not prefer a better alternative having the choice? "If it isn't optimal for you, the best thing to do is create a new function that *is* optimal for you" - it is beyond my understanding, why you are suggesting me to do that, knowing, that I have done (with your help) just that quite long ago. "It's too bad that people stopped making suggestions" - I see at least one suggestion in there, which is quite old, and still was neither accepted nor refused, and, to me, the page looks complete. If it does not look complete to you, it looks like your turn to add what you see as missing |
|
(0002391)
BrianH 7-Jun-2010 21:19 |
"as you did on that page you linked" - there: understanding, and it was the next thing in the same sentence. Stupid English, not distinguishing between the general "you" and the specific "you". I'll fix the wording so it's more clear. The specific "you" (Ladislav) did great, but the general "you" (everyone else)...
The purpose of that page was to ask for suggestions for new functions. It quickly got filled up with a technical criticism of existing functions - off topic, but not bad if it's helpful. Then, 3 actual suggestions for new functions were added, one of which was added to R3 and R2 (QUOTE) and one of which would make a good library function (BUILD). I didn't have any more suggestions for new replacement functions (REWORD didn't pan out), especially since you already linked the one you worked on with me, but was hoping for more constructive participation from the rest of the community; that is what is missing from that page. And still am hoping for that. I have nothing but praise for your participation, Ladislav. Carl has said that in a blog post he wants to replace REPLACE with a native that does what REPLACE and REWORD does, but more efficiently. He hasn't made a proposal for the exact behavior though, so it can't go on the page yet. (About INLINE) "and still was neither accepted nor refused" - We are waiting for more suggestions. But personally, I don't like Peta's INLINE - I prefer BUILD. We don't want to change COMPOSE's default behavior with #[unset!] because it is done that way for a good reason: To return nothing - similar to returning [] when using COMPOSE without /only - and it works with /only too. The BUILD function you mentioned is a good supplement for COMPOSE but not a good replacement for it, because the current behavior of COMPOSE is intentional, useful and widely used already. |
|
(0002392)
Ladislav 8-Jun-2010 17:40 |
Aha, thanks for the explanation, I did not know the original purpose of the page. Nevertheless, a BUILD-like function is in a similar category.
BUILD versus INLINE - they are very similar (INLINE being simpler, but otherwise it looks quite sufficient for the purpose), the main difference being the /WITH refinement, which I see as comfortable. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 8-Jun-2010 17:40 | Ladislav | Comment : 0002392 | Added | - |
| 7-Jun-2010 21:33 | BrianH | Comment : 0002382 | Modified | - |
| 7-Jun-2010 21:32 | BrianH | Comment : 0002391 | Modified | - |
| 7-Jun-2010 21:27 | BrianH | Comment : 0002391 | Modified | - |
| 7-Jun-2010 21:19 | BrianH | Comment : 0002391 | Added | - |
| 7-Jun-2010 16:37 | Ladislav | Comment : 0002390 | Added | - |
| 1-Jun-2010 23:26 | BrianH | Code | Modified | - |
| 1-Jun-2010 23:22 | BrianH | Code | Modified | - |
| 1-Jun-2010 23:22 | BrianH | Severity | Modified | minor => not a bug |
| 1-Jun-2010 23:22 | BrianH | Status | Modified | submitted => dismissed |
| 1-Jun-2010 23:22 | BrianH | Comment : 0002382 | Added | - |
| 1-Jun-2010 14:25 | Steeve | Comment : 0002381 | Added | - |
| 31-May-2010 08:15 | Ladislav | Comment : 0002380 | Added | - |
| 31-May-2010 08:01 | Ladislav | Comment : 0002379 | Added | - |
| 28-May-2010 21:49 | meijeru | Ticket | Added | - |