Scope of revision

Rationale for Ada 2005: Introduction

ENG

2. Scope of revision

@ The changes from Ada 83 to Ada 95 were large. They included several major new items such as

polymorphism through tagged types, class-wide types and dispatching,
the hierarchical library system including public and private child packages,
protected objects for better real-time control,
more comprehensive predefined library, especially for character and string handling,
specialized annexes such as those for system programming, real-time, and numerics.

@ By contrast the changes from Ada 95 to Ada 2005 are relatively modest. Ada 95 was almost a new language which happened to be compatible with Ada 83. However, a new language always brings surprises and despite very careful design things do not always turn out quite as expected when used in earnest.

@ Indeed, a number of errors in the Ada 95 standard were corrected in the Corrigendum issued in 2001 [2] and then incorporated into the Consolidated Ada Reference Manual [3]. But it was still essentially the same language and further improvement needed to be done.

@ Technically, Ada 2005 is defined as an Amendment to rather than a Revision of the Ada 95 standard and this captures the flavour of the changes as not being very extensive.

@ In a sense we can think of Ada 2005 as rounding out the rough edges in Ada 95 rather than making major leaps forward. This is perhaps not quite true of the Real-Time Systems annex which includes much new material of an optional nature. Nevertheless I am sure that the changes will bring big benefits to users at hopefully not too much cost to implementors.

@ The scope of the Amendment was guided by a document issued by WG9 to the ARG in September 2002 [1]. The key paragraph is:

@ "The main purpose of the Amendment is to address identified problems in Ada that are interfering with Ada's usage or adoption, especially in its major application areas (such as high-reliability, long-3 lived real-time and/or embedded applications and very large complex systems). The resulting changes may range from relatively minor, to more substantial."

@ Note that by saying "identified problems" it implicitly rejects a major redesign such as occurred with Ada 95. The phrase in parentheses draws attention to the areas where Ada has a major market presence. Ada has carved an important niche in the safety-critical areas which almost inevitably are of a real-time and/or embedded nature. But Ada is also in successful use in very large systems where the inherent reliability and composition features are extremely valuable. So changes should aim to help in those areas. And the final sentence is really an exhortation to steer a middle course between too much change and not enough.

@ The document then identifies two specific worthwhile changes, namely, inclusion of the Ravenscar profile [4] (for predictable real-time) and a solution to the problem of mutually dependent types across two packages (see Section 3.3 below).

@ The ARG is then requested to pay particular attention to

A. Improvements that will maintain or improve Ada's advantages, especially in those user domains where safety and criticality are prime concerns. Within this area it cites as high priority, improvements in the real-time features and improvements in the high integrity features. Of lesser priority are features that increase static error checking. Improvements in interfacing to other languages are also mentioned.
B. Improvements that will remedy shortcomings in Ada. It cites in particular improvements in OO features, specifically, adding a Java-like interface feature and improved interfacing to other OO languages.

@ So the ARG is asked to improve both OO and real-time with a strong emphasis on real-time and high integrity features. It is interesting that WG9 rejected the thought that "design by contract" features should be added to the above general categories on the grounds that they would not be static.

@ The ARG is also asked to consider the following factors in selecting features for inclusion:

