Re: Ragged Array Proposal

[Robert Dewar <robert_dewar@my-deja.com>]

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.