Re: disjoint ranges ?

Re: disjoint ranges ?

[Pat Rogers]

"Philippe Torres" <ptorres@laas.fr> wrote in message
news:39E612C9.9BF98CD3@laas.fr...
> A very dumb question but i can't find the right syntax so here i am.
> How can i declare a type or subtype with a disjoint range ?

All too easy to answer -- you can't.

Generally for that kind of thing you need a bigger abstraction, either
a "bag" or a set.

---
Patrick Rogers                      Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: disjoint ranges ?

[Pat Rogers]

"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:8s59nu$ej4$1@news.huji.ac.il...

> This should be in the FAQ! It was discussed several time here (try
Deja).

Agreed.

> You might find this illuminating:
> http://www.adapower.com/lang/rangewholes.html

Yes, I know about that; I find it rather complex**.  In any case it is
an example of what I called "a bigger abstraction".

** As I understand it, in LanguageLawyerSpeak that is read as "I don't
like it."  ;-)



> Pat Rogers <progers@NOclasswideSPAM.com> wrote in message
> news:DhpF5.178$AR3.40313@nnrp2.sbc.net...
> > "Philippe Torres" <ptorres@laas.fr> wrote in message
> > news:39E612C9.9BF98CD3@laas.fr...
> > > A very dumb question but i can't find the right syntax so here i
am.
> > > How can i declare a type or subtype with a disjoint range ?
> >
> > All too easy to answer -- you can't.
> >
> > Generally for that kind of thing you need a bigger abstraction,
either
> > a "bag" or a set.
> >
> > ---
> > Patrick Rogers                      Consulting and Training in:
> > http://www.classwide.com      Deadline Schedulability Analysis
> > progers@classwide.com        Software Fault Tolerance
> > (281)648-3165                       Real-Time/OO Languages
> >
> > Adam ... does not deserve all the credit; much is due to Eve, the
> > first woman, and Satan, the first consultant.
> > Mark Twain
> >
> >
>
>
>

disjoint ranges ?

[Philippe Torres]

A very dumb question but i can't find the right syntax so here i am. 
How can i declare a type or subtype with a disjoint range ?

Example :

If i declare :
---
type Hours is new Integer range 0 .. 23 ;
--
i would like a
---
subtype Lunch_Hours is Hours range 7..9 & 12..14 & 19..21 ;
---
I know this syntax is totally incorrect but i would like to avoid
enumerations since :

1- enumeration types don't accept elements named as numeric literals. I
can't define : type Lunch_hours is (7,8,9,12,13,...);

2- if my range are big, i am in trouble.

Does someone have an idea ?

Thanks in advance
Philippe

Re: disjoint ranges ?

[Ehud Lamm]

This should be in the FAQ! It was discussed several time here (try Deja).
You might find this illuminating:
http://www.adapower.com/lang/rangewholes.html

--
Ehud Lamm   mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <==  Me!



Pat Rogers <progers@NOclasswideSPAM.com> wrote in message
news:DhpF5.178$AR3.40313@nnrp2.sbc.net...
> "Philippe Torres" <ptorres@laas.fr> wrote in message
> news:39E612C9.9BF98CD3@laas.fr...
> > A very dumb question but i can't find the right syntax so here i am.
> > How can i declare a type or subtype with a disjoint range ?
>
> All too easy to answer -- you can't.
>
> Generally for that kind of thing you need a bigger abstraction, either
> a "bag" or a set.
>
> ---
> Patrick Rogers                      Consulting and Training in:
> http://www.classwide.com      Deadline Schedulability Analysis
> progers@classwide.com        Software Fault Tolerance
> (281)648-3165                       Real-Time/OO Languages
>
> Adam ... does not deserve all the credit; much is due to Eve, the
> first woman, and Satan, the first consultant.
> Mark Twain
>
>

Re: disjoint ranges ?

[wayne lydecker]

>Philippe Torres wrote:
>
>> A very dumb question but i can't find the right syntax so here i am.
>> How can i declare a type or subtype with a disjoint range ?
>>
>> Example :
>>
>> If i declare :
>> ---
>> type Hours is new Integer range 0 .. 23 ;
>> --
>> i would like a
>> ---
>> subtype Lunch_Hours is Hours range 7..9 & 12..14 & 19..21 ;
>> ---
>
>The problem of disjoint ranges came up for me many years ago on a different
>project.   I
>even suggested this as a capability for Ada 9X, but my suggestion either
>fell through the
>cracks or I submitted it incorrectly.
>
>My first attempt at a solution was to try to overload the "in" test as a
>boolean function.  That
>turns out to be illegal for a variety of reasons that require careful study
>of the language rules
>for the "in" test.   It turns out that membership tests are not
>operations/operators in Ada.
>
>I finally ended up declaring a function that would do this test, but did
>not use operator
>overloading.   It does solve the problem, but requires you call the
>function each place
>you intend to use a value of the type.
>
>A better approach  would probably be to add a capability for assertion
>checking.
>This simple mechanism could be added at the type level or the subprogram
>level
>within the package specification.  The notion of range checks was a good
>one in
>the early design of Ada.   Perhaps the same thing can be accomplished
>through
>assertions in some future version.
>
>Richard Riehle

How about using a boolean array:

with Text_IO;
procedure lunch is
  type Hours is new Integer range 0 .. 23 ;
  Lunch_Hours : array (Hours) of Boolean :=
    (7..9 => True, 12..14 => True, 19..21 => True, others => False);
begin
  if Lunch_Hours(7) then
    text_io.put_line("Lunch time");
  else
    text_io.put_Line("Get back to work");
  end if;
end;


-- Wayne.

Re: disjoint ranges ?

[wayne lydecker]

> wayne lydecker wrote:
> 
> >How about using a boolean array:
> >
> > with Text_IO;
> > procedure lunch is
> >   type Hours is new Integer range 0 .. 23 ;
> >   Lunch_Hours : array (Hours) of Boolean :=
> >     (7..9 => True, 12..14 => True, 19..21 => True, others => False);
> > begin
> >   if Lunch_Hours(7) then
> >     text_io.put_line("Lunch time");
> >   else
> >     text_io.put_Line("Get back to work");
> >   end if;
> > end;
> 
> This is one of those, "I can find a way to do it in my language," examples.
> We can ultimately solve any programming problem in any programming
> language (Yes, I exaggerate slightly), but this returns us to the issue of
> expressiveness versus expressibility.   Certain languages are more expressive
> of certain problems.   They directly map the solution space to the problem
> space.
> 
> The original post, if I read it correctly, was not concerned with the question,
> "Can such and such be accomplished," but rather, "Is there a syntax to
> directly express the solution to the given problem?"   Pat Rogers candidly
> and succinctly answered, "No."  That was a correct answer.
> 
> Richard Riehle

I see your point.  Mine was a simple solution but did not employ
sets.  To mimic the union of homogenous sets is relatively simple,
here is how I did it.  There are many more operators other than
"in" that could also be coded, but I suspect that that is the
reason it's not part of the language.

-- Wayne.

package Sets is
  type Set_Type is array (1..2) of Integer;
  type Set_Array_Type is array (Positive range <>) of Set_Type;

  function Is_In (Value     : Integer;
                  Set_Array : Set_Array_Type)
                  return Boolean;
end;
----------
package body Sets is
  function Is_In (Value     : Integer;
                  Set_Array : Set_Array_Type)
                  return Boolean is
  begin
    for SA in Set_Array'range loop
      if Value >= Set_Array(SA)(1) and
         Value <= Set_Array(SA)(2) then
        Return True;
      end if;
    end loop;
    Return False;
  end;
end;
------------
with Sets;
with Text_IO;
procedure Lunch is
  Lunch_Hours : constant Sets.Set_Array_Type := ((7,9), (12,14), (19,21));
begin
  if Sets.Is_In (7, Lunch_Hours) then
    text_io.put_line("Lunch time");
  else
    text_io.put_Line("Get back to work");
  end if;
end;

Re: disjoint ranges ?

[Philippe Torres]

Ehud Lamm wrote:
> 
> This should be in the FAQ! It was discussed several time here (try Deja).
> You might find this illuminating:
> http://www.adapower.com/lang/rangewholes.html
> 
Thanks for that.

Philippe

Re: disjoint ranges ?

[Philippe Torres]

Jeff Carter wrote:
> 
> It's interesting how the useful things you can do easily with types and
> subtypes in Ada, and not at all or with difficulty in many (most?) other
> languages, lead people to expect even more from Ada's type system than
> it should reasonably be expected to do.
> 
It's very true but i find that, range being an attribute so common, the
union of ranges would be very useful and not that unreasonable. it could
only improve Ada's advantage in this domain. Perhaps in some future ?

Philippe

Re: disjoint ranges ?

[Ehud Lamm]

O agree with you on the "bigger abstraction" description.  I didn't want to
go into all the  details: explaining why disjoint ranges are what I'd call
"over abstractig" (you should remember to think about implementaion costs,
from time to time...)

