Re: Ragged Array Proposal

Re: Ragged Array Proposal

[Ted Dennison]

In article <37e7c08e@eeyore.callnetuk.com>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> I have set up a WWW site, and posted an article on it detailing a
first
> draft of my proposal for a 'ragged array type' extension to the
language.
> The URL is:
>
> http://www.callnetuk.com/home/nickroberts
>
> Do please take a look.
>
> I seem to get the impression that the cognoscenti consider this
> particular idea worthless. I am perfectly serious about it, however;

I would have used the word "excessive" rather than "worthless". But then
again, I probably wouldn't count as a cognoscentum.

One thing confuses me about your proposal. You say that when the array
is declared all the elements will be constrained. But then you say that
you can dynamicly change elements. Are you saying that if I try to
assign a 5 character string into an array element that is a 4 character
string, the compiler would accept it? If so, how about if a function
returns a 5 character string? Or how about if the 4 character string
element in the ragged array is passed into a subprogram as an "out" or
"in out" parameter?

Also for your example you say "the various ways of doing the equivalent
thing in Ada 95 are all unappealing." I but I can do the equivalent
thing in Ada 95 in only 2 more lines of code:

   type Command_String_Ptr is access all String;
   for Command_String_Ptr'Storage_Size use 1024;

   type Command is (Cut, Copy, Paste, ...);

   Labels: constant array (Command) of Command_String_Ptr :=
      (Cut      => new String'("Cu&t"),
       Copy     => new String'("&Copy"),

       Paste    => new String'("&Paste"),
       ...);

Admittedly I have to keep watch that I leave enough space in the pool
for all the command strings. But if this is in an outer block on a
virtual memory OS (by far the typcial case), I don't even need the "for"
clause.

Anyway, perhaps you should explain in the proposal why this approach is
unappealing vs. complicating the language.

On the plus side, I find the proposal's visual layout, as well as that
of the rest of your website, quite visually appealing. I hope it won't
be too much of a challange to maintain that standard as your website
grows.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ragged Array Proposal

[Ray Blaak]

Ted Dennison <dennison@telepath.com> writes:
> Also for your example you say "the various ways of doing the equivalent
> thing in Ada 95 are all unappealing." I but I can do the equivalent
> thing in Ada 95 in only 2 more lines of code:
> 
>    type Command_String_Ptr is access all String;
>    for Command_String_Ptr'Storage_Size use 1024;
> 
>    type Command is (Cut, Copy, Paste, ...);
> 
>    Labels: constant array (Command) of Command_String_Ptr :=
>       (Cut      => new String'("Cu&t"),
>        Copy     => new String'("&Copy"),
> 
>        Paste    => new String'("&Paste"),
>        ...);

The problem with this approach is that the data is duplicated. It is both in
the static data area of the program (i.e. the string constants), and in the
heap.

In Ada95, to avoid duplicating the data, the approach is tedious (i.e. having
an aliased constant for each string, and assigning their 'Access values into
the array).

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Ragged Array Proposal

[Ted Dennison]

In article <m3vh922o3u.fsf@vault80.infomatch.bc.ca>,
  Ray Blaak <blaak@infomatch.com> wrote:
> Ted Dennison <dennison@telepath.com> writes:

> >    Labels: constant array (Command) of Command_String_Ptr :=
> >       (Cut      => new String'("Cu&t"),
> >        Copy     => new String'("&Copy"),
> >
> >        Paste    => new String'("&Paste"),
> >        ...);
>
> The problem with this approach is that the data is duplicated. It is
> both in the static data area of the program (i.e. the string
> constants), and in the heap.

Perhaps. But unless I'm operating in an extremely low memory
environment, why should I care? An if memory is that limited, I probably
will be using a language subset that doesn't allow dynamic allocation
anyway.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ragged Array Proposal

[Tucker Taft]

Ray Blaak wrote:
> 
> Ted Dennison <dennison@telepath.com> writes:
> > Also for your example you say "the various ways of doing the equivalent
> > thing in Ada 95 are all unappealing." I but I can do the equivalent
> > thing in Ada 95 in only 2 more lines of code:
> >
> >    type Command_String_Ptr is access all String;
> >    for Command_String_Ptr'Storage_Size use 1024;
> >
> >    type Command is (Cut, Copy, Paste, ...);
> >
> >    Labels: constant array (Command) of Command_String_Ptr :=
> >       (Cut      => new String'("Cu&t"),
> >        Copy     => new String'("&Copy"),
> >
> >        Paste    => new String'("&Paste"),
> >        ...);
> 
> The problem with this approach is that the data is duplicated. It is both in
> the static data area of the program (i.e. the string constants), and in the
> heap.

If you change Command_String_Ptr to be "access constant String;" then
the recommended implementation does *not* duplicate the static data.
It is link-time allocated and initialized.  This might vary by compiler,
but anything having to do with link-time initialization is an "optimization,"
so that is true even for static constants.  I know at least that the
Aonix and Green Hills Ada 95 compilers statically allocate and initialize
allocators for access-to-constant types.  I haven't checked GNAT.

> In Ada95, to avoid duplicating the data, the approach is tedious (i.e. having
> an aliased constant for each string, and assigning their 'Access values into
> the array).

