Ada_Ru форум

Обсуждение языка Ада

small questions-ics...

Оставить новое сообщение

Сообщения

urisska
small questions-ics...
2003-07-04 11:54:59

hi!

 

сорри, если не по-делу, но тут такой теоритический вопрос:

 

почему в ада не ввели _тип_ package? - как задачи?,- типа:

 

task [type] ident ...eklmn... - ето есть

 

package [type] ident ...eklmn... - уже нема :-(

 

причем на эту несуразность ( нюанс? ) указывалось и у Джехани

(Язык программирования Ада) и еще ранее Джехани дает ссылку на

статью 1980 года, где говорилось об этом - и вот 95 - и тоже нет!

в чем причина? task type ведь есть!

 

тогда при этом говорить об абстрактом типе данных через пакеты не совсем корректно: - в аде пакеты реализуют абстрактные данные, но не абстрактный _тип_ данных ( массив пакетов не получишь)

 

ps:вопрос под впечатлением п.2.3.2. _Адского_ программирования...:-)

Datiy Yuriy wrote:

> hi!

>

> сорри, если не по-делу, но тут такой теоритический вопрос:

 

ну почему же не по делу - сейчас пободаемся!

 

> почему в ада не ввели _тип_ package? - как задачи?,- типа:

>

> task [type] ident ...eklmn... - ето есть

>

