OpenEuphoria

Re: Strings, again

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jun 06, 2004
• 409 views

Pete wrote:

<snip>

> HMMM...
> How can I hammer this home?
>
> POINT 1: A string type will make nothing possible that cannot be done
> using sequences. Nothing, and I mean nothing. Some fairly hideous
> syntax might be necessary to overcome the total failure to distinguish
> between currently ambiguous strings and sequences (eg {tStr,"ABC"} vs
> {tSeq,{65,66,67}}, but it CAN be done. (and if you never yet needed
> to, bully for you).

I agree. Using such a syntax will be awkward, but not a real problem
when only my own program is concerned.
But things look different, when a program written by me writes some data
to a file, and a program written by someone else reads the data.

Quoting "lib_e_g.htm#get" (Eu 2.4):
"get() can read arbitrarily complicated Euphoria objects. You could have
a long sequence of values in braces and separated by commas, e.g.
{23, {49, 57}, 0.5, -1, 99, 'A', "john"}."

"The combination of print() and get() can be used to save a Euphoria
object to disk and later read it back. This technique could be used to
implement a database as one or more large Euphoria sequences stored in
disk files."

Now let's see what happens when I use this technique to implement a
database:

include get.e
sequence data
integer fn

data = {23, {49, 57}, 0.5, -1, 99, 'A', "john"}

fn = open("test.dat", "w")
print(fn, data)
close(fn)

fn = open("test.dat", "r")
data = get(fn)
close(fn)

print(1, data)

As we already would have expected, the program prints
   {0, {23,{49,57},0.5,-1,99,65,{106,111,104,110}}}
on the screen.

The information that "john" is a string got lost here, by print()ing the
data to the file. Even when I change the output command, or change the
content of the file manually, so that "test.dat" actually contains
   {23,{49,57},0.5,-1,99,65,"john"}

the following program

include get.e
sequence data
integer fn

fn = open("test.dat", "r")
data = get(fn)
close(fn)
print(1, data)

also prints
   {0, {23,{49,57},0.5,-1,99,65,{106,111,104,110}}}
on the screen.

To make a long story short:
In order to make data exchange via print() and get() unambiguous, the
writing program must use a syntax like {tStr,"ABC"}, and the reading
program (possibly written by someone else), must use THE SAME SYNTAX,
too. In other words, some kind of standard will be required.

> POINT 2: Adding a string type will not stop sequences working.
> (Yes, it has got to the point where I feel the need to state that)
>
> POINT 3: A string type will make the interpreter slower.
>
> POINT 4: A string type will make programmers more productive,
> at least when tracking down bugs via trace() and/or examining ex.err
> that involve a fair bit of textual stuff. (and if you never yet went
> down that path, bully for you)
>
> POINT 5: It has nothing to do with the programmer knowing what a
> variable contains, but the infrastructure knowing it.

Thanks for pointing this out again.

> This discussion
> appears to have gone seriously off track regarding printing. That is
> not, and in my view never has been a problem when the programmer is
> writing code, but it certainly IS when the programmer is relying on
> already written code (from RDS) they CANNOT change - specifically the
> trace window and the ex.err file.

And it IS also a problem when exchanging data, as I tried to show above.
I, the programmer of the writing program, know that "john" is a string.
What I want is this: Just write the data to a file, send the file to
someone else, and then the recipient should be able to *simply* and
*reliably* retrieve the information, that I sent him.
What I not want is, to call her/him by phone and tell: "Hey, variable #1
is a sequence, variable #2 is ...".

> POINT 6: There *ARE* benefits to having strings, EVEN THEY DO NOT
> APPLY TO YOU. (And as pt 3, a downside too).
>
> POINT 7: Rob won't do this, so please stop rubbing salt in the open
> wound which is: I can't have my beloved string type!!!!!
>
> OK?

Yes, you wrote a well-balanced summary. Thanks.

> Pete
> PS If Rob's promised Eu in Eu, which is already promised to be far
> slower than the real deal, could handle strings (and be even slower),
> I still think that would be pretty cool!

In principle I also think so, but than it wouldn't be completely
compatible with the official version any more. 

Regards,
   Juergen