As mentioned above, that is not necessary if the type is access-to-constant
(which it must be if you are using 'Access on aliased constants).
Take a look at the generated code for new String'("xxx") when the type
is access-to-constant.  It should not involve any run-time code (presuming
the implementation advice was followed by the compiler implementor).
> > --
> Cheers,                                        The Rhythm is around me,
>                                                The Rhythm has control.
> Ray Blaak                                      The Rhythm is inside me,
> blaak@infomatch.com                            The Rhythm has my soul.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ragged Array Proposal

[Nick Roberts]

Tucker Taft <stt@averstar.com> wrote in message
news:37EA4E91.1D4D1FC@averstar.com...
[...]
| If you change Command_String_Ptr to be "access constant String;" then
| the recommended implementation does *not* duplicate the static data.
| It is link-time allocated and initialized.  This might vary by compiler,
| but anything having to do with link-time initialization is an
"optimization,"
| so that is true even for static constants.  I know at least that the
| Aonix and Green Hills Ada 95 compilers statically allocate and initialize
| allocators for access-to-constant types.  I haven't checked GNAT.
[...]

My contention is that using an access type and allocators is unappealing
simply because the programmer is forced to use an access type and allocators
for doing something _really simple_: declaring an array of strings!

With the greatest respect, it is perhaps easy for those of you who are
steeped in knowledge of the language to overlook this (and there can be no
arguing that STT is steeped in knowledge of the language!).

Try telling a C++ programmer that, in Ada, they have to declare an access
type, and then repeat the "new String'("xyz")" incantation for every string,
just to declare an array of strings, and they might be likely to say "Ada?
No thanks, I'll stick to C++, if you don't mind."

Frankly, the pre-allocation trick (which is fine and dandy in all other
respects) only makes things worse from this point of view (simplicity for
the programmer), since it makes it looks like something is happening
(dynamic allocation) which is actually not. I agree with the idea that Ada
language constructs should not be too divorced from their likely underlying
implementations, and this seems like a rare example of Ada committing this
sin. I would agree that ragged arrays commit the same sin, but I would say
less so.

To those who argue that adding ragged arrays would add unnecessary
complexity to the language, my reply is not to confuse complexity of the
language with complexity of _using_ the language. It would unarguably
simplify the language tremendously to remove arrays, records, generics,
tagged types, subprograms, etc., but it wouldn't simplify using the
language. My argument is that ragged arrays would add relatively little to
the complexity of the language, but would, in practice, very often simplify
using the language a great deal.

I think the example of the ragged array in a record demonstrates the most
serious reason for introducing ragged arrays. Think about the likely
underlying implementation for this (an array of pointers or offsets and a
block of data, all totally internal to the record), and then think about how
the same thing could be done in existing Ada 95.

In general, the closest you can get in Ada 95 is to use an access type
(either to the array as a whole, or to the components of the array), and
dynamic allocation. The ragged array will generally be more efficient: if
your program is going to have multiple objects constrained to the same
subtype of the record (a very likely scenario), the 'dope' information only
needs to be stored once, saving memory; the necessity to call upon the
allocator to allocate either the array or its components is avoided, saving
processor time; the necessity to declare access types and mess around with
the associated paraphernalia can be avoided (saving hair, in extreme cases
:-).

Ted Dennison wrote:

| One thing confuses me about your proposal. You say that when the array
| is declared all the elements will be constrained. But then you say that
| you can dynamicly change elements. Are you saying that if I try to
| assign a 5 character string into an array element that is a 4 character
| string, the compiler would accept it? If so, how about if a function
| returns a 5 character string? Or how about if the 4 character string
| element in the ragged array is passed into a subprogram as an "out" or
| "in out" parameter?

I'm not quite sure where I say this, Ted, but I hope I can clarify things
using your examples.

The subtypes of the components of a ragged array, called the 'profile' of
the array, form part of the constraint of the array. Supposing we declared
an 'array of strings' ragged array type:

type String_Array is array (Positive range <>) of String;

we could then declare an object of this type, constrained to, say, three
components, with a profile of, say, a 3-character string, a 4-character
string, and a 5-character string:

People: String_Array(1..3)(String(1..3),String(1..4),String(1..5));

Note the 'profiled constraint': an ordinary index constraint, followed by an
'array profile'. Alternatively, the object could have been constrained by an
initial value:

People: String_Array := ("Tom","Dick","Harry");

(Note the nice, simple syntax.) Either way, People is now permanently
constrained, both in terms of its indexes and its profile. The assignment:

People(2) := "Jane";

would be perfectly all right, since People(2) is a 4-character string.
However, either of:

People(3) := "Jane";
People(2) := "Emily";

would raise Constraint_Error. Nothing can change either the index subtype or
the profile of People, and its components follow the same rules they would
as stand-alone objects.

Since the actual parameter matching an 'out' or 'in out' mode formal
parameter must be an object, and all objects of an array type - including my
proposed ragged array type - must be constrained, the constraint, including
the profile of a ragged array, would be passed in upon a call to the
procedure, just as with all other mutable types, and the procedure could not
change the constraint.

As for a function result, since function return types (as well as any
subprogram parameter types) are allowed to be unconstrained, a function
could be declared which had simply String_Array as its return type, and then
the function could return results with any compatible subtype (i.e. any
index range and any profile).

For example, a function could be defined to reverse the order of the
components of a string array:

function Reverse_Order (A: in String_Array) return String_Array;

and then the expression Reverse_Order(("Tom","Dick","Harry")) would return
the array ("Harry","Dick","Tom").

It is significant to note that the implementation of this function would
have to be highly inefficient (involving repeated slicing and
concatenating). This illustrates that there would often be situations where
an array of access values would be far preferable to a ragged array. My
argument is that, conversely, there would often be situations where a ragged
array would be preferable to an array of access values.

I'm grateful to Ted for his compliment on the appearance of my site (I'll
try to maintain the standard!), and I'm very grateful to people taking the
time to look at my proposal and post comments.

Best wishes,

-------------------------------------
Nick Roberts
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos
-------------------------------------

PS: I'm not at all emotionally attached to the nomenclature that I've
invented (even the name "ragged array"), and not entirely happy with it, so
suggestions for improvements gratefully accepted. The same goes for the
syntax.

PPS: Hold on to your hats, folks! Next up is going to be a 'single derived
object' proposal. I haven't finished with you yet :-)

Re: Ragged Array Proposal

[Hyman Rosen]

"Nick Roberts" <nickroberts@callnetuk.com> writes:
> Try telling a C++ programmer that, in Ada, they have to declare an access
> type, and then repeat the "new String'("xyz")" incantation for every string,
> just to declare an array of strings, and they might be likely to say "Ada?
> No thanks, I'll stick to C++, if you don't mind."

A C programmer, maybe. In C++, if you want to initialize one of the
STL containers with constant data, you pretty much have to make copies
of things.

In C, we often do

char *fruits[] = { "apple", "orange", "pear" };

The compiler does a bunch of accounting for us to make this possible.
What we have really written above is the following:

static char unique_apple[6]    { 'a', 'p', 'p', 'l', 'e', 0 };
static char unique_orange[7] = { 'o', 'r', 'a', 'n', 'g', 'e', 0 };
static char unique_pear[5]   =  { 'p', 'e', 'a', 'r', 0 };

char *fruits[3] = { &unique_apple[0], &unique_orange[0], &unique_pear[0] };

Is it possible to do something similar in Ada?
Something like (forgive my fractured pseudo-Ada syntax) -

apple:  aliased String(5) := "apple";
orange: aliased String(6) := "orange";
pear:   aliased String(4) := "pear";

type StringPtr is access String(<>);

fruits: StringPtr[1..3] := (apple'access, orange'access, pear'access);

Re: Ragged Array Proposal

[Nick Roberts]

Hyman Rosen <hymie@prolifics.com> wrote in message
news:t7k8ph19um.fsf@calumny.jyacc.com...
[...]
| Is it possible to do something similar in Ada?
| Something like (forgive my fractured pseudo-Ada syntax) -
|
| apple:  aliased String(5) := "apple";
| orange: aliased String(6) := "orange";
| pear:   aliased String(4) := "pear";
|
| type StringPtr is access String(<>);
|
| fruits: StringPtr[1..3] := (apple'access, orange'access, pear'access);

This is one of the unappealing alternatives I was talking about.

In Ada 95, one would have to write something like:

Fruit_001: constant aliased String := "Apple";
Fruit_002: constant aliased String := "Orange";
Fruit_003: constant aliased String := "Pear";
...

type String_Sight is access constant String;

Fruits: constant array (Positive range <>) of String_Sight :=
    (Fruit_001'Access, Fruit_002'Access, Fruit_003'Access, ...);

Whereas with ragged arrays, one need only write:

Fruits: constant array (Positive range <>) of String :=
    ("Apple", "Orange", "Pear", ...);

Much simpler and clearer, don't you think?

-------------------------------------
Nick Roberts
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos
-------------------------------------

Re: Ragged Array Proposal

[Hyman Rosen]

"Nick Roberts" <nickroberts@callnetuk.com> writes:
> Whereas with ragged arrays, one need only write:
> Fruits: constant array (Positive range <>) of String :=
>     ("Apple", "Orange", "Pear", ...);
> Much simpler and clearer, don't you think?

I don't know, because I don't have the correct intuitions about Ada.
The more complicated version certainly seems to me like the sort of
code generally advocated here, where everything is very explicitly
stated in the code.

Re: Ragged Array Proposal

[Robert Dewar]

In article <t74sgkys8h.fsf@calumny.jyacc.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
> I don't know, because I don't have the correct intuitions
about Ada.
> The more complicated version
      ^^^^^^^^^^^^^^^^

"more complicated" /= longer

Actually the C version is quite a bit more complex, because of
the rather peculiar rules about whether string pointers are
or are not constants, and about the issue of whether
"abc" == "abc" (in general of course the answer in C is no)

It looks simpler, but that can hide a lot of sins :-)


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

Re: Ragged Array Proposal

[Hyman Rosen]

Robert Dewar <robert_dewar@my-deja.com> writes:
> "more complicated" /= longer
> 
> Actually the C version is quite a bit more complex, because of
> the rather peculiar rules about whether string pointers are
> or are not constants, and about the issue of whether
> "abc" == "abc" (in general of course the answer in C is no)
> 
> It looks simpler, but that can hide a lot of sins :-)

Like I said, I don't have proper Ada intuition. Frankly, for all its
supposed readability, looking at Ada code makes my eyes and my brain
swim. I think it's because Ada uses too many words and not enough
symbols. I've felt that way ever since I first saw Ada code lo those
many years ago, and I still feel so today.

I would certainly say that C's type system is simpler than Ada's.
The C ragged array example is completely simple. Granted, you have
to know C, but that's true of any language.

Re: Ragged Array Proposal

[Brian Rogoff]

On 27 Sep 1999, Hyman Rosen wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
> > "more complicated" /= longer
> > 
> > Actually the C version is quite a bit more complex, because of
> > the rather peculiar rules about whether string pointers are
> > or are not constants, and about the issue of whether
> > "abc" == "abc" (in general of course the answer in C is no)
> > 
> > It looks simpler, but that can hide a lot of sins :-)
> 
> Like I said, I don't have proper Ada intuition. Frankly, for all its
> supposed readability, looking at Ada code makes my eyes and my brain
> swim. I think it's because Ada uses too many words and not enough
> symbols. I've felt that way ever since I first saw Ada code lo those
> many years ago, and I still feel so today.

That's funny. I actually agree that Ada is a bit wordy for my tastes, and
would prefer a few more symbols, but I find that reading C++ "makes my
eyes and brain swim" because of its overuse of symbols, weird overloadings 
of words like "static", and generally bad syntax. I find well written Ada
far easier to read than C or C++, even though I write much more C family 
language code! To be fair, C++ is the way it is largely to remain
compatible with C; reading the examples in the "C++ resyntaxed" paper
(where C++ gets a slightly more Pascalish syntax) was much easier to me.

I guess you can only please some of the people some of the time...

-- Brian

Re: Ragged Array Proposal

[Robert Dewar]

In article <t7zoy8vt8x.fsf@calumny.jyacc.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
> > "more complicated" /= longer
> >
> > Actually the C version is quite a bit more complex, because
of
> > the rather peculiar rules about whether string pointers are
> > or are not constants, and about the issue of whether
> > "abc" == "abc" (in general of course the answer in C is no)
> >
> > It looks simpler, but that can hide a lot of sins :-)
>
> Like I said, I don't have proper Ada intuition. Frankly, for
all its
> supposed readability, looking at Ada code makes my eyes and my
brain
> swim. I think it's because Ada uses too many words and not
enough
> symbols. I've felt that way ever since I first saw Ada code lo
those
> many years ago, and I still feel so today.
>
> I would certainly say that C's type system is simpler than
Ada's.
> The C ragged array example is completely simple. Granted, you
have
> to know C, but that's true of any language.

No, I still disagree, the apparent simple syntax of C in this
case hides too many details. In particular, the fact that the
string literals are not what they appear, but instead are
implicit pointers is quite confusing.

In particular there are two confusing issues

1. Are the referenced strings constants or variables? As you
know the answer is not simple, and in some cases is even
implementation dependent in practice, or has compiler switches
to control the answer.

