Re: Type bug with "08" and "09"
- Steve Hall <digitect@...> wrote:
> The problem began because Vim is a text editor and all "data" within aVim being a text editor, anything within a file being edited is text data
> text file is a string. In the thread starter (5 months ago!) I had a
> series of 24 hour times (0658, 0749, 0844, 1022) to test against a 10
> minute interval. The simplest solution is to prepare the test by
> multiplying the first two digits by 60 and adding the last two.
> So is "0844" in this context a string or integer? As it turns out,
> both, since as a string the leading 0 is required by convention, and
> because those numbers represent integer values.
> I would agree that as a value in a piece of code, "08" is not natural
> except to mean octal. But when the line between data and code is more
> blurred, a la Vim, it's not so clear. I suppose this discussion could
> be made an example for those who promote strongly typed languages and
> who fight non-binary data formats, but I'd rather have to solve this
> bug with a simple leading-0-string-stripping function than to have to
> strongly-type everything and use a data conduit.
> Steve Hall [ digitect@... ]
(similar to string). In some circumstances (such as pressing Ctrl-A or
Ctrl-X in Normal mode) some part of that text can also be regarded as
numeric data, but what is numeric and under which radix will depend on
option settings -- 'nrformats' in the example given. If 'nrformats' includes
neither "alpha" nor "octal", then 08 (preceded and followed by non-numeric
data such as whgitespace) is regarded in that context as a valid decimal
number with the value eight: press Ctrl-X on it (or to its left) and you get
A file being sourced, OTOH, is code rather than text and its contents will
be interpreted according to the syntax for Ex commands. In that context,
depending on its position in the code stream, 020 might be the number
sixteen or the number twenty; and 08 (in a position where 020 would mean
sixteen) is not a number but in some contexts (e.g. as argument to the
":echo" command) it might be two numbers.
In the context described by Steve above, 0844 is of course (as all data) a
string; it is also a number, but in a format not explicitly known to Vim. It
is not an octal number, nor is it the decimal number "eight hundred
forty-four". Rather, it is a "time number" with an implicit sexagesimal
point, in a format which allows values from 0000 (zero, or midnight) to 2359
(twenty-three hours fifty-nine minutes). For some operations (such as all
comparisons, i.e. == != < <= > >=) using the string format with no
conversion is OK. Since 10 minutes is an integral divisor of 1 hour, the
indicated problem can also be solved with no conversion. OTOH, some other
operations (such as finding the remainder of the division by 24 minutes)
require, as a preliminary step, the indicated conversion (take the decimal
number formed by the first 2 digits, multiply by 60, then add the decimal
number formed by the last 2 digits).
Typing, in this case, depends on meta-textual information not explicitly
present in the text, but rather implicitly part of what the text is expected
to be. In the old-fashioned programming language on which I cut my milk
teeth, the meta-textual information for the part of the data record (i.e.
text line) containing that "time number" might, for instance, be coded as
follows in the program(s) handling that data (let's hope the mail clients
don't "beautify" it too much):
07 HOURS PICTURE 99.
88 HOURS-OK VALUE 00 THRU 23.
07 MINUTES PICTURE 99.
88 MINUTES-OK VALUE 00 THRU 59.
In a different language, that same meta-textual information would be coded
in a different but equivalent manner consistent with the syntax of the
language. In C, for instance; a structure could be used; in vim script it
would be implicit in the functions and commands written to handle that piece