| Type | Wish | Status | submitted | Date | 8-Aug-2015 09:05 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Evaluation | Submitted by | fork |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Make non-"special" DO types error until special behaviors conceived |
|---|---|
| Description |
Consider: >> code: "print {Hello}" >> do code Hello >> code: <print {Hello}> >> do code <print {Hello}> While both are strings, one of them triggered an evaluation as code...while the other merely gave back its literal form. It is the first "special" behavior that is the reason for DO's existence. Having a mundane behavior which may become relied upon weakens the offerings for what the type might do in the future. For instance, TAG! might be used by DO to search some kind of common module library, as a level of indirection for a full URL. >> do <matrix> A PATH! might be used to request a version of that library, and in the NewPath! world it might look like this: >> do '<matrix>/1.0.5 But right now the default when DO doesn't know what to do with a type is to return the value as-is. There are other questionable behaviors for WORD!, GET-WORD!, LIT-WORD!, and LIT-PATH! for some reason. (DO'ing an error to activate it makes sense, given there's no other real way to throw an error, so that seems like an okay special behavior...though it might make more sense to make that the default behavior for THROW of an ERROR!, with THROW/ONLY used to have it be caught via catch.) While on the topic, I'll mention there have already been active challenges to the idea of whether DO should be allowed to work on a FUNCTION!. The reason this is challenged is because it makes DO a "special outlier" in terms of being effectively variable arity: >> foo: func [x] [print x] >> do :foo "Hello" Hello This could have been achieved equally well with `foo "Hello"`. The theoretical benefit would be that you have something which might be a block, a function, or a string but don't know which...and you want DO to handle it regardless. But that really only makes since for single arity functions then, because the others could not consume parameters. By that argument it could be kept for single arity functions but not others; although this again points to the weirdness of the other anti-invariants like "runs strings, returns tags as is". |
| Example code |
| Assigned to | n/a | Fixed in | - | Last Update | 8-Aug-2015 21:42 |
|---|
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 8-Aug-2015 21:42 | Fork | Description | Modified | - |
| 8-Aug-2015 09:05 | Fork | Ticket | Added | - |