> package [type] ident ...eklmn... - уже нема :-(

 

А зачем? Что это дало бы хорошего?

 

> причем на эту несуразность ( нюанс? ) указывалось и у Джехани

> (Язык программирования Ада) и еще ранее Джехани дает ссылку на

> статью 1980 года, где говорилось об этом - и вот 95 - и тоже нет!

>

> в чем причина? task type ведь есть!

 

Ну, зачем task type, и зачем массивы задач, и зачем динамическое

порождение задач - это понятно. Зачем все это в случае пакетов -

мне лично непонятно абсолютно. А вот какие это сложнисти добавит и в определение

языка, и в реализацию - догадываюсь.

"Sergey I. Rybin" писал(а):

 

Datiy Yuriy wrote:

hi!

 

сорри, если не по-делу, но тут такой теоритический вопрос:

 

ну почему же не по делу - сейчас пободаемся!

 

 

не, бодаться не хочу - хочу понять

почему в ада не ввели _тип_ package? - как задачи?,- типа:

 

task [type] ident ...eklmn... - ето есть

 

package [type] ident ...eklmn... - уже нема :-(

 

А зачем? Что это дало бы хорошего?

 

 

читаю дальше: ч2п3.1 - реализация стека и очереди

при реализации как тип_пакет незачем передавать данные_стек или

данные_очередь

в вызываемые методы - для каждого нового стека все они внутрях сидят а если в пакете определяется не одни данные, а 2.3.4...?

их всех передавать при вызове методов (или хотя бы нухных для данного метода)?

непонятно...:-(

 

причем на эту несуразность ( нюанс? ) указывалось и у Джехани

(Язык программирования Ада) и еще ранее Джехани дает ссылку на

статью 1980 года, где говорилось об этом - и вот 95 - и тоже нет!

в чем причина? task type ведь есть!

 

Ну, зачем task type, и зачем массивы задач, и зачем динамическое порождение задач - это понятно. Зачем все это в случае пакетов -

 

зачем это в случае пакетов - куча книжек, начиная со страуструпа, etc... или даже намного ранее...

 

мне лично непонятно абсолютно. А вот какие это сложнисти добавит и в определение

языка, и в реализацию - догадываюсь.

 

 

так - сорри - поделитесь, хотя бы основными причинами

я лично их не вижу - почему и спрашиваю

читаю дальше: ч2п3.1 - реализация стека и очереди

при реализации как тип_пакет незачем передавать данные_стек или

данные_очередь

в вызываемые методы - для каждого нового стека все они внутрях сидят

а если в пакете определяется не одни данные, а 2.3.4...?

их всех передавать при вызове методов (или хотя бы нухных для данного

метода)?

непонятно...:-(

А что, это имеющимися средсвами не достигается? Тут, конечно,

детальную постановку задачи смотреть надо...

 

зачем это в случае пакетов - куча книжек, начиная со страуструпа, etc...

или даже намного ранее...

 

Ну, что из идей того же Страуструпа выросло - мы все хорошо

видим :)))

 

так - сорри - поделитесь, хотя бы основными причинами

я лично их не вижу - почему и спрашиваю

 

Ну, начать с того, что я с трудом себе представляю тип-пакет.

Можно более-менне законченный содержательный пример?

Sergey I. Rybin wrote:

читаю дальше: ч2п3.1 - реализация стека и очереди

при реализации как тип_пакет незачем передавать данные_стек или

данные_очередь

в вызываемые методы - для каждого нового стека все они внутрях сидят

а если в пакете определяется не одни данные, а 2.3.4...?

их всех передавать при вызове методов (или хотя бы нухных для данного

метода)?

непонятно...:-(

 

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

 

Что получаем?

 

Объединение определений типов, констант/переменных, набор подпрограмм, набор ненастроенных generic-ов.

 

Какими свойствами это можно наделить? Пакет остается "статичным" объектом? Или получаем право создавать экземпляры пакета?

 

Если создаем экземпляры, то как определяем операции инициализации/копирования/уничтожения?

 

Если создаем экземпляры, то какой смысл имеет настройка generic-ов?

 

Имеем ли право "наследовать" пакеты?

 

Если да, то как вводится понятие абстрактности, виртуальности?

 

 

Без ответов на эти вопросы первое впечатление от вопроса - попытка придумать замену классическому понятию класса в C++.

 

При обсуждении удаления одного параметра (собственно объекта, относительно которого производится вызов примитивной подпрограммы) необходимо заметить, что подпрограмма является примитивной даже если это функция возвращающая соответствующий тип. Кроме этого по поводу "точечной нотации" можно отослать к соответствующему AI.

 

А в отношении Страуструпа можно сказать только одно. Спустя много лет он в интервью признался, что целью создания C++ было не столько желание создать новый удобный язык, сколько желание прикрутить к C нечто, что бы позволило на этом потом деньги зарабатывать. Это было опубликовано в одном из журналов "Открытые системы".

 

 

-- Vadim Godunko

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

 

Ну, я примерно это и имел в виду...

 

Что получаем?

 

Не пойми что получаем... Или замучаемся определять,

что именно получилось...

Sergey I. Rybin wrote:

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

 

 

Ну, я примерно это и имел в виду...

 

 

Что получаем?

 

 

Не пойми что получаем... Или замучаемся определять,

что именно получилось...

 

Получив огромный урок из просмотренного сегодня фильма Terminator-3, хочу сказать, что главное - не получить то, что получилось в финале.

 

Тем паче, что многие из нас имеют к этому весьма близкое отношение...

 

 

-- Vadim Godunko

"Sergey I. Rybin" писал(а):

 

...

 

зачем это в случае пакетов - куча книжек, начиная со страуструпа, etc... или даже намного ранее...

 

Ну, что из идей того же Страуструпа выросло - мы все хорошо

видим :)))

 

 

o! - мне ужасно не нравится с++ по своим причинам

имнтересно, - а что в нем плохого по-вашему?

(или по общепринятому мнению?)

так - сорри - поделитесь, хотя бы основными причинами

я лично их не вижу - почему и спрашиваю

 

Ну, начать с того, что я с трудом себе представляю тип-пакет.

Можно более-менне законченный содержательный пример?

 

 

ok! - далее...

 

Юрий Датий

Vadim Godunko писал(а):

 

Sergey I. Rybin wrote:

>читаю дальше: ч2п3.1 - реализация стека и очереди

>при реализации как тип_пакет незачем передавать данные_стек или

>данные_очередь

>в вызываемые методы - для каждого нового стека все они внутрях сидят >а если в пакете определяется не одни данные, а 2.3.4...?

