comp.lang.ada
 help / color / mirror / Atom feed
From: dewar@gnat.com (Robert Dewar)
Subject: Re: Extended modal types
Date: 25 May 2002 08:57:11 -0700
Date: 2002-05-25T15:57:11+00:00	[thread overview]
Message-ID: <5ee5b646.0205250757.60c9715a@posting.google.com> (raw)
In-Reply-To: 3CEDFF90.B94D7E32@yahoo.com

Anatoly Chernyshev <rhezusfactor@yahoo.com> wrote in message news:<3CEDFF90.B94D7E32@yahoo.com>...
> and one cannot use arbitrary modular
> range,
> for example, like -100..345.

I can't even guess what an arbitrary modular range might be. Modular
refers to the fact that integer values are
represented by their (positive) remainder value when
divided by the modulus in use. Thus modular types can
never have negative numbers. 

If you are talking about wrap around types, then sure
you can get the effect you want. For example, in the
above case, you can define a type that is

   type r is mod 446;

Now you represent numbers in the range -100 .. 345 using
this type, and for example if you say

   rr : r := -100;

then the actual value would be 346.

The only thing you might want is an output routine that
understands this convention (which in fact is very similar
to how twos complement works).

But this is all a guess, since the term extended modular
type is meaningless.


Also I must say it is plain bizarre to get excited about
the prospect of such a peculiar special purpose feature (to
me even allowing non-binary modulus values is a mistake.

Actually a bit of history as to how this mistake came to
pass is of interest:

The URG agreed to provide unsigned types using a modular
type approach with binary modulus values that corresponded
to natural word sizes of the machine (much as C does).

We agreed to extend it to arbitrary powers of 2, since
an AND instruction is cheap on all machines.

Someone proposed (Bryce Bardin perhaps, apologies if that
is a wrong memory) extending this to non-binary values. The
vote in the URG was N-1 *against* this extension on the
grounds that it was frivolous (you can always program this
if you need it).

The Ada 9X design team put in general modular types, and
I and a couple of other people complained that it was a
feature that could not be justified.

Tuck and Bob responded that they had a commitment to 
implement the URG recommendations, and claimed that the
URG had recommended this. As chair of the URG, I knew
just how wrong this was :-) 

Turned out they had used as gospel the rejected proposal
for general modular types, assuming that the URG had
accepted it.

By that time, the feature was out, and featuritis had
set in and enough people were in favor that it stayed in.
Since it was not that much of a pain to implement, it
was not worth fighting.

But I find it a bit of nonsense in the
language (especially the weird semantics of NOT. For
example:

with Text_IO; use Text_IO;
procedure q is
  type r is mod 446;
  x : r := 13;

begin
   Put_Line (r'Image (not x));
end;

prints 432, and I do not find anything reasonable or
intuitive about that result :-)

To me this is orthogonality in language design run amok!



  parent reply	other threads:[~2002-05-25 15:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-24  8:53 Extended modal types Anatoly Chernyshev
2002-05-24 11:38 ` Marc A. Criley
2002-05-25 15:57 ` Robert Dewar [this message]
2002-05-25 18:06   ` Frank J. Lhota
2002-05-25 18:40     ` Florian Weimer
2002-05-25 21:56       ` David C. Hoos, Sr.
2002-05-27  4:57       ` Robert I. Eachus
2002-05-27  5:52         ` Florian Weimer
2002-05-27 23:47           ` Robert I. Eachus
2002-05-29  1:16             ` Robert Dewar
2002-05-29  2:31   ` Robert A Duff
2002-05-29  9:19     ` Dmitry A. Kazakov
2002-05-29  9:54     ` Robert Dewar
2002-05-29 15:20 ` Anatoly Chernyshev
2002-05-29 23:36   ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox