[Coco] new problem with unpack

[Aaron Wolfe]

I'd guess either their example of using a string was either written at a
point where string support was not built in to the language, or its just a
bad example.

Strings are now considered primitives in B09, so they don't qualify as
complex data types.  This is for good reason, because there are many string
functions built in that do not/can not work on arbitrary arrays or complex
data types.  These functions only work on strings (an array of bytes
terminated by 0 or being the entire allocated length).  Strings, like other
primitives, imply a great deal of information to the interpreter simply by
bring declared to be strings.

Basically, just don't read anything into their example that isn't
specifically stated, and the documentation matches perfectly with the
actual b09 behavior.

Note that you can use a String as an array of bytes quite easily in b09 via
other methods, if that is what you wanted to do (and you don't even need to
copy the data).  You can also turn an array of bytes into a string although
that direction is a bit more work.
On Nov 5, 2013 5:12 PM, "Wayne Campbell" <asa.rand at gmail.com> wrote:

> Steven: There is no type CHAR in Basic09, only STRING (for ascii
> characters). You both overlooked the most important part of the wording
> from the manuals, the example they site last:
>
> For example, you can copy a string variable of 80 characters into a
> one-dimensional array of 80 bytes.
>
> That is array(80):BYTE and arrayStr:STRING[80] I merely shortened it to 10
> characters. It should work the way I entered the statements. The lack of a
> clear example of use only clouds the issue more, as it is now anybody's
> guess as to what the author(s) intended.
>
> Aaron: I should have picked better data. I didn't think about the fact that
> the numbers are not the same as the values. I am looking at your example
> that you say does work, and I see you made the STRING a 1-element array. I
> hadn't thought of that. The wording in the manual suggests to me that I can
> copy any complex structure to any other complex structure. While STRING is
> counted as a atomic type, it inherently is not, as it has to be treated as
> a character array internally. And it should even be capable of handling
> non-printable characters as well as printable characters.
>
> I wonder what happened, and how this feature turns out to be so radically
> different from what I expected. If I take that last statement literally, I
> can copy the contents of a 80 character string to a 80-byte array using the
> assignment operator alone. That is array:=arrayStr, and if it can go that
> way, it should be able to go the other way too: arrayStr:=array.
>
> Maybe I'll never know, but it sure does bug me. Yet another Basic09 Level 3
> feature fix. ;)
>
> Wayne
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>