| Type | Wish | Status | submitted | Date | 6-Sep-2013 19:39 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Mezzanine | Submitted by | onetom |
| Platform | All | Severity | minor | Priority | low |
| Summary | Remove 'FOUND? |
|---|---|
| Description |
As per discussed on SO chat it's not useful because FIND works well with logical operations anyway.
In case of PICK, just use TO LOGIC! @DocKimbel agreed too. It doesn't read well anyway |
| Example code |
| Assigned to | n/a | Fixed in | - | Last Update | 16-Sep-2013 20:05 |
|---|
| Comments | |
|---|---|
|
(0003953)
Ladislav 6-Sep-2013 19:42 |
This looks like a mistake to me:
- FIND does not work well with logical operations like AND, OR, XOR at all. - TO LOGIC! works differently than FOUND? (FOUND? 0 yields TRUE, while TO LOGIC! 0 yields FALSE). |
|
(0003954)
onetom 6-Sep-2013 20:08 |
>> all [find "asd" "Asd" true]
== true >> to logic! all [true find "asd" "Asd"] == true >> true and to logic! find "asd" "Asd" == true I don't know what kind of practical expression would lead to using FOUND? on an INTEGER!. Can you help us and give a non-contrived example, please? Nobody could give any reasonable example on SO chat... :( Probably we need a better name for this NOT NONE? functionality. |
|
(0003955)
onetom 6-Sep-2013 20:18 |
Or the other option is to properly reason for the need for this function in the documentation, in such a detail that anyone can understand it.
The example in the docs http://www.rebol.com/r3/docs/functions/found-q.html works just as well without FOUND? as with it: >> if found? find luke@rebol.com ".com" [print "found it"] found it >> if find luke@rebol.com ".com" [print "found it"] found it |
|
(0003956)
abolka 6-Sep-2013 20:29 |
Another important difference: `FOUND? false` yields TRUE, whereas `TO-LOGIC false` obviously yields FALSE. |
|
(0003957)
fork 6-Sep-2013 20:45 |
I'll echo @onetom's call for a case where this really matters. And if it matters so much, then isn't it better to write explicit code at the callsite? Can anyone honestly say FOUND? is the answer to the issue?
FOUND? is a dud, semantically. If there needs to be a SOMETHING? for the NOT NONE? macro case then... well, okay. But does it come up often enough? Think of the children. |
|
(0003958)
onetom 6-Sep-2013 21:12 |
Stating that NOT NONE? FALSE is false is obvious and doesn't justify having a shortcut function for NOT NONE?, neither does it explain why is it called FOUND?.
I never wrote FOUND? (this OR that). This function name suggests one should use it in conjunction with FIND, but in that case it doesn't seem to be needed. As the documentation say, the only problem is PICK, like >> PICK [yes no] FIND "asd" "qwe" ** Script error: invalid argument: none ** Where: PICK ** Near: PICK [yes no] FIND "asd" "qwe" >> PICK [yes no] FIND "asd" "asd" ** Script error: invalid argument: "asd" ** Where: PICK ** Near: PICK [yes no] FIND "asd" "asd" but then again >> PICK [yes no] TO LOGIC! FIND "asd" "qwe" == no >> PICK [yes no] TO LOGIC! FIND "asd" "asd" == yes I suspect it was invented just for this PICK use case, since we don't have the ternary operator. While FOUND? is clearer than NOT NONE?, TO LOGIC! is more telling (since it symmetric, because it doesn't emphasize the NONE case). The other case which I saw sometimes is IF NOT FOUND? FIND, but that's again equivalent to IF NOT FIND. As I noticed the FOUND? FIND became a reflex. Kinf of a "safety" idiom and it is just used more often in places where it's not needed then in places where it is "needed". Here is a crude measurement based on the script library, to support this claim: ---==| ~/Downloads/library/scripts |==--- $ grep -ri found? . | wc -l 310 $ grep -ri found? . | egrep 'if|either' | wc -l 191 $ grep -ri found? . | egrep 'pick' | wc -l 9 Those 110 = 310 - 191 - 9 cases are usually part of ALL or ANY blocks which are rarely used with PICK. But even if it wasn't the case, the worst case, real world NEEDED : NOT-NEEDED ratio is 119 : 191 ~= 1 : 2. |
|
(0003959)
abolka 6-Sep-2013 21:45 |
"Stating that NOT NONE? FALSE is false is obvious"
First and foremost, it's incorrect. "NOT NONE? FALSE" is TRUE. "This function name suggests one should use it in conjunction with FIND" To me, the function name suggests that it is useful in conjunction with results related to trying to find something, in an abstract sense. FIND is not the only such function. SELECT, PICK, and map! lookup are other functions that come to mind immediately. For cases such as SELECT, `if found? select ...` is _not_ equivalent to `if select ...`. (Note that this needs to be taken into account in the greps above, or otherwise invalidates the statistic.) |
|
(0003960)
onetom 6-Sep-2013 22:11 |
Sure, I meant TRUE, it was not the point, but the lack of realistic examples.
Regarding SELECTs: $ grep -ri found? . | egrep 'select' | wc -l 11 BUT only *2* of those are real SELECT cases. Please give real examples for typical SELECT and map! cases, so we can decide this matter and either drop FOUND? or adjust the documentation. |
|
(0003961)
Ladislav 7-Sep-2013 01:16 |
I remember having used FOUND? with ANY or ALL like this:
found? any [...] or found? all [...] however, I am not sure what exactly was the reason why I needed a logic! value. Most probably it was the fact that Rebol does not have conditional operators except for NOT, which happens to be conditional operator, in fact. |
|
(0003962)
BrianH 9-Sep-2013 07:36 |
FOUND? is like TRUE?, a function that was needed, which we had to come up with a name for, and that's the name it got. The main reason for both is to generate logic values based on certain circumstances, usually to be stored and used later rather than used immediately - we'd still need this value transformation even if we had conditional operators. It's not necessarily for use with AND or OR, it's for putting the results somewhere, or for not leaking references. Making these functions go away doesn't make the circumstances that led to their creation go away.
As with most mezzanines, it would be possible to do without it, but that is an argument for making it optional, not getting rid of it. As long as it's useful it doesn't hurt to make it available somehow. If you want further justification for their existence, it would be easy to implement FOUND? and TRUE? as natives. However, they are useful as they are now. If you want a moral justification for the existence of FOUND?, here's a simple one: FOUND? provides a built-in way to justify FIND not returning a logic value. It's a companion function for FIND, sort of a compositional replacement for a refinement for all functions of that type. FIND is only one of a whole class of functions that are used both conditionally and to provide information. Other such functions are SELECT and EXISTS?, though the increase in none-propagation in Rebol 3 makes such functions even more common. FOUND? (or the inlined NOT NONE?) is a transformation which all FIND-like functions end up needing eventually. For that matter, I would be willing to bet that the main reason people ever use NOT NONE? instead of FOUND? is the name. People use FOUND? when it adds clarity to their code (and they aren't offended by its existence, of course). Only hyper-optimizers would use NOT NONE? with FIND, for instance. But when it's in an expression where the word "found" doesn't make sense, they use NOT NONE? instead. This is not a problem. |
|
(0003963)
Ladislav 9-Sep-2013 09:44 |
#1879 is related, providing some reasons why we even need such helpers as TRUE?, ... As stated there, virtually nobody knows the differences between FOUND?, TO LOGIC!, TRUE? or between NOT and logic operators, which should alarm the language designer that something is wrong here |
|
(0003966)
BrianH 15-Sep-2013 05:27 |
Ladislav, TRUE? was initially implemented for generating logic values to be stored. Operators weren't the issue at all. It's tricky to mix infix and prefix syntax in Rebol (many parentheses required), and TRUE? is mezzanine so it's not an efficient operation either (yet), so at the time it just never occurred to us to use TRUE? with logical operators. For the most part it makes more sense to use ANY and ALL than to use TRUE? with AND and OR, just because of the mixed-fix issue. It would make more sense to use them with AND~, OR~ and XOR~, if those functions were used more often.
I agree about the language design issue though. It is worrying that there is a need for those 3 different operations, and that there would still be a need for them after conditional operators are implemented. Nonetheless, those really are 3 different operations. We could simplify things by dropping support for C-like zero-to-false conversion (the main difference between TO-LOGIC and TRUE?) or make null and false the same thing like some simplistic Lisp variants (the main difference between TRUE? and FOUND?), and that would reduce the number of needed operations. The problem with that is that those distinctions are useful, each in different situations. We drop the distinctions, we make the language less useful. That's the tradeoff. |
|
(0003967)
Ladislav 15-Sep-2013 09:43 |
"there would still be a need for them after conditional operators are implemented" - aha, thought-provoking! Would there be a need for them in such case? This might require a user poll asking people why are they using or needing them.
"We could simplify things by dropping support for C-like zero-to-false conversion (the main difference between TO-LOGIC and TRUE?)" - I (just one user, but it is a safe bet there will be others, user poll could tell, again) *never* used or needed zero-to-false in Rebol "or make null and false the same thing" - this does not look attractive to me due to the above, I rather find it worse than the present state |
|
(0003970)
BrianH 16-Sep-2013 19:43 |
Didn't say they were good ideas, just that they would be necessary to reduce the number of distinct operations.
I think that the zero-to-false conversion made a lot more sense in Rebol 2, with its thin library wrapper around C, which considers 0 and false to be equivalent. If we commit to never adding such a wrapper in Rebol 3, and always converting such conditions to logic values in our extensions, and not complaining about compatibility issues, then we could get rid of zero-to-false conversion and just use TO-LOGIC instead of TRUE?. Otherwise, it's still useful. However, if we decide to get rid of the zero-to-false conversion in TO-LOGIC, we can add it back as a separate function exported by whatever extension someone makes to recreate an R2-style library dialect. That would let us get rid of TRUE?. I don't suggest making null and false equivalent, that distinction is too useful (which is why most Lisp variants make the distinction). We'll still need the operation performed by FOUND?. However, we could make the function itself optionally included - included by default in the regular interpreter, not in minimal builds - and just use NOT NULL? when it's not included. Low-level mezzanine code shouldn't use it, just like it can't use the TO-type conversion wrappers, needing to use TO type instead. There's not much we can do about the mixed-fix expression thing though. Without having prefix-operators (like function calls, but higher precedence than infix-operators), it's still awkward to mix prefix and infix operations. That, more than the conditional situation, seems to be why some people use ANY or ALL rather than AND or OR. |
|
(0003971)
BrianH 16-Sep-2013 20:05 |
Made #2055 for the (TO LOGIC! 0) == TRUE proposal. This has nothing to do with FOUND?, it only relates to TRUE?. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 16-Sep-2013 20:05 | BrianH | Comment : 0003971 | Added | - |
| 16-Sep-2013 19:43 | BrianH | Comment : 0003970 | Added | - |
| 15-Sep-2013 09:58 | Ladislav | Comment : 0003967 | Modified | - |
| 15-Sep-2013 09:57 | Ladislav | Comment : 0003967 | Modified | - |
| 15-Sep-2013 09:50 | Ladislav | Comment : 0003967 | Modified | - |
| 15-Sep-2013 09:49 | Ladislav | Comment : 0003967 | Modified | - |
| 15-Sep-2013 09:43 | Ladislav | Comment : 0003967 | Added | - |
| 15-Sep-2013 05:27 | BrianH | Comment : 0003966 | Added | - |
| 9-Sep-2013 09:46 | Ladislav | Comment : 0003963 | Modified | - |
| 9-Sep-2013 09:44 | Ladislav | Comment : 0003963 | Added | - |
| 9-Sep-2013 07:36 | BrianH | Comment : 0003962 | Added | - |
| 7-Sep-2013 01:16 | Ladislav | Comment : 0003961 | Added | - |
| 6-Sep-2013 22:14 | onetom | Comment : 0003960 | Modified | - |
| 6-Sep-2013 22:11 | onetom | Comment : 0003960 | Added | - |
| 6-Sep-2013 22:06 | abolka | Comment : 0003959 | Modified | - |
| 6-Sep-2013 21:57 | abolka | Comment : 0003959 | Modified | - |
| 6-Sep-2013 21:45 | abolka | Comment : 0003959 | Modified | - |
| 6-Sep-2013 21:45 | abolka | Comment : 0003959 | Added | - |
| 6-Sep-2013 21:12 | onetom | Comment : 0003958 | Added | - |
| 6-Sep-2013 20:45 | fork | Comment : 0003957 | Added | - |
| 6-Sep-2013 20:29 | abolka | Comment : 0003956 | Added | - |
| 6-Sep-2013 20:18 | onetom | Comment : 0003955 | Added | - |
| 6-Sep-2013 20:09 | onetom | Comment : 0003954 | Modified | - |
| 6-Sep-2013 20:08 | onetom | Comment : 0003954 | Added | - |
| 6-Sep-2013 19:45 | Ladislav | Comment : 0003953 | Modified | - |
| 6-Sep-2013 19:42 | Ladislav | Comment : 0003953 | Added | - |
| 6-Sep-2013 19:39 | onetom | Ticket | Added | - |