Re: Practicalities of Ada for app development

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

On Tue, 12 Jun 2012 11:48:43 +0200, Georg Bauhaus wrote:

> On 12.06.12 09:55, Dmitry A. Kazakov wrote:
>> On Mon, 11 Jun 2012 22:50:33 +0200, Georg Bauhaus wrote:
>>
>>> Reason: numeric literals typically mean a number of some "arithmetic"
>>> type.
>>
>> No, a numeric literal means what it tells "a number."
> 
> "A number" tells little to an average reader of a program
> seeing just that number.

Sorry for the reader, but numeric literal is just that: a number.

>>>     Some_Time_Object :=  45 * Seconds;
> 
>> Technically Barnes is not quite right.
> 
> Oh, I believe he is right and makes sure this is understood:
> 
> "the expression uses the rule that a fixed[!] point value
> can be multiplied by an integer giving a result of the same fixed
> point type". (�18.3, p.465)
>
> Using whole quantities of Seconds, Minutes, and so on will give
> us aggregates and formulas that do not invite confusion by
> stipulating that the fraction can be anything but 0.

It is very difficult if possible to create dimensioned fixed-point system
due to problems of handling accuracy. Note that the point of using fixed
point is to keep results exact.

>> 2. You cannot multiply time, you do durations (time intervals);
> 
> Like in "two times"? "Time after Time"? "Many times"?

The thing represented by Ada.Calendar.Time or Ada.Real_Time.Time has no
dimension. You can multiply durations by themselves and by other
dimensioned values and scalars. Times can be subtracted. Duration can be
added to time.
 
>> 3. "s" or "second" is the proper name of the unit.
> 
> "Seconds" is the plural of a "second" (one unit of time).

http://physics.nist.gov/cuu/Units/units.html
 
> "s" is asking for trouble, since "s" may well name a parameter
> or variable, like when copied from a formula (s = v * t, say).
> 
> By comparison, is "m" the name of Meter or of Minute?

"m" is meter. Minute is not a SI unit. Yes, there are many conflicting
names when irregular or units outside SI are involved.

As for conflicts with names of variables, that is not a problem in Ada.

>> in a properly typed languages you need no special
>> forms of literals. I guess that U+n stems from C-ish nL, nU etc.
> 
> Uhm, no! U+number is official U-nicode notation. (Also in ISO 10646.)

Yes, but C is where the ears are growing from.

If you want to follow the notation, you should to do it exactly, i.e.
U+0C20, without dashes around the number. If you don't, then use the most
appropriate way from the implementation language perspective. The middle
way would bring nothing but confusion.

>> You can overload numeric literals in almost any context in Ada.
> 
> Overloading literals is the questionable part. It is what got me
> started. No inference, please! Even when compilers can decide
> whether or not there is that single assignable type!
> 
> What I consider silly is to insist that readers infer
> the proper meaning of a sequence of digits when we can
> do better.

Sorry, but the program as a whole is not what it means. You have to
interpret the program in order to understand its semantics. A good language
design is to support trivial inference and require complex things explicit. 

Type annotation of operands of an expression *is* trivial, or else the
program is poorly designed.

>> The proper way to do this is:
>>
>>     UTF8_Pi : constant String := Image (16#0C30#);
> 
> How is that different from
> 
>        UTF8_Pi : constant String := U+16#0C30;

Compare:

   Image (16#0C30#) * 3

and

   U+16#0C30# * 3

Anyway, if U+n notation support seem the only problem with Ada UTF-8, I
gather that the issue is closed. (:-))

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