2. The equality check between two strings

   if (a == "the") { ...

   has difficult semantics. Generally it does not do at all
   what is expected, and in some cases again, the result can
   be implementation or compiler switch dependent.

Sure you can respond "well you have to know C", but, note that
a common type of publication in the C community are books that
go through pitfalls like this, and explain how to avoid falling
into them. Ada prefers an approach that avoids the pitfalls in
the first place.

There is even a C++ primer that has a section called "pitfalls"
in every chapter, outlining things that compile fine, but do not
do what you might expect at run time.

This kind of phenomenon is simply far less common in Ada, since
Ada was designed to avoid pitfalls of this kind, note that I
say far less common, not non-existant, but the difference is
striking.

Sure, if you know a language well enough, you can completly
insulate yourself from such problems. This is also true of
PDP-8 machine language, but this is NOT a legitimate argument
for writing in PDP-8 machine language!



>


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

Re: Ragged Array Proposal

[Ted Dennison]

In article <37eaa24b@eeyore.callnetuk.com>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:

> People: String_Array(1..3)(String(1..3),String(1..4),String(1..5));
>

I'm not sure I like this example. Right now in Ada you would have to use
explicit subtypes in any such declaration. But above you are using
anonymous subtypes (eg: "String(1..3)"). I know creating a bunch
of onetime subtypes might seem to be a pain, but it would restore
consistency with the rest of the language.

> (Note the nice, simple syntax.) Either way, People is now permanently
> constrained, both in terms of its indexes and its profile. The
assignment:
>
> People(3) := "Jane";
> People(2) := "Emily";
>
> would raise Constraint_Error. Nothing can change either the index

OK. That's not so bad then. It would seem quite possible to create stack
space for such variables. The only bad issue I still see is that its
probably going to need a dope vector from hell to keep track of all the
contraints of all its elements. But this isn't any different than the
current situation with my array of string pointers.

I'm starting to like this proposal.

I think the syntax does need still some work. For instance, can variant
records be components too? What would one of those declarations look
like? How about classwide tagged types?

Also, if we do this, wouldn't the constrained subtype restriction on
record fields start to look a bit restrictive?

--
T.E.D.


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

Re: Ragged Array Proposal

[Nick Roberts]

Ted Dennison <dennison@telepath.com> wrote in message
news:7sg24e$4oo$1@nnrp1.deja.com...
[...]
| > People: String_Array(1..3)(String(1..3),String(1..4),String(1..5));
|
| I'm not sure I like this example. Right now in Ada you would have to use
| explicit subtypes in any such declaration. But above you are using
| anonymous subtypes (eg: "String(1..3)"). I know creating a bunch
| of onetime subtypes might seem to be a pain, but it would restore
| consistency with the rest of the language.

I'm not quite sure what Ted is about here, but Ada has always allowed
stand-alone object definitions to have a subtype indication ('String(1..5)')
rather than just a subtype mark ('String_5'), and I cannot see any obvious
reason why the proposed 'array profile' shouldn't allow subtype indications.

| The only bad issue I still see is that its
| probably going to need a dope vector from hell to keep track of all the
| contraints of all its elements. But this isn't any different than the
| current situation with my array of string pointers.

An Ada implementation's internal representation of the profile would simply
be an array of whatever the implementation uses for stand-alone object's
subtypes (possibly requiring one extra level of indirection). This may be
considered to be a 'dope vector from Hell', but it would be hidden from the
programmer, and, since in practice most subtypes are static anyway, it would
often be optimised away anyway.

| I'm starting to like this proposal.

Thank you!

| I think the syntax does need still some work. For instance, can variant
| records be components too? What would one of those declarations look
| like? How about classwide tagged types?

I agree wholeheartedly. I am unsatisfied by both the syntax and the
nomenclature as I have it at present in my proposal. Even the name 'ragged
array' is not really appropriate. I would be very grateful for suggestions
of improvements.

| Also, if we do this, wouldn't the constrained subtype restriction on
| record fields start to look a bit restrictive?

Firstly, the specific rule is that record components must be definite,
rather than unconstrained (they can be unconstrained elementary types, each
type of which is assumed to occupy the same amount of memory regardless of
constraint).

Secondly, it is the purpose of record discriminants to parametise the
subtypes of record components. My proposal for ragged arrays is essentially
to provide a way (the 'array profile') to parametise the subtypes of the
components of an array. It is necessary that the subtypes of every component
of any definite array or record subtype is definite, since otherwise, in
general, it would be impossible to know how much memory to allocate for the
component (and grossly wasteful to allocate enough for any possible value).

Now, if a component in a record were allowed to have an indefinite subtype,
how could that subtype get constrained (to make it definite)? There would be
no point in inventing some mechanism to do so when such a mechanism already
effectively exists: discriminants.

-------------------------------------
Nick Roberts
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos
-------------------------------------

Re: Ragged Array Proposal

[Robert Dewar]

In article <37eaa24b@eeyore.callnetuk.com>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> With the greatest respect, it is perhaps easy for those of you
> who are steeped in knowledge of the language to overlook this
> (and there can be no arguing that STT is steeped in knowledge
> of the language!).

Of *course* we understand that it is easier to construct ragged
arrays if you have a specific feature for doing this. That is
precisely why this was discussed extensively during the language
design.

If it was NOT the case that your suggestion would make at least
some cases easier to program, then you would not bother to make
the suggestion, but the mere existence of such cases does not
justify the addition.

In this particular case, there is a significant implementation
burden (wait till you are really working on your Ada compiler
to appreciate that :-). In particular, getting the debugger to
understand this completely new type would be significant work.

What we decided during the design process was that the added
functionality was simply not worth the added implementation
burden. I see nothing that has changed this decision, or that
makes it worth while to reopen the discussion at this stage,
and the decision seems reasonable to me (then and now).

> Try telling a C++ programmer that, in Ada, they have to
declare an access
> type, and then repeat the "new String'("xyz")" incantation for
every string,
> just to declare an array of strings, and they might be likely
to say "Ada?
> No thanks, I'll stick to C++, if you don't mind."

Again, if someone really chooses a language based on the
perceived simplicity of one element of the language, there
is nothing much you can do, because when you compare two
languages there will always be cases where one is easier
than the other.

Incidentally, remember that C++ does not have strings, only
string pointers. If it is the syntax that is bothering you,
define a unary plus appropriately, so you can write:

  x : array (1 .. 3) of S := (+"how", +"about", +"that");



>
> Frankly, the pre-allocation trick (which is fine and dandy in
all other
> respects) only makes things worse from this point of view
(simplicity for
> the programmer), since it makes it looks like something is
happening
> (dynamic allocation) which is actually not.

The recommended way of doing things does not involve any
allocators .... just the use of 'Access which is like & in C.


> I would agree that ragged arrays commit the same sin, but I
> would say less so.

No, more so, the recommended approach with 'Access is 100%
WYSIWYG.

> To those who argue that adding ragged arrays would add
unnecessary
> complexity to the language, my reply is not to confuse
complexity of the
> language with complexity of _using_ the language.

Simplicity/Complexity has many aspects, in this case the
complexity of both definition and implementation is
considerable. I think the usage is not easy either, have
you given any thought to how you would apply rep clauses
to this type? what component_size would mean? whether this
is a new formal type for generics (that's just 3 of dozens
of semantic issues of complexity for the user that leap
to mind).



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

Re: Ragged Array Proposal

[Wes Groleau]

> In this particular case, there is a significant implementation
> burden (wait till you are really working on your Ada compiler
> to appreciate that :-). In particular, getting the debugger to
> understand this completely new type would be significant work.

In the cases of gdb and Apex Duo, where the same debugger understands
both C and Ada, then the debugger should be able to understand

   char *fruits[] = { "apple", "orange", "pear" };

So how much work would it be to handle an Ada syntax that has the
same underlying implementation?

Of course, if the answer is "not much" there's still the question
of whether the value is worth the addition to the language.  I'm
somewhat in favor of the capability (I have yet to look at the
proposed syntax).

The loudest complaints I hear from C-sick folks (who've seen Ada 83 
but never heard of Ada.Strings.* or Interfaces.C) concerns Ada's 
alleged lack of string capabilities.

Re: Ragged Array Proposal

[Robert Dewar]

In article <37EBD2F3.E1E32672@ftw.rsc.raytheon.com>,
  Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> > In this particular case, there is a significant
implementation
> > burden (wait till you are really working on your Ada
compiler
> > to appreciate that :-). In particular, getting the debugger
to
> > understand this completely new type would be significant
work.
>
> In the cases of gdb and Apex Duo, where the same debugger
understands
> both C and Ada, then the debugger should be able to understand
>
>    char *fruits[] = { "apple", "orange", "pear" };
>
> So how much work would it be to handle an Ada syntax that has
the
> same underlying implementation?


Oops, I got mixed up, and thought that Nick had written this,
so please ignore my suggestion of implementing a debugger (that
was intended for Nick :-)

Wes, if you are seriously proposing that the ragged arrays
be implemented with a storage structure identical to that used
for fruits above, then you have suddenly enormously increased
the implementation burden.

That's because the C structure depends on the notion of simple
machine addresses that point to a null terminated string.

This means you have to introduce a whole new concept at both
the Ada semantic level (strings that are not allowed to contain
the null character), and at the implementation level (string
pointers with implicit bounds that are incompatible with normal
pointer-to-unconstrained).

It's doable, I suppose, but you have enormously increased the
complexity of the proposal, probably unintentially (that's the
trouble in language design, things that seem so simple and
straightforward turn out to be much more messy than you think).

Robert


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

Re: Ragged Array Proposal

[Robert Dewar]

In article <37EBD2F3.E1E32672@ftw.rsc.raytheon.com>,
  Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> In the cases of gdb and Apex Duo, where the same debugger
understands
> both C and Ada, then the debugger should be able to understand
>
>    char *fruits[] = { "apple", "orange", "pear" };
>
> So how much work would it be to handle an Ada syntax that has
the
> same underlying implementation?

Quite a bit, the storage structure you are proposing for your
ragged arrays is quite different from the structure implied
by the above C structure. Just because it looks a bit similar
to the human eye at the source level is quite irrelevant. You
would need a way of marking the Ada structure (tricky using
standard debugging formats, because there is no analogous
C format at the storage level), and circuitry in the debugger
for interpreting this structure.

I guess you should add a world class debugger to the list of
things you planning to knock off in your spare time one day :-)

