Re: ADA Popularity Discussion Request

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 14 Sep 2004 15:57:21 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>  
>:> (No matter in what language.) If all of them are
>:> isolated in some module(s), where's the problem.
>: 
>: The problem is a geometric explosion of interfaces in cases like:
>: 
>: procedure Connect
>: (DB : in out Data_Base; Server, Name, Password : String);
> 
> This is very much a procedure doing I/O. You cannot expect this to
> work at an abstract level without hiding the outside world, can
> you? And on the other hand, you have to serve the outside world
> what it is expecting. If you use String values for the network
> database connection credentials, what will be the interpretation
> of of a Character value with 'pos > 127?  UTF-8? ISO-8859-1? Are
> you connecting to DB2 on a mainframe?

Constraint_Error, if the data base cannot UNICODE. It is no different from:

procedure Foo (X : Positive);
...
Foo (-1);

Positive is a subtype of Integer. Integer is a "subtype" of
Universal_Integer. Conversion from the base to its subtype may raise
Constraint_Error. Wide_Character and Character are related in exactly same
manner as Integer and Positive.

> To what extent is switching back and forth between Standard.String
> and (Un)Bounded strings a problem? Where does it happen? Locally?
> At I/O boundaries? If you store strings in one internal representation
> in your program how many parameter profile variants will there be?

Look at Ada.Strings it is an example of how it explodes. Now consider, that
some day Ada will have a comprehensive library for building GUIs, text
processing, interfacing data bases etc. Should this library use: String,
Unbounded_String, Wide_String ...? Should it be generic, parametrized by a
string type. Which is BTW impossible too, because even at the level of
generics the least common ancestor of all Ada string types is "type Duno is
private"; So you have to specify all methods you might need in the library
a formal parameters!

> Would you also want a polymorhpic number type with automagic
> conversion?

It *IS* polymorphic. All numeric literals are overloaded [=statically
polymorphic.] But you probably meant other thing, which I will answer.

It seems that you are mixing types and subtypes. [IMO Ada's syntax of
extensible [tagged] types is quite misleading in that respect. They are in
fact subtypes, not distinct types.]

Different predefined string types should be subtypes, not unrelated types.
It is exactly the same case as Integer, Positive and Natural. That by no
means prevents us from creating distinct string types when we need it.
Compare:

type My_Int is new Integer; -- This a new type
X : My_Int  := Positive'(1); -- This an error!
Y : Integer := Positive'(1); -- This is OK!

Strings should work in exactly same way:

type My_String is new Unbounded_String; -- This a new type
X : My_String := String'("A"); -- This is illegal
Y : Unbounded_String := String'("A"); -- This should be legal

>: For the user point of view, what is the difference between String and
>: Unbounded_String to require explicit conversions between them? Isn't it an
>: implementation detail?
> 
> The difference is the same as the difference between an array
> of fixed size and a list. I guess that humans are more accustomed
> to character lists than to something_else lists. Have you recently
> read any complaints about fixed size arrays of something_else in
> Ada?

But all that is irrelevant for a user. What is important to him is the
interface: I can get an element by index, I can get a slice, I can
concatenate etc. How the compiler/library does the trick is interesting
only out of curiosity or when the performance is a big issue. 

>:> Is it an
>:> aesthetical problem to have to use Ada's verbosity with strings?
>: 
>: With strings it becomes compelling. The problem is fundamental, Ada's
>: support of interface implementation is very rudimental. You cannot define
>: the interface of abstract characters and then the interface of an abstract
>: array of abstract characters.
> 
> Where would these abstract interfaces be useful?

For developing class-wide/generic libraries.

> Do you want to code convenient string conversion automagic to overcome
> notions of what an array of characters is, in Ada? :-)

Yes. It is a way to have it. Type conversions A->B applied automatically,
promote B as subtype of A. I do not propose to do it in that chaotic PL/1
or limited C++ way. It should be Ada's way.

>: And what will we do when Wide_Wide_String come?
> 
> Use it. When string memory and 32 bit instructions instead of
> 8 bit instructions is no concern, use it everywhere. :-)

I do not want rain forests to disappear because of a need to print a dozen
copies of ARM 2050! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de