| Type | Wish | Status | submitted | Date | 18-Sep-2013 02:24 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Native | Submitted by | fork |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Simplify TO BLOCK! and complex construct via MAKE BLOCK! |
|---|---|
| Description |
Help for MAKE currently reads as: === USAGE: MAKE type spec DESCRIPTION: Constructs or allocates the specified datatype. MAKE is an action value. ARGUMENTS: type -- The datatype or an example value (any-type!) spec -- Attributes or size of the new value (modified) (any-type!) === The help for TO currently reads very similarly: === USAGE: TO type spec DESCRIPTION: Converts to a specified datatype. TO is an action value. ARGUMENTS: type -- The datatype or example value (any-type!) spec -- The attributes of the new value (any-type!)</pre> === MAKE is an operation unique to Rebol, with few incoming expectations. So if a user is told that MAKE BLOCK! 10 has special behavior of preallocating memory for ten elements, but still returns an empty block... they will nod and say "okay". And if they are told that MAKE BLOCK! "ABC: DEF" will tokenize any string passed to Rebol symbols (in this case, [ABC: DEF]) they probably won't complain either. This is all part of learning what MAKE does. It's okay that there's not a simple rule. As learning object construction parameters in any other language, you go have to read a long function list and know what each does. That is life. Yet I would argue that TO is a different animal. The expectations of users coming from other languages of conversions via the likes of "to_s" is that they do understandable things. If you have TO BLOCK 10 yielding [10] and TO BLOCK! 12-Dec-2012 producing [12-Dec-2012], it will come as a shock to see TO BLOCK! "ABC: DEF" producing [ABC: DEF]. But that's what it does at the moment. I believe that while that is a good answer for MAKE of a block, it's puzzling for a user of TO. A simple and comfortable rule for all TO conversions targeting an ANY-BLOCK! type would be: "If the value being converted is an ANY-BLOCK!, then the result will be a copy of the input whose block subtype is the target type. Otherwise, the result will be the input value in a single element of the target block type." More generally, what TO does should be as simple as possible. Any complex behavior should be explicitly asked for, or provided through MAKE. @BrianH agrees that instead of the second argument of TO being a "spec", that it simply be labeled "value". This helps clarify that complex constructions are to be done with MAKE, and that TO doesn't have any extra parameterizations. We should also separate the script/bad-make-arg error into separate errors for MAKE and TO. |
| Example code |
;; ;; Current behavior examples ;; >> make block! "abc: def" == [abc: def] >> to block! "abc: def" == [abc: def] ;; ;; Desired behavior examples ;; >> make block! "abc: def" == [abc: def] >> to block! "abc: def" == ["abc: def"] |
| Assigned to | n/a | Fixed in | - | Last Update | 7-Oct-2013 22:05 |
|---|
| Comments | |
|---|---|
|
(0003986)
BrianH 18-Sep-2013 21:08 |
We'll need to put together a list of all of the changes we need made, grouped by target and source datatypes. Both the MAKE and TO actions will need changes. If other tickets relate to this we should make reference to them here, rather than copying their requests here.
So far: - Block type conversions using TO from non-blocks should wrap the value in a block of the type specified. No tokenization. MAKE should still do tokenization. - TO word types with decorations (all except word!) from strings that have the same decorations in them (like to set-word! "a:") should work as if there were no decorations in the string (like to set-word! "a"). If the string has incompatible decorations (like to get-word! "a:"), we can still trigger an error. If a string has no decorations in it, it should still work. See also #1915 and #1916 for a TO-BLOCK tokenization replacement (though you could still use MAKE). See #2055 for logic! conversions. Some datatypes, such as string, have other converters available that target them. The TO converter should be the simple, sensible default. Some other types, notably binary!, need more detailed converters to and from them, but that is not TO's job. We already went over the behavior of to binary! whatever and to whatever none, so we don't need to revisit them. |
|
(0004056)
maxim 7-Oct-2013 21:07 |
I agree that TO should be as simple as possible and when logical and possible, completely symmetric.
TO STRING! TO BLOCK! "foo bar" should always return the original string. |
|
(0004058)
Gregg 7-Oct-2013 22:05 |
I support this, and changing the name of the second param to 'value. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 7-Oct-2013 22:05 | Gregg | Comment : 0004058 | Added | - |
| 7-Oct-2013 21:07 | maxim | Comment : 0004056 | Added | - |
| 3-Oct-2013 02:19 | fork | Summary | Modified | Adjust TO and MAKE behavior to more clearly delineate construction and conversion => Simplify TO BLOCK! and complex construct via MAKE BLOCK! |
| 3-Oct-2013 02:19 | fork | Description | Modified | - |
| 3-Oct-2013 02:19 | fork | Code | Modified | - |
| 18-Sep-2013 23:26 | BrianH | Description | Modified | - |
| 18-Sep-2013 21:08 | BrianH | Comment : 0003986 | Added | - |
| 18-Sep-2013 03:18 | Fork | Description | Modified | - |
| 18-Sep-2013 03:18 | Fork | Code | Modified | - |
| 18-Sep-2013 02:29 | Fork | Code | Modified | - |
| 18-Sep-2013 02:27 | Fork | Description | Modified | - |
| 18-Sep-2013 02:27 | Fork | Description | Modified | - |
| 18-Sep-2013 02:24 | Fork | Ticket | Added | - |