>их всех передавать при вызове методов (или хотя бы нухных для данного >метода)?

>непонятно...:-(

 

 

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

 

Что получаем?

 

Объединение определений типов, констант/переменных, набор подпрограмм, набор ненастроенных generic-ов.

 

Какими свойствами это можно наделить? Пакет остается "статичным" объектом? Или получаем право создавать экземпляры пакета?

 

Если создаем экземпляры, то как определяем операции

инициализации/копирования/уничтожения?

 

Если создаем экземпляры, то какой смысл имеет настройка generic-ов?

Имеем ли право "наследовать" пакеты?

 

Если да, то как вводится понятие абстрактности, виртуальности?

 

Без ответов на эти вопросы первое впечатление от вопроса - попытка придумать замену классическому понятию класса в C++.

 

 

по-порядку - сначала пример: ( сразу введем с generic - чтобы часть вопоросов отпала )

 

generic

type TElement is private;

package type TStack is

procedure Pop ( E : out TElement );

procedure Push ( E : in TElement );

function Empty return Boolean;

...

exception: ...

end TStack;

 

все! - вопрос: а где структура стека? - в боди! - и если завтра

структура будет

переделываться с массива/списка/дерева/.../etc на еще что-то - то остальным

модулям даже перекомпилироваться не надо - поскоку меняется токо бодя!, а не спецификация...

далее:

 

...

type StackInt is new TStack ( Integer );

...

VanyaStack := new (StackInt);

VanyaStack.Push (CeloeChislo);

VanyaStack := null; -- eto po povodu delete_object

...

 

далее основной вопрос: а почему собственно так не было сделано ни в 83, ни в 95?

что плохо?

- нарушение строгой типизации

- неэффективная реализация

- затруднение создания надежного генератора кода?

- что-то еще?

ведь с такой структурой работает и generic, child_package, access...

вот это собственно и хотел спросить - почему ето отвергается?

 

--

Vadim Godunko

 

 

--

Датий Юрий

On Saturday 05 July 2003 03:13, Datiy Yuriy wrote:

[skipped]

по-порядку - сначала пример: ( сразу введем с generic - чтобы часть вопоросов отпала )

 

generic

type TElement is private;

package type TStack is

procedure Pop ( E : out TElement );

procedure Push ( E : in TElement );

function Empty return Boolean;

...

exception: ...

end TStack;

 

А чем не нравится вот это?

-----------------------------------

generic

type Element is private;

package Stacks is

 

type Stack is private;

 

procedure Push(E:Element);

function Pop return Element;

procedure Empty;

 

end Stacks;

----------------------------------

Затем используем:

 

--инстанциируем пакеты,

--каждый раз создается новая копия

package Stack1 is new Stacks(Integer ); -- например

package Stack2 is new Stacks(Integer );

package Stack3 is new Stacks(Integer );

-- поскольку все пакеты инстанциируются с одним типом,

-- добавлять use Stack?; бессмысленно

 

-- теперь просто

Stack1.Push(1);

Stack2.Pop; -- в данном случае raises exception,

-- который я не определил для краткости...

 

Конечно создание таких стеков в цикле с сохранением в массиве (например) потребует некоторой изобретательности, но думать сейчас лень :).

 

Этот пример подходит для ситуации, когда стек пишется раз и о нем благополучно забывается, как правило в связи с некритичностью его эффективности. Если же нужен более полный контроль и/или возможность расширять пакет, то почему бы не сделать как положено:

 

--------------

 

generic

type Element is private;

package Stacks is

 

type Stack is abstract limited tagged null record;

-- можно private вместо null record, но в данном случае бессмысленно -- можно также убрать limited, но тогда придется переопределять равенство -- и делать тип controlled

 

procedure Push(S : in out Stack; E:Element);

function Pop (S : Stack) return Element;

function Empty return Stack;

 

end Stacks;

 

Затем соответственно определяем конкретные реализации...

После используем Stack'Class по мере надобности, например:

 