That's why I referred to previous discussions here.

--
Ehud Lamm   mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <==  Me!



Pat Rogers <progers@NOclasswideSPAM.com> wrote in message
news:z6rF5.45$bz5.65618@nnrp3.sbc.net...
> "Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
> news:8s59nu$ej4$1@news.huji.ac.il...
>
> > This should be in the FAQ! It was discussed several time here (try
> Deja).
>
> Agreed.
>
> > You might find this illuminating:
> > http://www.adapower.com/lang/rangewholes.html
>
> Yes, I know about that; I find it rather complex**.  In any case it is
> an example of what I called "a bigger abstraction".
>
> ** As I understand it, in LanguageLawyerSpeak that is read as "I don't
> like it."  ;-)
>
>
>
> > Pat Rogers <progers@NOclasswideSPAM.com> wrote in message
> > news:DhpF5.178$AR3.40313@nnrp2.sbc.net...
> > > "Philippe Torres" <ptorres@laas.fr> wrote in message
> > > news:39E612C9.9BF98CD3@laas.fr...
> > > > A very dumb question but i can't find the right syntax so here i
> am.
> > > > How can i declare a type or subtype with a disjoint range ?
> > >
> > > All too easy to answer -- you can't.
> > >
> > > Generally for that kind of thing you need a bigger abstraction,
> either
> > > a "bag" or a set.
> > >
> > > ---
> > > Patrick Rogers                      Consulting and Training in:
> > > http://www.classwide.com      Deadline Schedulability Analysis
> > > progers@classwide.com        Software Fault Tolerance
> > > (281)648-3165                       Real-Time/OO Languages
> > >
> > > Adam ... does not deserve all the credit; much is due to Eve, the
> > > first woman, and Satan, the first consultant.
> > > Mark Twain
> > >
> > >
> >
> >
> >
>
>

Re: disjoint ranges ?

[Marin David Condic]

I have a similar experience. People *do* start to expect more capabilities
when they start seeing the various cool things they can do in Ada. A friend
of mine wanted to use enumerals to represent commands, but wanted to be able
to do something with correlating similar words to the same command. Some
version of wanting to interpret something like "Stop" "Quit" and "End" all
as the same thing. Of course there's no way to do that directly within a
single type or a subtype mechanism. One might resort to parallel types and
use 'Pos and 'Val to get you there or one might use groupings and ranges
(when Stop..End =>) to get you there, but there isn't some way of defining a
subtype with different enumerals for the same positions or some similar
mechanism.

Its a good example of how someone can see a feature in Ada and start
imagining even more powerful features resulting from it. Unfortunately, not
all imagined features are implementable.

MDC


Jeff Carter wrote:

> It's interesting how the useful things you can do easily with types and
> subtypes in Ada, and not at all or with difficulty in many (most?) other
> languages, lead people to expect even more from Ada's type system than
> it should reasonably be expected to do.

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: disjoint ranges ?

[Lao Xiao Hai]

Philippe Torres wrote:

> A very dumb question but i can't find the right syntax so here i am.
> How can i declare a type or subtype with a disjoint range ?
>
> Example :
>
> If i declare :
> ---
> type Hours is new Integer range 0 .. 23 ;
> --
> i would like a
> ---
> subtype Lunch_Hours is Hours range 7..9 & 12..14 & 19..21 ;
> ---

The problem of disjoint ranges came up for me many years ago on a different
project.   I
even suggested this as a capability for Ada 9X, but my suggestion either
fell through the
cracks or I submitted it incorrectly.

My first attempt at a solution was to try to overload the "in" test as a
boolean function.  That
turns out to be illegal for a variety of reasons that require careful study
of the language rules
for the "in" test.   It turns out that membership tests are not
operations/operators in Ada.

I finally ended up declaring a function that would do this test, but did
not use operator
overloading.   It does solve the problem, but requires you call the
function each place
you intend to use a value of the type.

A better approach  would probably be to add a capability for assertion
checking.
This simple mechanism could be added at the type level or the subprogram
level
within the package specification.  The notion of range checks was a good
one in
the early design of Ada.   Perhaps the same thing can be accomplished
through
assertions in some future version.

Richard Riehle

Re: disjoint ranges ?

[Lao Xiao Hai]

wayne lydecker wrote:

> >How about using a boolean array:
>
> with Text_IO;
> procedure lunch is
>   type Hours is new Integer range 0 .. 23 ;
>   Lunch_Hours : array (Hours) of Boolean :=
>     (7..9 => True, 12..14 => True, 19..21 => True, others => False);
> begin
>   if Lunch_Hours(7) then
>     text_io.put_line("Lunch time");
>   else
>     text_io.put_Line("Get back to work");
>   end if;
> end;

This is one of those, "I can find a way to do it in my language," examples.
We can ultimately solve any programming problem in any programming
language (Yes, I exaggerate slightly), but this returns us to the issue of
expressiveness versus expressibility.   Certain languages are more expressive
of certain problems.   They directly map the solution space to the problem
space.

The original post, if I read it correctly, was not concerned with the question,
"Can such and such be accomplished," but rather, "Is there a syntax to
directly express the solution to the given problem?"   Pat Rogers candidly
and succinctly answered, "No."  That was a correct answer.

There are some in the world of object technology who believe that enumerated
types are a bad idea because they are an artifact of an old-fashioned style of
programming.   This same criticism could be leveled at the whole issue of
range constraints.   While the notion of a range constraints was a good one
when first introduced,  it could be argued that the problem addressed by
a range constraint better can  be solved with assertions.  An assertion would
enable easy modeling of non-contiguous ranges.   Of course, this also makes
the compiler a bit more complicated and introduces other problems.  The
question is whether the new problems are worse than the old one being
solved.

I coming to believe more and more that an assertion model, similar to that
in Eiffel, would be a worthwhile capability of the next Ada standard.  At
the same time,  perhaps the new standard should make obsolescent some
of the outmoded ideas(e.g., variant records) that are anachronistic in the
contemporary world of OOP.

Just a little old-fashioned heresy on a warm Saturday evening in California.

Richard Riehle

Re: disjoint ranges ?

[Jeff Carter]

It's interesting how the useful things you can do easily with types and
subtypes in Ada, and not at all or with difficulty in many (most?) other
languages, lead people to expect even more from Ada's type system than
it should reasonably be expected to do.

I was recently asked a similar question, except the person was
attempting to create a subtype usable as an array index from a large
enumeration type. In this case, the problem was in the design; the type
needed to be broken into several smaller types. I asked the person what
language he had previously used, and was then able to ask, "How would
you have done this in X?" Ada provides a lot of powerful capabilities,
but at some point you have to do some work to get them to do what you
want.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail

Re: disjoint ranges ?

[Robert Dewar]

In article <39E6E890.3B13E7A9@laas.fr>,
  Philippe Torres <ptorres@laas.fr> wrote:
> It's very true but i find that, range being an attribute so
> common, the union of ranges would be very useful and not that
> unreasonable. it could
> only improve Ada's advantage in this domain. Perhaps in some
> future ?


No, it could be over all damaging. Every new feature you add
to a language damages it by adding to the understanding,
programming, description, and implementation complexity.
A feature like this is actually *quite* complex, think for
example, that we would have to allow dynamic bounds for the
ranges, and then the checks for disjointness get tricky
to describe (e.g. can several ranges be flat or superflat?
if they are, can bounds overlap for the flat ranges? etc)

That's only the tip of the iceburg complexity wise.

But the point is that you have to make sure that the value
of the feature more than undoes the damage done by its
addition. The burden of proof is tricky in this case, and
I doubt a convincing argument can be made for adding this
feature to the language.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: disjoint ranges ?

[Robert Dewar]

In article <39E7225D.88A4906@acm.org>,
> Its a good example of how someone can see a feature in Ada and
> start imagining even more powerful features resulting from it.
> Unfortunately, not
> all imagined features are implementable.

or properly definable. Often you see feature suggestions that
start off as pretty half baked misunderstandings of the
fundamental semantics of Ada. Even when this is not the case,
people have not *begun* to work out the implications of the
proposal. The subject of this thread is actually a good
example. Everyone can see what this means in the trivial
case presented in the first message of the thread.

But if you even *vaguely* attempt an orthogonal description
you run into all sorts of troubles.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: disjoint ranges ?

[Robert Dewar]

In article <39E75AE3.90F858CE@ix.netcom.com>,
  Lao Xiao Hai <laoxhai@ix.netcom.com> wrote:

> The problem of disjoint ranges came up for me many years ago
> on a different project.   I
> even suggested this as a capability for Ada 9X, but my
> suggestion either fell through the cracks or I submitted it
> incorrectly.