> The loudest complaints I hear from C-sick folks (who've seen
Ada 83
> but never heard of Ada.Strings.* or Interfaces.C) concerns
Ada's
> alleged lack of string capabilities.

Anyone can complain about anything, especially when the
complaint is based on willful ignorance (willful here because
any C programmer who wants to find out about the string
capabilities in Ada, which are far more powerful than those
in C of course, can easily do so!)




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

Re: Ragged Array Proposal

[Robert Dewar]

In article <37EA4E91.1D4D1FC@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
  I know at least that the
> Aonix and Green Hills Ada 95 compilers statically allocate and
initialize
> allocators for access-to-constant types.  I haven't checked
GNAT.

Yes, GNAT does the same optimization, it is after all trivial.
It is interesting to note that the original form with allocators
could also be optimized.


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

Re: Ragged Array Proposal

[Robert Dewar]

In article <m3vh922o3u.fsf@vault80.infomatch.bc.ca>,
> The problem with this approach is that the data is duplicated.

It is both in
> the static data area of the program (i.e. the string

constants), and in the
> heap.

The right way to write this is using 'Access on constant
strings, and then the data will not be duplicated. Of course
a compiler might optimize the above case anyway.


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

Re: Ragged Array Proposal

[Robert I. Eachus]

Nick Roberts wrote:

> I seem to get the impression that the cognoscenti consider this particular
> idea worthless. I am perfectly serious about it, however; I am completely
> convinced that it would be both workable and valuable (extremely so, in
> fact). I beseech anyone who might be interested to take a serious look; I
> would be delighted to have feedback (_any_ kind of feedback), either to me
> by e-mail or to this newsgroup.
 
   Not worthless, just excessive.  There are already two ways to do what
you seem to want: arrays of Ada.Strings.Unbounded.Unbounded_String, or a
generic
package that does what you want using Controlled types.  If you want to
supply a package like that it would probably be considered, if not for
the next standard, at least to be provided by all implementors.  (And if
you do it before the ARG meeting Monday, it might even get considered
there...)

   Note: I have implemented a slightly more general version of that
package, where my major concern was to provide extensible records. 
Hmmm.  What you want seems to be a generic package with a specification
like:

   with Ada.Finalization;
   generic
     type Index is (<>);
   package Ragged is

     type Element is private with null;
     type Element_Reference is access all Element'Class;
     type Ragged_Array is array (Index range <>) of Element_Reference;
    
     procedure Assign_To(R: in out Ragged_Array; I: in Index, E:
Element);
     function Dereference(R: Ragged_Array; I: Index) return
Element'Class;
   
   private
     -- implemenation defined...
   end Ragged;

   Any comments?

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ragged Array Proposal

[Nick Roberts]

Robert I. Eachus <eachus@mitre.org> wrote in message
news:37EA9A72.594ED8F5@mitre.org...
[...]
|    Not worthless, just excessive.  There are already two ways to do what
| you seem to want: arrays of Ada.Strings.Unbounded.Unbounded_String, or a
| generic
| package that does what you want using Controlled types.

Using Ada.Strings.Unbounded is one of the unappealing alternatives I was
talking about.

To use the fructuous example of another post in this thread, in Ada 95 one
would have to declare:

Fruits: constant array (Positive range <>) of Unbounded_String :=
    (To_Unbounded_String("Apple"),
     To_Unbounded_String("Orange"),
     To_Unbounded_String("Pear"),
     ...);

This technique suffers from the same heavy syntax of the allocator
technique, and while it saves having to explicitly declare an access type,
it's almost certain to have an implementation that involves dynamic
allocation (together with the further baggage of a controlled type). A very
clever optimiser might be able to perform pre-allocation (as mentioned in
other posts in this thread), but I suspect that most Ada compilers, in
reality, would not.

An overloading of "+" could be declared to slim down the declaration of each
component, but this does not resolve the inefficiency.

Similar comments apply to the use of Ada.Strings.Bounded. In this case,
there is the same syntactic clumsiness (with the addition of a generic
instantiation), and also inefficiency (albeit wasted memory rather than
dynamic allocation).

|    Note: I have implemented a slightly more general version of that
| package, where my major concern was to provide extensible records.
| Hmmm.  What you want seems to be a generic package with a specification
| like:
|
|    with Ada.Finalization;
|    generic
|      type Index is (<>);
|    package Ragged is
|
|      type Element is private with null;
|      type Element_Reference is access all Element'Class;
|      type Ragged_Array is array (Index range <>) of Element_Reference;
|
|      procedure Assign_To(R: in out Ragged_Array; I: in Index, E:
| Element);
|      function Dereference(R: Ragged_Array; I: Index) return
| Element'Class;
|
|    private
|      -- implemenation defined...
|    end Ragged;
|
|    Any comments?

This kind of package really only 'wraps up' the techniques using access
values or fixed-size buffers; it doesn't resolve the underlying problems.
Use of this kind of package will still suffer from the heavy syntax (in the
above case, a generic instantiation, a tagged type derivation, a declaration
of an object, and then several calls to a procedure!), and the inefficiency
of using dynamic allocation or fixed-size buffers.

| If you want to
| supply a package like that it would probably be considered, if not for
| the next standard, at least to be provided by all implementors.  (And if
| you do it before the ARG meeting Monday, it might even get considered
| there...)