procedure Convert(from : in Stack'Class; to : out Stack'Class)... --конвертирует один тип стека в другой..

 

George

Прошу прощения за ломанное форматирование в прошлом email'е. Попробую переслать еще раз, боюсь только что связанно это было с тем что yahoo groups не справляются без полного CR LF :(.

 

On Saturday 05 July 2003 19:28, George Shapovalov wrote:

On Saturday 05 July 2003 03:13, Datiy Yuriy wrote:[skipped]> по-порядку - сначала пример: ( сразу введем с generic - чтобы часть

вопоросов отпала

)>> generic

type TElement is private;

package type TStack is> procedure

Pop ( E : out TElement );

procedure Push ( E : in TElement );

function

Empty return Boolean;

...

exception: ...

end TStack;

 

А чем не нравится вот это?

 

-----------------------------------

generic

type Element is private;

package Stacks is

procedure Push(E:Element);

function Pop return Element;

procedure Empty;

end Stacks;

----------------------------------

 

Затем используем:

 

--инстанциируем пакеты,

--каждый раз создается новая копия

package Stack1 is new Stacks(Integer ); -- например

package Stack2 is new Stacks(Integer );

package Stack3 is new Stacks(Integer );

-- поскольку все пакеты инстанциируются с одним типом,

-- добавлять use Stack?; бессмысленно

 

-- теперь просто

Stack1.Push(1);Stack2.Pop;

-- в данном случае raises exception,

-- который я не определил для краткости...

 

Конечно создание таких стеков в цикле с сохранением в массиве

(например)потребует некоторой изобретательности, но думать сейчас лень :). Этот пример подходит для ситуации, когда стек пишется раз и о нем благополучно забывается, как правило в связи с некритичностью его эффективности.Если же нужен более полный контроль и/или возможность расширять пакет, то почему бы не сделать как положено:

 

--------------

generic

type Element is private;

package Stacks is

type Stack is abstract limited tagged null record;

-- можно private вместо null record, но в данном случае бессмысленно -- можно также убрать limited, но тогда придется переопределять равенство -- и делать тип controlled

procedure Push(S : in out Stack; E:Element);

function Pop (S : Stack) return Element;

function Empty return Stack;

end Stacks;

 

Затем соответственно определяем конкретные реализации...

После используем Stack'Class по мере надобности, например:

 

procedure Convert(from : in Stack'Class; to : out Stack'Class);

--конвертирует один тип стека в другой..

 

George

Меня собственно интересовало следующее (допустимо и в Ada83 и в Ada95):

 

package type Stack is

 

procedure Push (Item : Item_Type);

 

generic

with procedure Action (Item : in Item_Type;

Quit : in out Boolean);

procedure Visit;

 

end Stack;

 

Как теперь будет выглядеть пример использования?

 

 

-- Vadim Godunko

George Shapovalov wrote:

 

...

А чем не нравится вот это?

...

 

 

нравиться, - но вопрос в другом:

все это я знаю, решал, писал, пишу, etc...

вопорос не в том _КАК_ решить данную(ые) задачу(и),

а не знает ли кто _ПОЧЕМУ_ не сделали package [type]

- почему отвергли это предложение

( которое обсуждалось и предлагалось еще в 1980 )?

 

я пока не вижу отрицательных сторон,- если бы не task [type] - тогда можно было бы говорить о сложности реализации - но task [type] есть!

а положительных моментов куча ( описанных не буду повторяться где...)

George

 

--

Yuriy Datiy

Datiy Yuriy wrote:

 

нравиться, - но вопрос в другом:

все это я знаю, решал, писал, пишу, etc...

вопорос не в том _КАК_ решить данную(ые) задачу(и),

а не знает ли кто _ПОЧЕМУ_ не сделали package [type]

- почему отвергли это предложение

( которое обсуждалось и предлагалось еще в 1980 )?

 

я пока не вижу отрицательных сторон,- если бы не task [type] - тогда

можно было бы говорить о сложности реализации - но task [type] есть!

 