Nope! (speaking as one of the four authors of the Ada 9X
requirements document), it did not fall through the cracks,
it simply did not make it past the first cut where we rejected
complex features that seemed to clearly have insufficient value
from an expressive point of view. This particular one was
closer than some, but still far from the bar :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: disjoint ranges ?

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> No, it could be over all damaging. Every new feature you add
> to a language damages it by adding to the understanding,
> programming, description, and implementation complexity.

Quite true, but you don't necessarily have to add features in order to
add functionality.  Sometimes, making a feature more powerful can add
functionality without increasing complexity.

For example, the approach I would take in this case would be to add
arbitrary boolean conditions as invariant conditions (somewhat as in
Eiffel), and then *get rid of* all the various kinds of special-purpose
constraints (range, index, discrim, accuracy).  This would lead to
adding the requested functionality, at a net *decrease* in language
complexity.

Note that Eiffel doesn't quite solve this problem: it has arbitrary
invariant expressions on types, but they can't be applied to integers
(there's only one integer type, and it can't have invariants).

> A feature like this is actually *quite* complex, think for
> example, that we would have to allow dynamic bounds for the
> ranges, and then the checks for disjointness get tricky
> to describe (e.g. can several ranges be flat or superflat?
> if they are, can bounds overlap for the flat ranges? etc)
> 
> That's only the tip of the iceburg complexity wise.
> 
> But the point is that you have to make sure that the value
> of the feature more than undoes the damage done by its
> addition. The burden of proof is tricky in this case, and
> I doubt a convincing argument can be made for adding this
> feature to the language.

Agreed.  Simply *adding* this feature as a feature is not a good idea.

- Bob

Re: disjoint ranges ?

[Robert A Duff]

Lao Xiao Hai <laoxhai@ix.netcom.com> writes:

> The problem of disjoint ranges came up for me many years ago on a
> different project.  I even suggested this as a capability for Ada 9X,
> but my suggestion either fell through the cracks or I submitted it
> incorrectly.

I don't think it fell through the cracks, and you probably submitted it
correctly.  It was simply judged to be too much added complexity for too
little gain.  That doesn't mean it's a dumb idea -- it just means that
the trade-off was not worth it.

- Bob

Re: disjoint ranges ?

[Robert Dewar]

In article <wcc66ms91t9.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:

> For example, the approach I would take in this case would be
to add
> arbitrary boolean conditions as invariant conditions (somewhat
as in
> Eiffel), and then *get rid of* all the various kinds of
special-purpose
> constraints (range, index, discrim, accuracy).

But unless you have a secret solution to the halting problem,
you will be faced with considerable complexity of deciding
which of these conditions can be checked at compile time
(Indeed I think this could make 4.9 look like a picnic).

After all, you are the first to know that what looks simple
at first sight often turns out not to be.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: disjoint ranges ?

[Lao Xiao Hai]

Robert A Duff wrote:

> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > No, it could be over all damaging. Every new feature you add
> > to a language damages it by adding to the understanding,
> > programming, description, and implementation complexity.
>
> Quite true, but you don't necessarily have to add features in order to
> add functionality.  Sometimes, making a feature more powerful can add
> functionality without increasing complexity.

So, making a feature more powerful might be something such as being
able to overload the "in" membership test.   For some reason, this
operator is not really a first class operator in Ada.   I have often
wondered about the rationale for that decision.    If it were overloadable,

one could simply declare a membership function that would enable
disjoint membership tests.

I do see some problems with this when considered in terms of the
for loop since it would be a strange loop, indeed, that had disjoint
values.  On the other hand, that could also be an alternate solution
to the absence of a step capability.   Also, it does not have to
be incompatible with the requirement that the value be discrete.

Any thoughts on this?

Richard Riehle

Re: disjoint ranges ?

[Robert A Duff]

Lao Xiao Hai <laoxhai@ix.netcom.com> writes:

> So, making a feature more powerful might be something such as being
> able to overload the "in" membership test.

It might be in the abstract, but in the context of Ada, probably not.

>...   For some reason, this
> operator is not really a first class operator in Ada.   I have often
> wondered about the rationale for that decision.

What is the type of the right-hand side of "in" here:

    if X in Integer range 1..10 ...

?  Ada has no way of describing that type.  In order to make "in" a
normal operator, we would need to invent a way to pass types as
parameters, and talk about the type of a type (and subtypes).  This is
not entirely unreasonable in the abstract, but it would be an enormous
change to Ada.

Consider:

    type T is range 1..100;
    function "in"(X: T; Y: type-of-T?) return Boolean;

Or maybe it should be T'in?  Anyway, it raises all kinds of questions.
What *is* the range of T (given that "in" changes it)?

- Bob

Re: disjoint ranges ?

