OberonCore

Выделено: viewtopic.php?p=49746#p49746

Здравствуйте, Сергей.
Вы писали, что хорошо бы удалить из Оберона указатели, кроме указателей на записи, и добавили бы тип STRING.
Чем плохи указатели на массивы? Мне кажется что это очень полезный инструмент во многих случаях, когда размер массива изначально не известен. А если выделять сразу максимальный размер для каждого элемента, то может не хватить памяти. К тому же в массиве можно быстро искать с помощью бинарного поиска, а в записях поиск можно делать только последовательно.
Насчет типа STRING. Почему интересно Вирт не добавил такой тип в язык, веть он и компилятор писал, где используются строки, и операционную систему, где тоже тескстовые строки используются?
К тому же строки можно реализовать без добавления новой функциональности в язык, используя процедуры, например:
Concat(str1, str2); Append(str1, str2)
Единственное с чем я согласен, что когда надо конкатенировать много членов, например,
str = str1 + str2 + str3 + str4, то
не удобно писать Concat(Concat(Concat(str1, str2), str3), str4).

Рискну предположить, что для того, чтобы не "множить сущности". Ведь строка по сути является массивом символов, а массивы в языке и так уже есть. Буду благодарен, если кто-нибудь подкинет ссылочку на то как сам Вирт комментирует это.

Кстати, сам я считаю, что строковый тип в языке должен быть.

Как-то ведь Вирт обошелся без указателей на массив в Обероне-07.

Так Вирт для специфических нужд может и обходится без указателей на массивы, но по мне так это полный перегиб палки.

При написании компилятора можно обойтись только указателями на записи. Для массива ключевых слов, например, размер можно задать заранее. Но ведь это не говорит о том, что всегда можно обойтись без динамических массивов.
Можно конечно в записи создать фиксированный массив на 1000 элементов, а если требуется добавить 1001-й элемент в массив, то создать еще одну запись. Но это усложнит алгоритмы для работы с такой структурой.

Совсем нельзя. Но насколько часто надо?
А: достаточно массивов статич. размера
Б: подойдут линейные дин. массивы. Альтернатива - список записей со статич. массивом - чуть сложнее
В: необходимы сложные дин. структуры

P.S. 1) Эта тема уже обсуждалась где-то здесь viewtopic.php?p=20297#p20297
2) В качестве иллюстрации замены Б на В, думаю, подойдет пример Александра Ильина
viewtopic.php?p=22775#p22775
viewtopic.php?p=23103#p23103

В случае строк согласен, можно обойтись без динамических массивов.
Но без динамических массивов нельзя обойтись когда, имеется большой объем данных, в которых требуется быстро находить требуемый элемент. Одно из очевидных решений, отсортировать массив, и затем бинарным поиском искать требуемый элемент много раз. Можно конечно и здесь обойтись без динамических массивов, если реализовать сбалансированное дерево, в котором также можно искать с помощью бинарного поиска. Но сбалансированное дерево требует больше памяти, чем массив, за счет того, что требуется хранить ссылки на левого и правого потомков. К тому же алгорит балансировки дерева в несколько раз сложнее алгоритма сортировки, например.
Поэтому я считаю, что если мы отбрасываем динамические массивы, то мы также отбрасываем большой пласт эффективных по времени и памяти алгоритмов.

Мне это очень напомнило ситуацию с (чистыми)функциональными языками. Вначале мы отпиливает (насовсем) изменяемость (mutable types), как лишнее. Как то, без чело проще жить. А затем, как возникает алгоритмическая задача плохо ложащаяся на неизменяемые типы данных, мы начинаем выдумывать обходные пути, городить костыли, вводить понятия типа "аммортизиацинная сложность алгоритма", сильно отдающие маркетингом и т.п. Ну и вообще, аммортизационная сложность O(1), а то что оно работает в 10-20 раз медленнее чем то же на простом Си или ином языке с mutable data, это уже мелочь.

Угу. Это потому, что если некое разделение, которое есть "от природы задач" (например, на операторы и выражения) попытаться убрать, то оно непременно вылезет выше - и потребует всё равно своего проведения в жизнь. Так же, как с однородными языками, где оставлена только одна форма записи - базовая абстракция. Разнообразие всё равно приходится имитировать выше, только это перекладывается на плечи программистов.

Пожалуй, это и есть то самое "... но не проще".

Не всё так просто, по-моему. Если речь о массивной задаче - всегда есть возможность задуматься об организации иного механизма доступа кроме динамического массива. По ключевой информации, например.

Ещё Files.File.

Но дин. массивы представляются всё равно нужными. Мелкий пример - вот хранить неизменяемую, но дополняемую структуру со строками разных длин; удобно эти "хвосты" переменной длины динамически порождать.

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

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

Если я не ошибаюсь, то в Обероне-07, который сделан с учётом опыта Оберона-SA, это как-то связано с особенностями целевой платформы StrongARM. Было такое предположение.

Откровенно говоря, не помню в АРМах ничего такого.
Помню что да, переменные должны располагаться по адресам кратным своим размерам.
Т.е. простой и нивинный код сишный навроде:

является пакостью.

Но как это связано с обероновскими массивами, если связано вообще?

Можно обойтись блоками фиксированной длины:

Вообще-то Фортран много лет обходился без динамических массивов...
Кроме того, на базе фиксированного массива большого размера можно построить систему распределения памяти. Например, см. Холл "Вычислительные структуры"...

Угу. Менеджер памяти написать для своей виртуальной машины
Это называется -- эмуляция.

Кроме того, речь идет не о динамических массивах (размер которых можно менять ПОСЛЕ создания), а о обычных массивах просто размер которых не известен на момент компиляции. Скажите лучше, что в них плохого?

Такая формулировка вопроса в контексте темы некорректна. Думаю, все согласятся, что Вирт не руководствуется разделением средств ЯП на плохие и хорошие.

Вирт выпустил новую ревизию Оберона (http://oberoncore.ru/wiki/lang/oberon-07) на основании 20 летнего опыта работы. Врят ли среди нас, ведущих обсуждение, найдётся кто-то, имеющий подобный опыт.

Я думаю, что более полезным было бы вместо умозрительного поиска причины 'Почему Вирт решил исключить "дин. массивы" из фундаментальных, обязательных в языке средств' - на базе нашего богатого опыта использования ЯП с дин. массивами, обзавестись опытом работы без дин. массивов. На своих реальных задачах. И, через некоторое время, обсудить этот опыт.

Самое простая замена "дин. масс." - список записей со статич. массивами: viewtopic.php?p=49936#p49936

Потребность в упомянутом тов. Лаптевым решении тоже, думаю, никуда не исчесла. В критичных по времени задачах задействуют ручную сборку мусора, переиспользование ставших ненужными объектов (тов. Губанов приводил примеры для C#). Мне кажется, это есть частный случай ручного распределения памяти.

P.S. Касательно предложенного подхода у меня опыт наработался. Уже давно пишу на КП без FOR, RETURN-в из середины. Привык. Последнее сделало код более структурным и понятным. Не жалею, проблем не испытываю.

Что-то не могу у себя найти report Вирта на Oberon-SA. Помнится мне, что в нём по поводу убранных массивов было пояснение.

P.S.: вот он: http://www.oberoncore.ru/wiki/lang/oberon_sa
Сейчас поглядим.