а положительных моментов куча ( описанных не буду повторяться где...)

 

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

 

 

-- Vadim Godunko

Vadim Godunko wrote:

 

Datiy Yuriy wrote:

 

нравиться, - но вопрос в другом:

все это я знаю, решал, писал, пишу, etc...

вопорос не в том _КАК_ решить данную(ые) задачу(и),

а не знает ли кто _ПОЧЕМУ_ не сделали package [type]

- почему отвергли это предложение

( которое обсуждалось и предлагалось еще в 1980 )?

 

я пока не вижу отрицательных сторон,- если бы не task [type] - тогда можно было бы говорить о сложности реализации - но task [type] есть!

а положительных моментов куча ( описанных не буду повторяться где...)

Всё очень просто. Пакет есть абстракция для агрегирования других абстракций. Задача есть абстракция для параллельного исполнения. Отсутствие в языке типа пакет скорее всего обусловлено с одной стороны упрощением семантики языка, а с другой стороны наличием в языке других необходимых для решения подобных задач конструкций (устранением

избыточности, если так можно сказать).

 

 

возможно, - просто я думал может кто-то конкретно знает почему

принимались

те или иные решения, например: приняли access to subroutine, тогда как в Java от этого ушли; введен tagged - а для чего он нужен? (точнее для чего

_слово_ (reserved_word) tagged нужно?), появилось динамическое

связывание

(ушли от жесткой типизации - статического контроля типов) - почему? (не надо

забывать об основном требовании к языку - надежность), etc...

 

вооще конечно было бы не плохо FAQ эдакий специализированный...

 

--

Vadim Godunko

 

--

Yuriy Datiy

Datiy Yuriy wrote:

 

возможно, - просто я думал может кто-то конкретно знает почему

принимались

те или иные решения, например: приняли access to subroutine, тогда как

в Java от этого ушли;

 

В Ada83 от access to subprogram тоже ушли. А вот в Ada95 к нему вернулись. Причины по крайней мере две:

- необходимость интеграции с другими языками (например, классические callbacks из глубин C-шных библиотек в вариации 83 выглядели как System.Address, а в вариации 95 выглядят как access to subprogram with C calling conventions - таким образом типизация ужесточилась);

- необходимость введения понятия remote access to subprogram.

 

 

введен tagged - а для чего он нужен? (точнее для

чего

_слово_ (reserved_word) tagged нужно?),

 

Тоже достаточно просто. Резервное слово tagged обозначает особые правила построения дочерних типов.

 

появилось динамическое

связывание

(ушли от жесткой типизации - статического контроля типов) - почему? (не

надо

забывать об основном требовании к языку - надежность), etc...

 

 

ООП было необходимо языку. Но делать язык полностью объектно-ориентированным тоже не хотелось (вторая причина появления tagged).

 

Динамическое связывание появилось как реализация ООП. Но сказать, что оно не жестко типизированно тоже нельзя. Жесткая типизация осталась, только перешла из разряда проверяемой при компиляции в разряд проверяемой во время исполнения.

 

Если же речь идет о надежности (в особенности аналитическом доказательстве корректности программы), то сущеуствует, например, такая штука как SPARK (или SPARC - не помню). Она является подмножеством языка, и в этом подмножестве тех же динамических вызовов нет (но tagged типы остались!).

 

 

-- Vadim Godunko

я пока не вижу отрицательных сторон,- если бы не task [type] - тогда

можно было бы говорить о сложности реализации - но task [type] есть!

 

Сложность реализации task [type] - ну просто офигенная! Но зато понятно,

чего ради стараться, и зачем тот task [type] не просто полезен - необходим!

 

Полезность package type - сомнительна. Сложностей, скорее всего, будет

немало. Но я вот пока что абсолютно не убежден в том, что package type

не то, что необходим - просто полезен!

 

а положительных моментов куча ( описанных не буду повторяться где...)

 

Извините за наглость, но, боюсь, мало кто из соучастников

полезет по указанным источникам. Так что, если не в лом,