I would be delighted for the ARG to consider my ragged array proposal, if it
comes within the group's remit. I will endeavour to get some or all of the
'Changes to the RM' section written before Monday.

I want to illustrate what I think is the key advantage of ragged arrays. In
the examples in my proposal, I declare an abstract type Figure, and a ragged
array type Figure_Array, and then various concrete types derived from
Figure. I then declare a record type Compound_Figure with a component of
this ragged array type, and finally I declare a subtype of this record type,
Double_Triangle.

I don't specify the components for the concrete figure types, but suppose
the type Circle has components for a radius and a centre (on flat plane),
and that there is a Label figure which has components for a Wide_Character
and a centre. Furthermore, suppose we declare another subtype:

subtype Telephone_Button is Compound_Figure(2)(Circle,Label);

A value could be assigned to an object, Star say, of the Telephone_Button
subtype as follows:

Star := (2, (15,(23,47), ('*',(23,47)));

Now, consider how such a record subtype could be implemented in Ada 95. One
possibility is:

type Figure_Access is access all Figure'Class;

type Figure_Array is array (Positive range <>) of Figure_Access;

type Compound_Figure (Length: Natural) is new Figure with
    record
        Constituents: Figure_Array(1..Length);
         ...
    end record;

Now consider declaring the subtype Telephone_Button. This can done with:

subtype Telephone_Button is Compound_Figure(2);

But note how the subtypes of the components of the array cannot be
constrained. Being able to impose such a constraint would be a valuable
technique in many situations.

Now consider assigning a value to an object of this subtype. We can either
use an allocator:

Star := (2, new Circle(15,(23,47)), new Label('*',(23,47)));

Or we can used aliased objects:

TBC: constant aliased Circle := (15,(23,47));
SBL: constant aliased Label := ('*',(23,47));

Star := (2, TBC'Access, SBL'Access);

I think both of these methods are less preferable to the ragged array. It's
obvious that the syntax is less concise. What may not be so obvious,
however, but which, I am convinced, is of great significance, is that the
above Ada 95 version (or, indeed, any Ada 95 alternative) will generally be
less efficient, in terms of memory used and often execution speed too, and
there's _no way around it_ except kludges.

It's unfortunate that it is difficult to come up with a realistic example
that isn't either too complicated for an example, or simply dismissed with a
wave of the hand as being unrealistic. But I am convinced that this is a
problem that could be critical for certain applications. Suppose an
application had extremely limited memory, for example (e.g. an embedded
controller), or needed to store a huge number of items of subtypes similar
to Telephone_Button; the memory saving from the use of ragged arrays could
be significant, or even critical.

-------------------------------------
Nick Roberts
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos
-------------------------------------

Re: Ragged Array Proposal

[Robert Dewar]

In article <37ebb120@eeyore.callnetuk.com>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> Using Ada.Strings.Unbounded is one of the unappealing
alternatives I was
> talking about.


The trouble with this thread is that it is just replaying an
old discussion with little new being added on both sides. I
guess that is somewhat inevitable as new people begin to think
about things, often without digging through the past :-)

Nick, you might want to dig up some of the old discussions
and proposals on ragged arrays ...


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

Re: Ragged Array Proposal

[Robert Dewar]

In article <37ebb120@eeyore.callnetuk.com>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> Using Ada.Strings.Unbounded is one of the unappealing
alternatives I was
> talking about.


The trouble with this thread is that it is just replaying an
old discussion with little new being added on both sides. I
guess that is somewhat inevitable as new people begin to think
about things, often without digging through the past :-)

Nick, you might want to dig up some of the old discussions
and proposals on ragged arrays ...


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

Re: Ragged Array Proposal

[Robert Dewar]

In article <37ebb120@eeyore.callnetuk.com>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:

> Fruits: constant array (Positive range <>) of Unbounded_String
:=
>     (To_Unbounded_String("Apple"),
>      To_Unbounded_String("Orange"),
>      To_Unbounded_String("Pear"),
>      ...);
>
> This technique suffers from the same heavy syntax of the
allocator
> technique,

Well as I noted in an earlier message, the "light" syntax of
C hides a lot of sins, it is always puzzling to people who
are using C at first, that they cannot declare the Fruits
array as in our example, and then say


   if (Fruits [j] == "abc") ...

of course they *can* say it, it is perfectly legal and well
defined in C, it just does not do what the programmer expects
(generally the result will be false).

If you really get so upset by reading To_Unbounded_String, then
replace it with a unary "+" as in my previous example (I
actually wanted the unary "+" in the standard here, but
that proposal did not attract enough support). Indeed both
Jean Ichbiah and I have always liked the idea of using unary
plus as a quietish, but still explicit, conversion operator,
and we both pushed for adding one extra unary operator (obvious
choice the pillow or currency conversion symbol) which would
have no predefined meaning, but would be specifically intended
as a conversion operator of this kind, but that again did not
attract enough support.

> and while it saves having to explicitly declare an access
> type, it's almost certain to have an implementation that
> involves dynamic allocation (together with the further baggage
> of a controlled type).

Sure, but you would be surprised what a large percentage of
string processing stuff is quite happy with such overhead
(think of SPITBOL, and even Java).

> A very clever optimiser might be able to perform
> pre-allocation (as mentioned in
> other posts in this thread), but I suspect that most Ada
compilers, in
> reality, would not.

Waste of time I would think ...


Robert Dewar


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

Re: Ragged Array Proposal

[Ted Dennison]

In article <37ebb120@eeyore.callnetuk.com>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> To use the fructuous example of another post in this thread, in Ada 95
> one would have to declare:
>
> Fruits: constant array (Positive range <>) of Unbounded_String :=
>     (To_Unbounded_String("Apple"),
>      To_Unbounded_String("Orange"),
>      To_Unbounded_String("Pear"),
>      ...);