Implementability. Can the feature be implemented at reasonable cost?
Need. Do users actually need it? [A good one!]
Language stability. Would it appear disturbing to current users?
Competition and popularity. Does it help to improve the perception of Ada and make it more competitive?
Interoperability. Does it ease problems of interfacing with other languages and systems? [That's the third mention of interfacing.]
Language consistency. Is it syntactically and semantically consistent with the language's current structure and design philosophy?

@ An important further statement is that "In order to produce a technically superior result, it is permitted to compromise backwards compatibility when the impact on users is judged to be acceptable." In other words don't be paranoid about compatibility.

@ Finally, there is a warning about secondary standards. Its essence is don't use secondary standards if you can get the material into the RM itself. And please put the stuff on vectors and matrices from ISO/IEC 13813 [5] into the language itself. The reason for this exhortation is that secondary standards have proved themselves to be almost invisible and hence virtually useless.

@ The guidelines conclude with the target schedule. This includes WG9 approval of the scope of the amendment in June 2004 which was achieved and submission to ISO/IEC JTC1 in late 2005.

Rationale for Ada 2005: Introduction

ENGRUSTOPBACKNEXT

2. Обзор переделок

@ Ада 95 сильно отличалась от Ады 83. Ада 95 включала несколько новых элементов, таких как:

полиморфизм через теговые, надклассовые типы и диспетчеризацию;
иерархическую библиотечную систему, включая публичные и приватные дочерние пакеты;
защищенные объекты для лучшего управления в реальном времени;
более всестороннюю стандартную библиотеку для символьной и строковой обработки;
специализированные приложения для системного программирования, работы в реальном времени и обработки численных данных.

@ В отличие от этого изменения между Адой 95 и Адой 2005 относительно скромны. Ада 95 была практически новым языком, который, можно считать, только по случайности оказался совместим с Адой 83. Однако, новый язык всегда приносит неожиданности, и несмотря на очень осторожный дизайн, многие вещи на практике оказались не совсем такими как предполагалось в начале.

@ Действительно, многие ошибки в стандарте ada были исправлены в Corrigendum (Пересмотре), выпущенным в 2001 [2], который затем попал в Consolidated Ada Reference Manual (Объединенное Справочное описание Ады) [3]. Но это был все еще по существу тот же самый язык, и дальнейшее усовершенствование должно было быть сделано.

@ Технически, язык Ада 2005 определен как Поправка, а не Пересмотр стандарта ada и это отражает характер изменений, как не являющихся кардинальными.

@ В некотором смысле, мы можем считать Аду 2005 как исправление шороховатостей ada, а не как некий качественный скачок вперед. Это возможно, не совсем верно для приложений систем реального времени, которые включает много нового материала дополнительной природы. Однако, я уверен, что изменения принесут большие пользы пользователям и, мы надеемся, не слишком много затрат разработчикам компилятора.

@ В обзоре Поправки, выпущенным WG9 к ARG в сентябре 2002 [1] заявляется что:

@ "Основная цель Поправки состоит в том, чтобы исправить обнаруженные проблемы с которыми сталкиваются приложения Ады, особенно в её главных прикладных областях (таких как высоконадежные, долгоживущие встраиваемые приложения реального времени и очень большие сложные системы). Получающиеся изменения могут расположиться в порядке от относительно незначительных к более существенным."

@ Обратите внимание, что фраза "обнаруженные проблемы" неявно отклоняет главную модернизацию, которая произошла с Адой 95. Фраза в круглых скобках привлекает внимание к областям, где у Ады есть главное рыночное приемущество. Ада заняла важную нишу в критических по отношению к безопасности областях, которые почти неизбежно имеют внедренную природу в реальном времени. Но Ада успешно применяется и в очень больших системах, где высокая надежность и итегрированность чрезвычайно важны. Таким образом, изменения должны стремиться помогать в этих областях. И окончательное пожелание - избежать крайностей между слишком большим изменением и незначительным.

@ Документ идентифицирует два существенных изменения, а именно, включение конфигурации Ravenscar [4] (особый режим реального времени) и решение проблемы взаимно зависимых типов из разных пакетов (см. Раздел 3.3 ниже).

@ ARG требует обратить особое внимание на:

Усовершенствования, которые поддерживают или улучшают преимущества Ады, особенно в тех областях где безопасность и критичность - главная цель. Исходя из этого первоочередной задачей считается усовершенствование возможностей в реальном времени и усовершенствование возможностей целостности и стабильности. Меньшим приоритетом считаются возможности, которые увеличивают статическую проверку ошибок. Также упоминаются усовершенствования в области интерфейсов и связь с другими языками.
Усовершенствования, которые исправят недостатки Ады. Они включают усовершенствование возможностей OOП, добавляя возможности java-подобного интерфейса и улучшенный интерфейс с другими языками OOП.

@ Таким образом, ARG просит улучшить и OOП и работу в реальном времени с сильным акцентом на целостность в реальном времени. Интересно, что WG9 отклонил мысль, что "дизайн в соответствии с контрактом" особенности должен быть добавлен к вышеупомянутым общим категориям на том основании, что они не были бы статическими.

@ ARG также просит обратить внимание следующие факторы в выборе включения изменений:

Реализуемость. Возможность может быть осуществлена за разумную стоимость.
Потребность. Пользователи должны действительно нуждаться в этом.
Языковая приемственность. Изменения не должны распугать текущих пользователей.
Соревнование и популярность. Необходимо улучшить восприятие Ады и сделать её более конкурентоспособной.
Функциональная совместимость. Ослабить проблемы интерфейсной связи с другими языками и системами.
Языковая последовательность. Синтаксическая и семантическая совместимость с текущей структурой языка и философией дизайна.

@ Важный следующий вопрос - "Чтобы достичь технически превосходного результата, разрешено поставить под угрозу совместимость, когда воздействие на пользователей, как предполагается, является приемлемым". Другими словами, не впадать паранойю совместимости в ущерб эффективности.

@ Наконец, есть упоминание о вторичных стандартах. Его суть, не использовать вторичные стандарты, если Вы можете получить материал из RM непосредственно. И пожалуйста, помещайте материал по векторам и матрицам от ISO/IEC 13813 [5] в язык непосредственно. Причина для этого увещевания в том, что вторичные стандарты оказались почти невидимыми и, следовательно, фактически бесполезными.

@ Рекомендации заканчиваются целевым списком. Он включает одобрение WG9 поправки области видимости в июне 2004, которая была достигнута и представлена к рассмотрению ISO/IEC JTC1 в конце 2005.

ENG RUS

TOP BACK NEXT

2010-10-24 00:26:52

. .