Re: Implementing an elegant range type.

["Chad R. Meiners" <crmeiners@hotmail.com>]

"Mark Lundquist" <mark@rational.com> wrote in message
news:7nst6.593482$U46.17851651@news1.sttls1.wa.home.com...
>
> Chad R. Meiners <crmeiners@hotmail.com> wrote in message
> news:3ab6442f.0@silver.truman.edu...
> > There are certain times that I have wanted to pass ranges as a
> > parameter to subroutines, for example being able to
> > write, "Register_Slots (75..4242);" which of course isn't directly
> > allowed.  The solution I came up with is to declare a null type that
> > doesn't take up any memory so that I can create array type of the
> > ranges I want as in the example below.
> >
> > type Nothing is null record;
> > for  Nothing'Size use 0;
> >
> > type Integer_Range_Type is array (Integer range <>) of Nothing;
> >
> > Thus I could declare an array, "Integer_Range : Integer_Range_Type
> > (Integer);", and use it to pass array slice which would contain the
> > range data.  Example: "Register_Slots (Integer_Range(75..4242));"
>
> OK... how does this relate to your subject line, "Implementing an
_elegant_
> range type"? (emphasis mine) :-) :-) :-)

Well I am searching for the best solution for Implementing an elegant
range type.  The example I gave is a candidate I am evaluating.

> Looks like you blew past the last "Warning: Entering Kludge Zone" sign a
few
> miles back! :-)  Aren't you going to extreme lengths just to implement an
> "ordered pair" abstraction in a non-idiomatic way?  And why... to be able
to
> use the ".." notation?  It doesn't seem worth the contortions to me!
Maybe
> I'm missing something... if so, please clarify!

I don't it is fair to say that I blew past any warning signs.

Ranges in Ada are not types but they have operators such as "in" so they are
sort of a psuedo-type.  It occured that since ranges are a part of every
array,
passing a array of null elements is logically equivalent to passing a range.
I am conducting a controlled experiment in using null arrays to represent
ranges
in a more tangible form.


> Why not just write:
>
>     type Integer_Range is record
>         First, Last : Integer;
>     end record;
>
> Then you'd be able to say (taking up your example):
>
>     Register_Slots (Integer_Range'(75, 4242));
>
> or
>
>     Register_Slots ((First => 75, Last => 4242));
>
> You can quite easily write
>
>     function Length (Of : Integer_Range);
>
> (or call it "Extent" or whatever) to give the effect of 'Length as you
might
> have used it with the Integer_Range_Type kludge.

Of course that is the standard solution of making an ADT range type which
is entirely independent of Ada's ranges.  I have always found this solution
unsatifying since it is adds too much complexity to the code that makes use
of
it.  For example, the operator I want to use is "in" and not "Length".  I
want to be
able to write "If x in Switches_To_Be_Reserved'Range then ..." as opposed to
"If In(X,Switches_To_Be_Reserved) then ..." since the first seems to be the
more
consistant and readable approach.  With my approach all a programmer needs
to do is
declare an array type of "Nothing", and he/she gets the semantics and
operations
of the language automatically.

> Your Integer_Range_Type solution is kind of clever, but it's not readily
> understandable... if I had to deal with some code written with this style
of
> representing ranges, it would take me a while (even with comments) to
figure
> out what in the world the Maximum Array Of Nothings is for and why we are
> passing around slices of it.  And when I did figure it out, I would be
> annoyed :-)

I like this comment because it shows me why you perceive the solution as a
kludge :)

I freely admit that this solution is unusual.  That is why I haven't use it
in any real program.  Instead I am carefully examining its potentional as a
useful and elegant solution to a problem domain (What to do if you need to
pass (or return) a range of some type from a subroutine).

From your above arguement, I gather that your criticism is rooted with the
fact that the solution is unusual.  The problem with unusual solutions is
that
they often violate the limitations people place on the language.  One such
violation is the usage of an array to be a psuedo-function that returns a
requested range.  The other violation is that the elements of the array are
completely unimportant.

Perhaps we as a community should use this solution to as ourselves why we
place these limitations on a language as rich as Ada.  Is it simply baggage
brought over from previous experiences with other language?  If not why
should
these limitation be absolute?  It appears to me that this solution reduces
complexity by using semantics given by the langauge as oppose to having to
define
them independently.  The only problem is that is unusual which can be solved
by
making it publicly know and understood.

> OK, so much for my $.04 (adjusted for inflation :-) worth of unsolicited
> advice :-)

Thank you for volunteering your opinion.  It was my hope that I would
get some useful information and opinions to my question.

> >
> > The problem I am encountering is that when I declare a variable
> > with a range as large as Integer_Range's I get a
> > Storage_Error which doesn't make much sense since if Integer_Range's
> > range is something smaller than 2**20 elements, Integer_Range'Size
> > equals 8 for all cases which I expect should be true even for the
> > large cases since the elements of the array have no size.  I am
> > using GNAT 3.13p on WinNT.
> >
> > Has anyone used a similar approach for representing ranges or have
> > any advice on getting around the Storage_Error for large ranges?
>
> I don't understand the Size attribute well enough to be of much help
here...
> I just have not given it enough study.  I don't know of any language rule
> that would require GNAT to do what it's doing, but that doesn't mean there
> isn't one.  Or maybe it's a GNAT bug.  But most likely it's just something
> that the implementation has every right to do.  Like I said, I don't
really
> know.
>
> But... you might try playing with 'Size of the array type, 'Size of the
> array object, and 'Component_Size.  If nothing else, the error messages
may
> be illuminating.
>
> Mark Lundquist
> Rational Software

-Chad R. Meiners