REBOL3 tracker
  0.9.12 beta
Ticket #0002159 User: anonymous

Project:

Previous Next
rss
TypeWish Statusreviewed Date25-Jun-2014 08:24
Versionr3 master CategoryNative Submitted byrebolek
PlatformAll Severityminor Prioritynormal

Summary MOLD and SAVE default mode should preserve none! and other values.
Description When using MOLD and SAVE, NONE is not preserved and is loaded back as word! instead of none! value. Many years ago, in 2.5.1, /ALL refinement was introduced to preserve this and other values. It makes sense that in R3 this should be default behaviour as the conversion to word! doesn't make any sense (besides NONE is more readable than #[NONE], but if you want readable interpretation, use FORM instead).

Others have pointed that /ALL also preserves index in blocks and according to them, this is not desired behaviour, so the proposal is that only the datatype degradation should be prevented in the default mode and the rest should be left to /ALL refinement.
Example code
Before:

>> mold none
== "none"

After:

>> mold none
== "#[none]"

Assigned ton/a Fixed in- Last Update28-Aug-2014 16:35


Comments
(0004478)
oldes
25-Jun-2014 09:08

Are you aware that mold/all is affecting also other datatypes?

>> mold/all next "abc"
== {#[string! "abc" 2]}
(0004479)
rebolek
25-Jun-2014 09:15

Yes, I'm aware of that. It makes sense to me that MOLD and SAVE should return most precise representation of values that is possible. If you want human readable string, use FORM.
(0004480)
BrianH
28-Jun-2014 02:04

There are two main problems with this proposal, and they have to do with MOLD's primary use in code-generation.

The first problem is that the object!, function! and closure! types usually can't be reconstructed from the MOLD/all construction syntax. In particular, the bindings aren't restored without going through the definitional-scoping process that the normal MOLD results would go through if you passed it to DO (more or less). This would make the main purpose of MOLD without /all pretty much useless.

The second problem is that most of the time you use MOLD for code generation, you don't want to see offset references. In general, when you have offset references at all during code generation, this is because you don't want to see the stuff earlier on. This is not as big a problem as the first though, it would just require code changes to match the new model: more intermediate copies, but in return you get more power in the generated code.

There was another suggestion (don't remember if it has a ticket) to make the default MOLD use /all syntax or a subset of it when there would be ambiguity or load issues in the result. The advantage to this over the above proposal is that you would be able to continue to use MOLD for code generation, but it would be more useful. It would just be a matter of putting together a list of all of the cases where the resulting value would be ambiguous (like the none case above, or even offset references if you prefer), then make sure to generate MOLD/all syntax in just those cases. In unambiguous cases, or cases like objects or functions where binding info would be lost, we would generate the existing syntax.

If there is no ticket for that other suggestion, I would recommend that this one be changed to that. Otherwise it should be dismissed.
(0004482)
rebolek
28-Jun-2014 07:28

I was looking for the other ticket and found none, so I changed the description, because current behaviour is useless and at least something should be done about it and that something is not dismissing.
(0004483)
BrianH
28-Jun-2014 19:34

Cases that need /all syntax, off the top of my head:
- Values of these types: datatype!, logic!, none!, unset!, typeset!
- Paths that contain dates, blocks, strings, binaries, paths, the special-case-syntax slash words like /, set-words, refinements, or anything with no literal syntax except construction syntax (like the above types)
- Paths with anything other than a word! value in the first position
- Paths of length less than 2
- Paths that contain a sequence of 3 numbers (conflict with date)
- Paths that have a sequence of an integer, a word with the same name as a month, and another integer (conflict with date)
- Words of a sequence of characters that don't match word syntax
- Ditto for tags
- Ditto for urls

We might want to not worry about the path sequence date-conflict cases, due to them being hard to detect efficiently, even in the case where the sequences aren't there. It could just be one of the remaining gotchas, a tradeoff we chose not to make.

We should consider whether we do offset series references, or maps. In both cases if they contain object or function values, those objects or functions would not really be usable once they're reloaded. However, in the case of maps the values wouldn't have been usable anyways, so we might consider it a good tradeoff for maps at least due to the value that literal maps could have. For offset series, it's more debatable (so let's have that debate).

You might note that some of these types aren't supported by construction syntax, notably words. We will need to make sure that they are supported by construction syntax.
(0004499)
Ladislav
28-Aug-2014 16:35

BrianH, you wrote: "Words of a sequence of characters that don't match word syntax" - that is a problem, since such words "do not exist" in R3, as demonstrated by:

to word! "1a"
** Syntax error: invalid character in: "1a"
** Where: to
** Near: to word! "1a"

Date User Field Action Change
28-Aug-2014 16:35 Ladislav Comment : 0004499 Added -
28-Jun-2014 19:51 BrianH Comment : 0004483 Modified -
28-Jun-2014 19:44 BrianH Comment : 0004483 Modified -
28-Jun-2014 19:38 BrianH Comment : 0004483 Modified -
28-Jun-2014 19:34 BrianH Comment : 0004483 Added -
28-Jun-2014 07:28 rebolek Comment : 0004482 Added -
28-Jun-2014 07:25 rebolek Summary Modified Make MOLD/ALL and SAVE/ALL default mode. => MOLD and SAVE default mode should preserve none! and other values.
28-Jun-2014 07:25 rebolek Description Modified -
28-Jun-2014 02:04 BrianH Description Modified -
28-Jun-2014 02:04 BrianH Code Modified -
28-Jun-2014 02:04 BrianH Status Modified submitted => reviewed
28-Jun-2014 02:04 BrianH Comment : 0004480 Added -
25-Jun-2014 09:15 rebolek Comment : 0004479 Added -
25-Jun-2014 09:08 Oldes Comment : 0004478 Added -
25-Jun-2014 08:24 rebolek Ticket Added -