Actually, that hides a bit of information. If I were writing it, it
would look more like:

Fruits : constant array (Positive range <>) of
Ada.Strings.Unbounded.Unbounded_String :=
   (Ada.Strings.Unbounded.To_Unbounded_String("Apple"),
    Ada.Strings.Unbounded.To_Unbounded_String("Orange"),
    Ada.Strings.Unbounded.To_Unbounded_String("Pear"),
    ...);

> I would be delighted for the ARG to consider my ragged array
> proposal, if it comes within the group's remit. I will endeavour to

While I'm beginning to think the idea may have merit, I think it would
be too drastic of a change to even think of retroactively incorporating
into the current standard. If it is considered at all, it should be for
a 20xx language revision.

--
T.E.D.


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

Re: Ragged Array Proposal

[Pascal Obry]

> 
> Actually, that hides a bit of information. If I were writing it, it
> would look more like:
> 
> Fruits : constant array (Positive range <>) of
> Ada.Strings.Unbounded.Unbounded_String :=
>    (Ada.Strings.Unbounded.To_Unbounded_String("Apple"),
>     Ada.Strings.Unbounded.To_Unbounded_String("Orange"),
>     Ada.Strings.Unbounded.To_Unbounded_String("Pear"),
>     ...);
> 

Well Ada.Strings.Unbounded is a package that has been designed to
be used with a use clause. Look above at all the redundant infos. Really
I think that a use in this case is just nice.

Pascal.

Re: Ragged Array Proposal

[Ted Dennison]

In article <01bf0919$67bbb350$022a6282@dieppe>,
  "Pascal Obry" <pascal_obry@csi.com> wrote:
>
> >
> > Actually, that hides a bit of information. If I were writing it, it
> > would look more like:
> >
> > Fruits : constant array (Positive range <>) of
> > Ada.Strings.Unbounded.Unbounded_String :=
> >    (Ada.Strings.Unbounded.To_Unbounded_String("Apple"),
> >     Ada.Strings.Unbounded.To_Unbounded_String("Orange"),
> >     Ada.Strings.Unbounded.To_Unbounded_String("Pear"),
> >     ...);
> >
>
> Well Ada.Strings.Unbounded is a package that has been designed to
> be used with a use clause. Look above at all the redundant infos.

There is no "redundant info" above, unless you count the redundant info
that the designers of the unbounded string package purposely put in
there. :-)

But that's not the issue here. We are talking about presenting an
example comparing the syntactic weight of the current approach to that
of a proposed approach. Unless you include the "use
Ada.Strings.Unbounded;" statement in your example, then I argue that you
*must* write the example this way. As others have pointed out, you can
further shorten (and thus hide away) some of the syntax using renames
clauses and unary operators. The fact that you can use tricks to hide
some of the inherent ugliness in the above approach is beside the point.
The fact that folks would object to someone *not* using such tricks
practicly makes Nick's point for him.

--
T.E.D.


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

Re: Ragged Array Proposal

[Robert Dewar]

In article <7sqo26$b5t$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> But that's not the issue here. We are talking about presenting
an
> example comparing the syntactic weight of the current approach
to that
> of a proposed approach. Unless you include the "use
> Ada.Strings.Unbounded;" statement in your example, then I
argue that you
> *must* write the example this way.


It is not a "trick" to use a USE clause here but just good
usage, and certainly not something unfamiliar to a C programmer
who would expect to use a #include for a header in a similar
situation.

If you like the "+" notation, then of course you would with
and use (or even use type :-) the package that defined and
reexported the adjusted string stuff. I can't imagine anyone
writing the fully expanded names here, so implying that this
is reasonable code is definitely misleading.

I do understand that some people operate in environments that
forbid USE clauses, but such environments which mandate the
use of a subset of Ada are not the source of inspiration about
what the best style is when using the *whole* Ada language.

Almost anything carried to extremes is a bad thing. Almost
everyone would agree that completely eliminating use clauses
or mandating their use everywhere would both be a bad idea.
So for most people we find a happy medium, and for most people

Ada.Strings.Unbounded.To_Unbounded_String

repeated over and over is not the way to do things!


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

Re: Ragged Array Proposal

[Geoff Bull]

Robert Dewar wrote:
> 

> So for most people we find a happy medium, and for most people
> 
> Ada.Strings.Unbounded.To_Unbounded_String
> 
> repeated over and over is not the way to do things!

To right!

Re: Ragged Array Proposal

[Robert Dewar]

In article <7so0i4$d8j$1@nnrp1.deja.com>,
> Fruits : constant array (Positive range <>) of
> Ada.Strings.Unbounded.Unbounded_String :=
>    (Ada.Strings.Unbounded.To_Unbounded_String("Apple"),
>     Ada.Strings.Unbounded.To_Unbounded_String("Orange"),
>     Ada.Strings.Unbounded.To_Unbounded_String("Pear"),
>     ...);

I can't *imagine* why you think that obviously redundant
qualification makes your code more readable. It is obvious
that the names in Unbounded have been chosen to be appropriate
for use with USE clauses (otherwise the name would have been
something like From_String, without the Unbounded in the name).

I perfectly understand the thought that generally likes to avoid
USE clauses, but I must say when people carry this to absurd
extremes like the above, it is hard to understand the thought
process involved.

Clearly no one would reuse the name To_Unbounded_String in a
user defined package (if they had any sense at all), so the
unqualified name is perfectly clear in practice.

Certainly we cannot buy an argument for a feature which goes
like this:

1. I refuse to use USE clauses

2. Therefore some code I have to write looks awful

3. Therefore I need some special feature in the language to
allow me to do this in some special way

:-)

Of course in this particular case, even the simple name
To_Unbounded_String is heavy, which is why the idea of a light
conversion operator makes good sense (the unary "+" suggestion).


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