[Lao Xiao Hai]

Robert A Duff wrote:

> Lao Xiao Hai <laoxhai@ix.netcom.com> writes:
>
> > So, making a feature more powerful might be something such as being
> > able to overload the "in" membership test.
>
> It might be in the abstract, but in the context of Ada, probably not.
>
> >...   For some reason, this
> > operator is not really a first class operator in Ada.   I have often
> > wondered about the rationale for that decision.
>
> What is the type of the right-hand side of "in" here:
>
>     if X in Integer range 1..10 ...
>
> ?  Ada has no way of describing that type.  In order to make "in" a
> normal operator, we would need to invent a way to pass types as
> parameters, and talk about the type of a type (and subtypes).  This is
> not entirely unreasonable in the abstract, but it would be an enormous
> change to Ada.
>
> Consider:
>
>     type T is range 1..100;
>     function "in"(X: T; Y: type-of-T?) return Boolean;
>
> Or maybe it should be T'in?  Anyway, it raises all kinds of questions.
> What *is* the range of T (given that "in" changes it)?

I see your point about the magnitude of the change required to pass a type
as
a parameter.    I suppose I did not think this through as carefully as I
should
have.   Still, it would be nice to be able to do something like this.
On the
other hand.   I don't think there is much virtue in making wrenching
changes
in the language design.

Thanks,

Richard

Re: disjoint ranges ?

[Robert Dewar]

In article <39EBB984.F2F8905F@ix.netcom.com>,
  Lao Xiao Hai <laoxhai@ix.netcom.com> wrote:
> So, making a feature more powerful might be something such as
being
> able to overload the "in" membership test.   For some reason,
this
> operator is not really a first class operator in Ada.

For very good reasons! The right operand of IN is not a value,
but a range. If you want to start making discrete ranges
first class values, you have suddenly taken (one of many)
avaliable trains to the land-of-increased-complexity.

It is easy to throw out an idea like this casually, but if
you even start to try to think what all the effects would
be on the existing semantics, you will find that it is far
harder than you think. Language design is like skiing, it
looks much easier than it is, and it is only when you actually
start doing it, that you find out it is more complex :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: disjoint ranges ?

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

>... Language design is like skiing, it
> looks much easier than it is, and it is only when you actually
> start doing it, that you find out it is more complex :-)

I must note that some of the designers of Ada 9X are avid skiers.
Tucker is better at it than I.  :-(

- Bob

Re: disjoint ranges ?

[dmitry6243]

In article <wccr95fobf6.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Lao Xiao Hai <laoxhai@ix.netcom.com> writes:
>
> > So, making a feature more powerful might be something such as being
> > able to overload the "in" membership test.
>
> It might be in the abstract, but in the context of Ada, probably not.
>
> >...   For some reason, this
> > operator is not really a first class operator in Ada.   I have often
> > wondered about the rationale for that decision.
>
> What is the type of the right-hand side of "in" here:
>
>     if X in Integer range 1..10 ...
>
> ?  Ada has no way of describing that type.  In order to make "in" a
> normal operator, we would need to invent a way to pass types as
> parameters, and talk about the type of a type (and subtypes).  This is
> not entirely unreasonable in the abstract, but it would be an enormous
> change to Ada.
>
> Consider:
>
>     type T is range 1..100;
>     function "in"(X: T; Y: type-of-T?) return Boolean;
>
> Or maybe it should be T'in?  Anyway, it raises all kinds of questions.
> What *is* the range of T (given that "in" changes it)?

IMO, to make it consistent one should introduce built-in index types (or
better to say, make them visible). Compare:

type A is array (Integer range 1..100) of ...;

and

type B is index (Integer range 1..100);

Array slice is a subarray. Index slice is a range. Array indexed by a
value of its index type is a subarray. Then

type T is range 1..100;
type T_Index is index (T);

function "in" (X: T; Y: T_Index) return Boolean;

Surely indices can be multi-dimensional:

type Square_Index is index (Integer range 1..100, Integer 1..100);

Surely one needs an attribute to get an anonymous index type from array.
Ada already has it! It is 'range. Unfortunately 'range = 'range(1) for
multi-dimensional arrays.

Static values of index types can used where ellipsis ".." appear.
Actually "range N..M" is a literal of an anonymous index type
(or maybe, of universal index type).

--
Regards,
Dmitry Kazakov


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Overloading "in" (was: disjoint ranges ?)

[Ehud Lamm]

Jeff Carter <jrcarter@acm.org> wrote in message
news:39EE6610.C91290B@acm.org...
> One possible syntax is
>
> function "in" (Left : T; Right : T range <>) return Boolean;
>

The problem is not the syntax! It is a semantics issue.

Just like the original poster had a synatx for "disjoint ranges"...
It is much easier to invent syntax, than solve the semantics/implementation
issues.
Heck, I invent new syntax everyday: and  I get compile time errors, beacuse
of it...


--
Ehud Lamm   mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <==  Me!

Overloading "in" (was: disjoint ranges ?)

[Jeff Carter]

One possible syntax is

function "in" (Left : T; Right : T range <>) return Boolean;

Not that I'm advocating including this capability.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail

Re: Overloading "in" (was: disjoint ranges ?)

[Jeff Carter]

Robert Dewar wrote:
> 
> In article <39EE6610.C91290B@acm.org>,
>   Jeff Carter <jrcarter@acm.org> wrote:
> > One possible syntax is
> >
> > function "in" (Left : T; Right : T range <>) return Boolean;
> >
> > Not that I'm advocating including this capability.
> 
> Yes, well anyone can dream up syntax like this, but figuring
> out the semantics and how it fits into the rest of the language
> may be a mind boggling excercise in complexity introduction :-)