давайте сюда (желательно - простенький) пример, который

показал бы, что package type - вещь и впрямь полезная.

Тот, который был приведен - не убедил абсолютно. Неясно,

зачем там типизация пакета и почему недостаточно просто

настраиваемого пакета.

 

Кстати, и в Аду83, и из Аду 95 не вошла целая куча идеи и механизмов,

предлагавшихся в ходе разработки языка. Тот факт, что

package type рассматривался, да не вошел в окончательную

редакцию, ни в коей мере не есть аргумент в пользу package type

Hello!

 

On Sat, 5 Jul 2003, George Shapovalov wrote:

 

-- теперь просто

Stack1.Push(1);

Stack2.Pop; -- в данном случае raises exception,

-- который я не определил для краткости...

 

Конечно создание таких стеков в цикле с сохранением в массиве (например) потребует некоторой изобретательности, но думать сейчас лень :).

 

Никогда не понимал, почему в ООП принято выносить _параметр_ процедуры в префикс. Чем хуже классическая запись "Push ( Stack1 , 1 ) ;" ?

 

 

Sincerely yours Cyril Sazonov

Cyril Sazonov wrote:

Hello!

 

On Sat, 5 Jul 2003, George Shapovalov wrote:

 

 

-- теперь просто

Stack1.Push(1);

Stack2.Pop; -- в данном случае raises exception, -- который я не определил для краткости...

Конечно создание таких стеков в цикле с сохранением в массиве (например)

потребует некоторой изобретательности, но думать сейчас лень :).

 

 

Никогда не понимал, почему в ООП принято выносить _параметр_ процедуры в

префикс. Чем хуже классическая запись "Push ( Stack1 , 1 ) ;" ?

 

Я тоже считаю, что это - уровень свисточков и звоночков, и только

за-ради этого городить новый огород явно не стоит....

"Sergey I. Rybin" писал(а):

 

...

 

а положительных моментов куча ( описанных не буду повторяться где...)

 

Извините за наглость, но, боюсь, мало кто из соучастников

полезет по указанным источникам. Так что, если не в лом,

давайте сюда (желательно - простенький) пример, который

показал бы, что package type - вещь и впрямь полезная.

Тот, который был приведен - не убедил абсолютно. Неясно,

зачем там типизация пакета и почему недостаточно просто

настраиваемого пакета.

 

 

sorry за непростенькость примера - но реально: один из последних

проектов:

(виртуальная Москва - что-то типа ActiveWorld, если кто-знает:

сервер в интернете + клиенты через интернет работают с этим сервером - "ходят по Москве"... :-)))

Итак, клиент:

TDynamic - исходный обьект - родиетельский - root

( class/package/tagged_record/task_type/etc...)

Наследование от root-a:

- TSelf - для каждого клиента "я сам"

- TClient - другие клиенты

- TBot - движущееся (авто, вертолет,...)

- TPortal - внутрипространственный переход

- TThing - вещи, предметы

- TInformathion - пакет информации

 

У root-a - основные параметры:

X,Y,Z, угол1, угол2, globalID, localID, Name, etc... - переменные + куча функций )

 

у каждого наследника своего добра добавляется(и переменных и функций)

и далее: каждого из 6 типов для каждого клиента может быть

несколько(сколько он на данный момент видит)

например: 1self, 34client, 22bot, 2 portal, 334thing, 7information ____________________________________________________

с package_type решение просматривается само собой

через tagged - ну не совсем красиво и удобно

через task [type] - под 1000 задач у клиента?...:-(((

 

--

Yuriy Datiy

с package_type решение просматривается само собой

 

Попробуйте его _написать_, причем с четким пониманием семантики

package type

 

через tagged - ну не совсем красиво и удобно

 

Пример действительно не сильно простой. Так что не

берусь сравнивать-оценивать.

 

Покуда в виде _кода_ не будет представлен пример

с package type, боюсь, дискуссия дальше данного

места не продвинется

Новое сообщение:
Страницы: 1 2

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти