OpenEuphoria

Re: String?

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

Pete wrote:

> On Mon, 31 May 2004 09:33:25 -0700, Rolf Schroeder
> <guest at RapidEuphoria.com> wrote:
>
>> Excuse me, but now I think YOU are missing the point: the decision, if you
>> want to print it as an ASCII string or if you want to print simply the
>> numbers, the decision comes by selection the 'tool' YOU select: format {%s}
>> in printf() gives you the text, and i.e. format {%d,%d,%d,%d} in printf
>> would give you the plain numbers.

I know, Rolf. That's exactly what I (and other people, too) don't like.
Mainly because in some situations, we don't have the possibility to
select anything: this applies to trace() and to output to the "ex.err"
file.

Also, RDS claims that Euphoria is simpler than BASIC. While this might
be true in general, in BASIC we can do this:
   dim s as string, i as integer
   s = "My age is"
   i = 99
   print s i
That's what I call simple.

In Euphoria, it's currently not possible to have a generic output
routine such as 'print' in BASIC, because sometimes only the programmer
(and not the program) knows, what a given sequence means. Although I
like Euphoria's pretty_print(), and Pete's version IMHO does even
smarter guessing, any output routine sometimes can't do anything else
than *guess*, what it should do. This is not satisfactory, IMHO.


> Hi Rolf,
>
> OK, I agree that in more than 90% of print cases, the programmer can
> easily apply the correct format info, however:
>
> Slightly restating the previous example:
>
> sequence weights
> 	weights={74,111,104,110}
> sequence name
> 	name="John"
>
> There is additional meaning obvious to anyone reading the source,
> which is lost in the assignment. Since equal(weights,name) will return
> true, any attempt at an "IsString" function is doomed to get one of
> them wrong.

Yes, and using a user-defined string type does *not* solve the problem.

> Sure you can do something like:
>
> constant tInt=1, tFlt=2, tSeq=3, tStr=4
>
> 	weights={tSeq,{74,111,104,110}}
> 	name={tStr,"John"}
>
> Which I think is about the easiest way to preserve the semantic
> information. Not exactly nice though, is it?

No, not too nice. And it also doesn't make the output of trace() and the
output to "ex.err" better readable.
But something like that is what I would Euphoria like to do *internally*
(if the cost is not too big).

> There may not be a whole lot a string type will allow that you cannot
> possibly do without. But to imply it has no merit is silly.
>
> Adding strings might more than double the program size and probably
> make everything 50% slower, so I could accept an argument against it
> on technical grounds.

Mee too.

> But being able to read values in the trace window, ex.err, and output
> from ?weights and ?name, is an overwhelming argument in favour.
>
> Of course you may actually be the second person on the planet that
> actually likes to see name (and weights) in the trace window appear as
> {74J,111o,104h,110n} ?
>
> That definitely falls into the class of Necessary Evil, not the realm
> of Good Ideas.

Regards,
   Juergen