Which is why I don't advocate adding it to the language :)

-- 
Jeff Carter
"I waggle my private parts at your aunties."
Monty Python & the Holy Grail

Re: Overloading "in" (was: disjoint ranges ?)

[Robert Dewar]

In article <39EE6610.C91290B@acm.org>,
  Jeff Carter <jrcarter@acm.org> wrote:
> One possible syntax is
>
> function "in" (Left : T; Right : T range <>) return Boolean;
>
> Not that I'm advocating including this capability.
>
> --
> Jeff Carter
> "You tiny-brained wipers of other people's bottoms!"
> Monty Python & the Holy Grail


Yes, well anyone can dream up syntax like this, but figuring
out the semantics and how it fits into the rest of the language
may be a mind boggling excercise in complexity introduction :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: disjoint ranges ?

[Charles Hixson]

Lao Xiao Hai wrote:

> ...
> There are some in the world of object technology who believe that enumerated
> types are a bad idea because they are an artifact of an old-fashioned style of
> programming.   This same criticism could be leveled at the whole issue of
> range constraints.   While the notion of a range constraints was a good one
> when first introduced,  it could be argued that the problem addressed by
> a range constraint better can  be solved with assertions.  An assertion would
> enable easy modeling of non-contiguous ranges.   Of course, this also makes
> the compiler a bit more complicated and introduces other problems.  The
> question is whether the new problems are worse than the old one being
> solved.
> ...

Many criticisms of features are based upon the way that C++ implements the
feature.  This is not exactly fair, but is perhaps inevitable as C++ is the most
commonly known language.  Since Java is the second, and there is a large overlap
between the user base, perhaps if C++ does a poor job of implementing a feature,
and Java leaves it out, we can expect the feature itself to be criticized.

The assumption that there is some basic "right" way to do things is probably
wrong.  It seems to me that there are a range of correct ways, some more suited to
some problems, and others to others.  It also seems that there are a range of ways
to think, and that some are more suited to some programming constructs, and others
to others.  It's not really clear that one would gain anything by shoehorning a
construct where it didn't fit naturally.  Ada is designed, complex, intricate,
reliable, "small", and, especially, Formal.  This is seen in the Ada implementation
of Objects as Tagged records.  It makes perfect sense, after you think about it
long enough.  A tagged type makes explicit things which most implementations of
Objects leave implicit.  If you feel that these things should be implicit, then you
are more likely to feel that the members of an enumerated type should be hidden
behind the impermeable walls of a class.  But there are lots of problems with
that.  The lack of enumerated types is one of Java's big weaknesses, even if I
don't like the way that C handles them.

-- (c) Charles Hixson
--  Addition of advertisements or hyperlinks to products specifically prohibited

Re: disjoint ranges ?

[dmitry6243]

In article <39F48116.35EE68C9@earthlink.net>,
  Charles Hixson <charleshixsn@earthlink.net> wrote:
> Lao Xiao Hai wrote:
>
> > ...
> > There are some in the world of object technology who believe that
enumerated
> > types are a bad idea because they are an artifact of an
old-fashioned style of
> > programming.   This same criticism could be leveled at the whole
issue of
> > range constraints.   While the notion of a range constraints was a
good one
> > when first introduced,  it could be argued that the problem
addressed by
> > a range constraint better can  be solved with assertions.  An
assertion would
> > enable easy modeling of non-contiguous ranges.   Of course, this
also makes
> > the compiler a bit more complicated and introduces other problems.
The
> > question is whether the new problems are worse than the old one
being
> > solved.
> > ...
>
> Many criticisms of features are based upon the way that C++ implements
the
> feature.  This is not exactly fair, but is perhaps inevitable as C++
is the most
> commonly known language.  Since Java is the second, and there is a
large overlap
> between the user base, perhaps if C++ does a poor job of implementing
a feature,
> and Java leaves it out, we can expect the feature itself to be
criticized.
>
> The assumption that there is some basic "right" way to do things is
probably
> wrong.  It seems to me that there are a range of correct ways, some
more suited to
> some problems, and others to others.

if 2 + 2 = 5 then
   5 := 4;
end if;    -- (:-))

(It isn't my invention. I forgot autor's name)

>  It also seems that there are a
range of ways
> to think, and that some are more suited to some programming
constructs, and others
> to others.  It's not really clear that one would gain anything by
shoehorning a
> construct where it didn't fit naturally.

Correct, but also requires an explanation why this or that construct
does not fit. Maybe it does not fit because some of already adopted
constructs fit even less than it.

>  Ada is designed, complex,
intricate,
> reliable, "small", and, especially, Formal.

... and regular.

However, there are lot of irregularities in Ada 95. One example is
missing procedural types (in presense of access procedural types).

>  This is seen in the Ada
implementation
> of Objects as Tagged records.  It makes perfect sense, after you think
about it
> long enough.  A tagged type makes explicit things which most
implementations of
> Objects leave implicit.

... for a very good reason: to hide implementation details.

IMO, Ada's way is very disputable (object=record, single inheritance, no
way to define supertypes, etc), except for one really EXCELLENT thing:
distinction between class-wide and "normal" values/pointers. This, I
believe, would allow (in some distant future (:-)) to have multiple
dispatch in Ada.

>  If you feel that these things should be
implicit, then you
> are more likely to feel that the members of an enumerated type should
be hidden
> behind the impermeable walls of a class.

It is of course a question whether enumerated types should be built-in.
I think they should.

Another question is whether they should be allowed to have methods
(impossible in Ada, because enumerated types are not tagged). There is
no big need in that, but I see no "physical" reason why they should not.

> But there are lots of problems with
> that.  The lack of enumerated types is one of Java's big weaknesses,
even if I
> don't like the way that C handles them.

Simply enums are so bad, that it was not a big loss. Lack of reasonable
enumerated types "supported" by comical visiblity rules is one of my
biggest problem when I'm switching from Ada to C++.

--
Regards,
Dmitry Kazakov


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: disjoint ranges ?

[Andrew Cooke]

I've just read the discussion following this article after it was
recommended as interesting at http://lambda.weblogs.com/

I know the following is a "but my language can do it" post, and that
many people here may already know the following, but I was surprised
that no-one mentioned that this kind of thing is possible in Lisp and I
wondered if knowing how Lisp works would help suggest an acceptable
semantics for Ada.

Anyway, if you're interested, (Common) Lisp specifies types using "type
specifiers".  I'm no Lisp expert, but these appear to be expressions
that test for type membership - either simple expressions or lists.  For
more information see http://www.lisp.org/HyperSpec/Body/sec_4-1.html

I suspect this would be a huge change to Ada (I guess it does not have
type specifiers).  And I have no idea how they make it efficient
(but Lisp seems to be pretty good at producing elegant ideas that are
also efficient)...

Andrew

PS Sorry if this is such a crap post it's embarassing, Ehud ;-)

In article <39E612C9.9BF98CD3@laas.fr>,
  Philippe Torres <ptorres@laas.fr> wrote:
> A very dumb question but i can't find the right syntax so here i am.
> How can i declare a type or subtype with a disjoint range ?
>
> Example :
>
> If i declare :
> ---
> type Hours is new Integer range 0 .. 23 ;
> --
> i would like a
> ---
> subtype Lunch_Hours is Hours range 7..9 & 12..14 & 19..21 ;
> ---
> I know this syntax is totally incorrect but i would like to avoid
> enumerations since :
>
> 1- enumeration types don't accept elements named as numeric literals.
I
> can't define : type Lunch_hours is (7,8,9,12,13,...);
>
> 2- if my range are big, i am in trouble.
>
> Does someone have an idea ?
>
> Thanks in advance
> Philippe
>


Sent via Deja.com http://www.deja.com/
Before you buy.