| Type | Wish | Status | reviewed | Date | 11-Jun-2014 16:11 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Mezzanine | Submitted by | fork |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Make PROBE's passing through values turned off by a refinement |
|---|---|
| Description |
@kronwiz reported a confusing incident coming from usage of PROBE, due to its behavior of passing through its result. I've had similar experiences and wasted time scratching my head over seemingly nonsensical results. There are many failure modes, but consider something like: data: "aaa" rule-set: [some "a"] foo: [false true] bar: "temp" bar: insert foo parse data probe bar Then you get as output: "temp" == [false true] The surreal-seeming violations of temporality can be tough for the people who need to rely on PROBE the most. Namely: people who were already confused! The issue is that there are two applications of probe that have come into practice: when you expect to be in-between expressions, and when you expect to be in mid-expression. It's easy to slip up in the first case. Those who like PROBE's current default behavior might offer up that if you want a "safer" and "less flexible" primitive, you can use PRINT MOLD. But there is a problem with that beyond just being more typing... because PRINT and MOLD are used in non-debugging scenarios, they are harder to search for and strip out when you are done debugging. This could lead us down the road of wondering if there should be another short word that is PROBE-like that doesn't pass through its result. I think a significantly better idea is to control PROBE's behavior with a refinement. My bias would be that the refinement be used to turn *on* the pass-thru behavior, which would be disabled by default. Simply because of the benefits it would have for the casual new user, while those who are injecting probes in mid-expression are probably more experienced and would have little trouble understanding the need to switch the passthru on. Possible names: PROBE/PASS, PROBE/PIPED, PROBE/VALUE... PROBE/CHAIN? Maybe even PROBE/ONLY ("Only probe, don't suppress result??") I actually kind of like that one. To appease the experts who would find this to be more typing for the case they consider, I'd suggest changing the `??` primitive from its current quoted behavior to be a passthru probe. (See CC#2153). That's even more smart/hip. It's simply a lot more reasonable to ask experts to be *more expert* and *more brief* than to ask new users to not make mistakes or be confused. |
| Example code |
;; ;; test case #1 ;; data: "aaa" rule-set: [some "a"] foo: [false true] bar: "temp" bar: insert foo parse data probe bar ;-- current behavior "temp" == [false true] ;-- proposed behavior "temp" ** Script error: parse does not allow unset! for its rules argument ;; ;; test case #2 ;; ;-- current behavior >> x: reduce [1 + (probe 2 + 3) + 4] 5 == [10] ;-- proposed behavior >> x: reduce [1 + (probe/only 2 + 3) + 4] 5 == [10] >> x: reduce [1 + (probe 2 + 3) + 4] ** Script error: + does not allow unset! for its value2 argument ** Where: reduce ** Near: reduce [1 + (probe2 2 + 3) + 4] |
| Assigned to | n/a | Fixed in | - | Last Update | 22-Jun-2014 21:53 |
|---|
| Comments | |
|---|---|
|
(0004433)
rebolek 11-Jun-2014 19:06 |
PROBE's greatest feature is that it works like probe,you can put it anywhere without modifying your code and you get value printed. So you want to get rid of its greatest feature to gain...exactly what?
I'm not against your proposal for PROBE/ONLY, only it should work vice versa (only probe, don't pass the value). |
|
(0004434)
fork 12-Jun-2014 00:15 |
> So you want to get rid of its greatest feature to gain...exactly what?
(a) The reason the ticket is longer than one sentence is because it explains "exactly what" you gain, and "exactly why" it the bias direction is important. I don't see the reason to write it again. (b) I agree it's a useful function, and it's not being gotten rid of. PRINT MOLD which people have apparently been willing to live with despite its badness is exactly the same length as PROBE/ONLY. probe/only can be typed without any shift keys. Though as a debugging function, this falls sort of under the case of console behaviors. And with that, I say we're continuing to make the mistake of not making it truly streamlined to let each person easily configure their own session. Instead of ignoring the reasoned arguments for such things and fighting tooth and nail to preserve the status quo (usually because you don't want to type more)..why don't you put on a thinking hat and suggest something like that "??" take on PROBE/ONLY's behavior, instead of its current quoted-argument behavior? >> x: reduce [1 + (?? 2 + 3) + 4] 5 == [10] |
|
(0004435)
rebolek 12-Jun-2014 00:31 |
Problem with this example code:
data: "aaa" rule-set: [some "a"] foo: [false true] bar: insert foo parse data probe bar is not PROBE problem, it's problem of badly written code, where PARSE is missing an argument. It could be followed by every other function, APPEND for example, and it still will be badly written code. Should we change all functions to not return value to prevent this one error? I don't want to start any arguments, I'm just saying that when this proposal will be implemented, we gain nothing and lose very useful function. If you want to just display value, you're free to use PRINT MOLD or ??, there's no reason to change meaning of PROBE. |
|
(0004436)
fork 12-Jun-2014 00:36 |
>> Should we change all functions to not return value to prevent this one error?
No. I addressed why this is a special case: "The surreal-seeming violations of temporality can be tough for the people who need to rely on PROBE the most. Namely: people who were already confused!" >> If you want to just display value, you're free to use PRINT MOLD I also addressed why this is not acceptable: "because PRINT and MOLD are used in non-debugging scenarios, they are harder to search for and strip out when you are done debugging." >> or ?? I explained that it exists already, AND it passes through. Hence it is a suitable replacement for the existing behavior of PROBE, while not meeting the requirements I lay out here. >> there's no reason to change meaning of PROBE. Yes, there is, and I explained it. What is it about ?? that you don't like *better* than PROBE? It's shorter, it's supported (with a slightly different meaning) by legacy, you can use it in PARSE and it has the same "output-but-keep-the-chain-going" meaning there. |
|
(0004438)
fork 13-Jun-2014 16:10 |
Never mind.
Just let people use PROBE and suffer through problems with it. Any compromise adding a new name is worse than just leaving it as is, and dealing with the periodic confusions. I don't want another word for it--and that's all anyone will do--so forget I asked. |
|
(0004457)
BrianH 22-Jun-2014 01:50 |
Giving PROBE an /only option to suppress the value pass-through would be possible. Suppressing the pass-through by default would be unwise, not only for compatibility, but also because passing the value through is and would be the most common usage model.
I can see the value of having PROBE/only as a replacement for PRINT MOLD, because you could leave in the PROBE expressions in there and then override PROBE with a non-printing function in production mode. Undismissing, on the condition that value pass-through is the default behavior. |
|
(0004468)
fork 22-Jun-2014 21:53 |
As mentioned I abandoned this idea due to the strong resistance... I think the objections by @rebolek and others pointed to "why solve just *this case*" have a sort of merit if there is a framework for solving these problems in general. Hence the idea of suggesting "punctuation" as a more generalized debugging tool that people learn to use when they need it. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 22-Jun-2014 21:53 | Fork | Comment : 0004468 | Added | - |
| 22-Jun-2014 01:51 | BrianH | Comment : 0004457 | Modified | - |
| 22-Jun-2014 01:50 | BrianH | Status | Modified | dismissed => reviewed |
| 22-Jun-2014 01:50 | BrianH | Category | Modified | Unspecified => Mezzanine |
| 22-Jun-2014 01:50 | BrianH | Summary | Modified | Make PROBE's passing through values turned on/off by a refinement => Make PROBE's passing through values turned off by a refinement |
| 22-Jun-2014 01:50 | BrianH | Comment : 0004457 | Added | - |
| 13-Jun-2014 16:10 | Fork | Status | Modified | submitted => dismissed |
| 13-Jun-2014 16:10 | Fork | Comment : 0004438 | Added | - |
| 12-Jun-2014 03:29 | fork | Description | Modified | - |
| 12-Jun-2014 03:28 | fork | Description | Modified | - |
| 12-Jun-2014 02:21 | fork | Description | Modified | - |
| 12-Jun-2014 02:19 | fork | Description | Modified | - |
| 12-Jun-2014 02:18 | fork | Description | Modified | - |
| 12-Jun-2014 02:16 | fork | Description | Modified | - |
| 12-Jun-2014 01:13 | fork | Comment : 0004436 | Modified | - |
| 12-Jun-2014 01:07 | fork | Comment : 0004434 | Modified | - |
| 12-Jun-2014 00:37 | fork | Comment : 0004436 | Modified | - |
| 12-Jun-2014 00:36 | fork | Comment : 0004436 | Added | - |
| 12-Jun-2014 00:31 | rebolek | Comment : 0004435 | Added | - |
| 12-Jun-2014 00:27 | fork | Comment : 0004434 | Modified | - |
| 12-Jun-2014 00:27 | fork | Comment : 0004434 | Modified | - |
| 12-Jun-2014 00:25 | fork | Comment : 0004434 | Modified | - |
| 12-Jun-2014 00:15 | fork | Comment : 0004434 | Added | - |
| 12-Jun-2014 00:00 | fork | Code | Modified | - |
| 12-Jun-2014 00:00 | fork | Description | Modified | - |
| 11-Jun-2014 19:06 | rebolek | Comment : 0004433 | Added | - |
| 11-Jun-2014 16:11 | Fork | Ticket | Added | - |