Redefining BINARY!

I've ready your feedback on my prior note about the use of INSERT for the BINARY datatype. Thanks for the quick feedback.

In order to make progress and resolve these issues as quickly as possible, we have to break down the problem into smaller chunks.

For example, these are fundamentally different binary actions (bin is a binary series):

insert bin "test"
insert bin 123

The first is a question of auto-encoding (converting) a string to be a binary value; should it be UTF-8 encoded and should LF's be converted to CRLFs.

The second is a question of semantics: are we asking for the byte value 123 or the integer string representation "123" to be inserted? (And then you could then add the above encoding question on top of that.)

In R2, we converted 123 to "123" then inserted that. Why? It came from this the desire to have:

port: open/string %file
insert port 123  ; here port is of string type

be very close to:

port: open/binary %file
insert port 123  ; here port is of binary type

We wanted them to be consistent. You can see why by the example.

However, in real life, there is no such thing as perfect consistency. There are always exceptions, even in the mathematics of computer languages and denotational semantics.

After all, what does it mean to do this?

insert bin image

Such a statement implies that a flat binary serialization of an image has meaning. In reality, it is of little use to us as written, because an IMAGE is a composite value, it includes more than just image data; we need to know at least the width of a line in pixels and size of a pixel, or we lose information in the above insert.

This is true of many other datatypes as well. What does it mean to have any specific datatype converted to or from binary? Examples? There are many:

to-binary "text"
to-binary 123
to-binary 12.3
to-binary #123
to-binary 1:23
to-binary 1-2-2003
to-binary image
to-binary object
to-binary charset "abc" ; a bitset

And, of course, you have the reverse conversions. I will not list them; they are pretty obvious.

In the past, we've had "the luxury" of ignoring a precise definition of BINARY.

We can no longer afford to do that. It must be precisely defined.

Yet, time is short. R3 must move along.

Possible conclusion?

My current inclination (working conclusion) is that perhaps we need to remove all to-binary conversions entirely, then bring them back one-at-a-time as we can properly define them. And, if we cannot define them, they will not exist.

In this way we will avoid creating a set of new incompatibilities with our future R3 implementations.

3 Comments