Ответ на »сообщение 5153« (AVC)
___________________________
>>> В Обероне это как раз вообще не является проблемой (для массивов любой размерности; сравните с Си/Си++).
Сравниваю:

int  a[100];

for(int i = 0; i < sizeof(a); i++)
{
  ...
}

std::vector< int >  a;

for(int i = 0; i < a.size(); i++)
{
  ...
}

Вообще-то разговор был о C#... И разговор был о конструкции foreach и о семантике программы, размазанной по состояниям переменных. Вот Вы написали:

FOR i := 0 TO LEN(a)-1 DO
    ...
END;

И что? Семантика этого выражения выводится из того, какие значения и в каком деапазоне принимает индекс i, а конструкция foreach так и означает, что будут пройдены все элементы множества...

Ответ на »сообщение 5153« (AVC)
___________________________

В Обероне это как раз вообще не является проблемой (для массивов любой размерности; сравните с Си/Си++).
FOR i := 0 TO LEN(a)-1 DO
    ...
END;
или
FOR i := 0 TO LEN(a, 0)-1 DO
    FOR j := 0 TO LEN(a, 1)-1 DO
        ...
    END
END;
По случайности, это было первой (хотя и не самой важной) чертой Оберона, с которой у меня зародился интерес к этому языку.

Слишком низкоуровнево... почему с нуля до LEN(a)-1 ? Зачем столько ненужных деталей? Неудобно...

Ответ на »сообщение 5153« (AVC)
___________________________

Ответ на »сообщение 5151« (Стэн)
___________________________
В Обероне это как раз вообще не является проблемой (для массивов любой размерности; сравните с Си/Си++).

Потому, что под Обероном лежит более высокоуровневая вычислительная модель. Не просто линейная однородная память, а типизированная тегированная. Си является "высокоуровневым ассемблером" 70-х. А ПК по уровню машинных абстракций не слишком далеко ушли от PDP :-)
А вот для современных архитектур (взять те же машины IBM) Оберон гораздо более тянет на "высокоуровневый ассемблер". Для тех же машин IBM, таких, как AS/400 (толковейшую штуку они сделали, надо сказать... даже высокоуровневый промежуточный код с динамической кодогенерацией и независимостью от оборудования... Да ещё в начале 80-х годов... Прям как наши с Эль-76).

Ответ на »сообщение 5151« (Стэн)
___________________________

Ответ на »сообщение 5150« (Антон Григорьев)
___________________________

>>>А foreach - это вопрос исключительно удобства, потому что Оберон следит за правильностью индекса массива и не даёт обратиться к несуществующему элементу в любом цикле.
Не-а!... ))) Кто сказал, что проблема именно в выходе за границы массива? Оберон легко позволит проийти все элементы, кроме двух последних... Конструкция же foreach, для базовых типов в C#, гарантирует, что мы обойдем ВСЕ элементы...
Было так:
a : array[5];

for i := 0 to 4 do
  ...
end;
Стало так:
a : array[7];
И что в данном случае Оберон гарантирует? И даже запрет на приведение типов не поможет... Ползай потом по всему тексту программы, ищи обход по этому массиву...


В Обероне это как раз вообще не является проблемой (для массивов любой размерности; сравните с Си/Си++).

FOR i := 0 TO LEN(a)-1 DO
    ...
END;

или

FOR i := 0 TO LEN(a, 0)-1 DO
    FOR j := 0 TO LEN(a, 1)-1 DO
        ...
    END
END;

По случайности, это было первой (хотя и не самой важной) чертой Оберона, с которой у меня зародился интерес к этому языку.

Ответ на »сообщение 5151« (Стэн)
___________________________
Я еще даже добавлю. В доказательстов своих идей о семантике программ, размытых в состояниях переменных.
Что означает это:

list : array[7];

for i := 0 to 4 do
  list[i]...
end;

Ошибку в программе, которая появилась после увеличения размера массива, или это абсолютно правильный код, который обходит все элементы кроме двух последних?
Вот эта конструкция однозначно обходит все элементы в списке вне зависимости от его размера:

foreach (l in list)
  ...
end;

Ответ на »сообщение 5150« (Антон Григорьев)
___________________________
>>> Нет, вот здесь категорически не согласен. Средства контроля в Обероне очень на высоком уровне, C# и рядом не стоит. Один толко запрет на явные приведения типа резко повышает уровень контроля. 
Контроля чего? Интерфейса?! Так кроме интерфейса есть еще и протокол - последовательность взаимодействия с элементами сущности... Так вот, грамматические конструкции призваны отвечать за правильную последовательность действий...

>>>А foreach - это вопрос исключительно удобства, потому что Оберон следит за правильностью индекса массива и не даёт обратиться к несуществующему элементу в любом цикле.
Не-а!... ))) Кто сказал, что проблема именно в выходе за границы массива? Оберон легко позволит проийти все элементы, кроме двух последних... Конструкция же foreach, для базовых типов в C#, гарантирует, что мы обойдем ВСЕ элементы...
Было так:

a : array[5];

for i := 0 to 4 do
  ...
end;

Стало так:

a : array[7];

И что в данном случае Оберон гарантирует? И даже запрет на приведение типов не поможет... Ползай потом по всему тексту программы, ищи обход по этому массиву...

Ответ на »сообщение 5149« (Стэн)
___________________________

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

Нет, вот здесь категорически не согласен. Средства контроля в Обероне очень на высоком уровне, C# и рядом не стоит. Один толко запрет на явные приведения типа резко повышает уровень контроля. А foreach - это вопрос исключительно удобства, потому что Оберон следит за правильностью индекса массива и не даёт обратиться к несуществующему элементу в любом цикле.

Ответ на »сообщение 5148« (AVC)

ИМХО, Вы, Антон, подменяете здесь понятия.
А именно: абстракцию, которую надо реализовать (это цель), подменяете средством (ООП), причем в одной его разновидности.

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

Ответ на »сообщение 5148« (AVC)
___________________________
>>> На мой взгляд, Вы упускаете из виду, что средства контроля, существующие на уровне ЯВУ, не существуют на уровне асемблера.
И как много средств контроля со стороны ЯВУ существуют в Обероне? Например есть конструкция обхода КАЖДОГО элемента массива? В C# есть foreach...
Я вот что скажу, средства контроля - это то, что выражено в грамматике языка (есть соответсвтвующие грамматические конструкции), а в Обероне грамматика очень бедная, и средства контроля получаются очень бедные... О чем изначально и идет речь...

Ответ на »сообщение 5147« (Антон Григорьев)
___________________________

Ответ на »сообщение 5146« (AVC)
___________________________


Я хотел сказать, что на ассемблере нельзя реализовать высокоуровневые абстракции.

Странное утверждение. Любая программа, которую можно откомпилировать, может быть отображена на ассемблер. Следовательно, любая абстракция, которую можно реализовать хотя бы на одном компилируемом ЯВУ, может быть реализована и на ассемблере.

И даже оттранслирована в машинный код. :)
На мой взгляд, Вы упускаете из виду, что средства контроля, существующие на уровне ЯВУ, не существуют на уровне асемблера.

Странный у нас разговор получается. Вы просите назвать абстракцию, которую нельзя реализовать на Обеорне. Я отвечаю, что дело не в принципиальной невозможности, а в сложности, и привожу пример абстракции, которую на Обеорне реализовать сложно - ООП. Вы в ответ говорите, что Оберон хорош в области компонентного программирования. Но ведь ООП и КП - технологии хоть и родственные, но всё-таки разные. Поэтому ваше замечание - это просто уход от темы, и сильные позиции Оберона в КП (с чем я полностью согласен) не отменяют его слабости в ООП.

ИМХО, Вы, Антон, подменяете здесь понятия.
А именно: абстракцию, которую надо реализовать (это цель), подменяете средством (ООП), причем в одной его разновидности.
Под ООП, вероятно, Вы понимаете использование классов.
Но вот существуют языки с поддержкой ООП -- Оберон и Ада-95 -- в которых нет классов.

Ответ на »сообщение 5146« (AVC)
___________________________


Я хотел сказать, что на ассемблере нельзя реализовать высокоуровневые абстракции.

Странное утверждение. Любая программа, которую можно откомпилировать, может быть отображена на ассемблер. Следовательно, любая абстракция, которую можно реализовать хотя бы на одном компилируемом ЯВУ, может быть реализована и на ассемблере. Другое дело, что её реализация будет размыта из-за постоянного отвлечения на состояние регистров процессора, и разглядеть абстракцию будет практически невозможно. Как в том анекдоте: "Ты его не видишь. И я его не вижу. А он есть!"

Прежде чем говорить о "заходе солнца вручную", хорошо бы представить, с чем следует сравнивать Оберон. На мой взгляд, речь может идти о компонентных технологиях (COM и т.п.). Вот и сравните, где больше ручной работы и "захода солнца вручную". (Просто представьте в уме код на Обероне и код (скажем, на Си++) для COM.)

Странный у нас разговор получается. Вы просите назвать абстракцию, которую нельзя реализовать на Обеорне. Я отвечаю, что дело не в принципиальной невозможности, а в сложности, и привожу пример абстракции, которую на Обеорне реализовать сложно - ООП. Вы в ответ говорите, что Оберон хорош в области компонентного программирования. Но ведь ООП и КП - технологии хоть и родственные, но всё-таки разные. Поэтому ваше замечание - это просто уход от темы, и сильные позиции Оберона в КП (с чем я полностью согласен) не отменяют его слабости в ООП.