(no subject)
- Posted by Derek Parnell <ddparnell at bigpond.com> Dec 23, 2004
- 988 views
Kondor Attila wrote: > > Greg Haberek <ghaberek at gmail.com> 2004.12.22. 14:56:42 -5h-kor =EDrta: > > > > > > seq={{52,49,53},"415"} > > > > > "415" <-- I'd like hier to see: {52,49,53} > > > "415" > > > > Unfortunately, {52,49,53} and "415" are the same internally (to the > > interpreter). You have to determine when a sequence is a string and > > when it is plain data. You'd have to do something like this: > > > > }}} <eucode> > > sequence a > >=20 > > a = {52,49,53} > >=20 > > print(1, a) -- outputs {52,49,53} > > printf(1, "%s", {a}) -- outputs "415" > >=20 > > </eucode> {{{ > > Thanks, but I know this. > > When I reed for example an edb, I do'nt know so that=20 > {52,49,53} is data sequence or string. It is not equal. > > I think it would be good, if were in euphoria string type (not user type!)= > . This is an age old problem, and is not restricted to Euphoria. Ultimately, all program data is stored as a sets of bits. The meaning of the bit-sets is determined by the programmer as it is never inherent in the data itself - its just ones and zeros. If you have a database field which is a sequence, AND you need to make sure that every program that ever reads that sequence knows how to interpret its bits, then you will also need to store the field's meta-data. Most database systems do this for you in a schema. The RDS database system is not quite that complex, and you must provide your own schema if you need one. Of course, that begs the question about how can an arbitary program understand the schema layout (meaning). The answer for that probably lies in the use of international standards that, if followed, allow this functionality. For example, there is a reasonble XML data description language developed that could be used to describe the schema and the database records too. So in short, it is meaningless to complain that Euphoria cannot distinguish between {65,66,67} and "ABC" because the meaning of these 96 bits is defined by the programmer each and every time they are used. In the definition of Euphoria, RDS has explictly decided to make data interpretation flexible, at the cost of making the programmer 'work' a bit harder. A lot of languages have the built-in tools for programmers to force a specific interpretation of bits, but in Euphoria you have to add this yourself (if its needed). That is just a statement of fact, and not a judgement, criticism or praise. So, if your data needs a consistent, specific, bit interpretation, you need to add this layer of information to your data. And yes, that is not always an easy task. -- Derek Parnell Melbourne, Australia