Re: C vs. Ada - strings

[Robert A Duff <bobduff@world.std.com>]

dale <dale@cs.rmit.edu.au> writes:

> Pete wrote:
> if you write
> > Positive'Image("5"). You get back
> > " 5", with a space for an optional - sign, even though it is a positive
> > number! or even worse,
> 
> (should read Positive'Imge (5))
> i've always thought of attributes such as these as rather low level
> features good for debugging, but not really of much use for fancy
> formatting. Still it can be annoying. You have to apply the trim
> function, or slice the array yourself, which is annoying.

The annoying extra blank is certainly a mistake.  So is the verbose
syntax.  Why can't you say X'Image instead of Integer'Image(X)?
After all, you can say "X + 1" (as opposed to something like
Integer'Add(X, 1)).  It's not necessary or helpful to mention the type
every time you want to do something to an object or value.

> instantiate a generic package to handle printing 
> > of
> > numbers, instead of
> > System.out.println("This is junk " + i); (where i is a numeric type).
> 
> Yes, but with this simplicity you get a very real problem - the
> inability to define new distinct numeric types.

I don't agree.  It's quite easy to design a language in which it is
possible to define convenient output procedures, and still have multiple
user-defined integer types.  And I don't mean by making all the output
primitives built-in, either (as in Pascal) -- I/O should be done in
library packages, not as built-in primitives.

>... Which do you think
> is the bigger problem - having to choose b/w int and long for almost
> all integer work (without the ability to have unsigned ints), 
> or having to instantiate (or do a type conversion) to get output?

The former.  But I think it's possible to get the best of both worlds,
so I think it's a legitimate complaint to say that Text_IO is a pain in
the neck compared to Java's primitives.  On the other hand, Java has its
own problems with strings.  Eg, the fact that the equality comparison is
pointer comparison.  And "+" is a poor choice for the concatenation
operator.

> Note that you could always include your own package of functions
> to get exactly the same behaviour as you see above in Java.

I don't see how.  Not if you have lots of user-defined integer types --
you have to declare something extra for every integer type, which does
not match the convenience of the Java routines.

- Bob