Oberon space
General Category => Общий раздел => Тема начата: vlad от Октябрь 12, 2013, 06:23:49 am
-
По мотивам обсуждения строк (http://oberspace.dyndns.org/index.php/topic,552.0.html) в O7. Чего не хватает в языке, чтобы использовать ARRAY OF CHAR как строку (дабы не плодить дополнительных сущностей в виде типа STRING или еще чего). Все уперлось прежде всего в то, что нельзя создать массив заранее неизвестного размера. Вобщем изначально было понятно, что с динамическими массивами придется что-то придумывать, поэтому текущая идея вызревала давно. А конкретная проблема со строками позволяет проверить идею на практике.
Итак, предложение по расширению O7 динамическими массивами.
1. Массив может быть объявлен без указания размера, в этом случае считается, что он динамический:
TYPE
A = ARRAY OF CHAR;
R = RECORD a: ARRAY OF INTEGER END;
VAR
a: ARRAY OF BOOLEAN;
2. Размер динамического массива по умолчанию - 0. Размер можно увеличить или уменьшить с помощью предопределенной функции RESIZE. Оставшиеся элементы после RESIZE сохраняют свое значение. Новые элементы имеют значение по умолчанию (https://github.com/vladfolts/oberonjs/wiki/Original-report-refinements#2-variables-default-values).
3. Присваивание массивов.
- Динамический массив присваивается другому динамическому массиву (конечно при сохранении типов элементов). После присваивания оба массива имеют одинаковый размер и содержимое.
- Обычный массив или открытый массив присваивается в динамический.
- Нельзя присвоить динамический массив в обычный или открытый (ошибка компиляции).
4. Открытые массивы (в формальных параметрах).
Синтаксис открытых массивов меняется - добавляется ключевое слово ANY, иначе они выглядят как динамические, хотя семантика различается (см. 3).
PROCEDURE p(VAR a1: ARRAY OF INTEGER; a2: ANY ARRAY OF CHAR; VAR a3: ANY ARRAY OF BOOLEAN);
a1 - динамический массив (содержимое и размер может меняться).
a2 - открытый массив (неизменяемый).
a3 - открытый массив (содержимое может меняться, но не размер).
Динамический массив в формальных параметрах может быть использован только с VAR. Без VAR он не имеет смысла, так как его размер не может быть изменен.
При подстановке фактических параметров:
- только динамический массив может быть использован если формальный параметр - динамический массив
- любой массив может быть использован если формальный параметр - открытый массив
5. Многомерные массивы.
Если динамический массив объявлен в качестве элемента другого массива, то он по-прежнему может иметь произвольный размер независимо от размера других элементов.
VAR a: ARRAY 2 OF ARRAY OF INTEGER;
...
RESIZE(a[0], 3);
RESIZE(a[1], 5);
ASSERT(LEN(a[0] = 3);
ASSERT(LEN(a[1] = 5);
Уфф. Вроде все. Критикуйте :)
-
Дополнительные комментарии:
1. Почему не POINTER TO ARRAY OF (как в ББ)
- Потому что оно не обязано всегда лежать в хипе - оставим компилятору возможность оптимизировать тривиальные случаи.
- Потому что не хочется иметь дело с разыменованием NIL (хватит и ошибок индексирования).
- Применительно к строкам лучше все же копировать содержимое при присваивании, чем иметь дело с расшаренными и изменяемыми строками.
2. Почему не NEW (как в астробовском расширении), а новая функция RESIZE
- Опять же - чтобы не было ощущения хипа
- Чтобы было понятно, что содержимое сохраняется (при возможности)
3. Почему ANY ARRAY OF для открытых массивов
- Придумайте лучший синтаксис для открытых массивов :)
-
Лучше, позаимствовать из Активного Оберона, чтобы не городить лисапеты. Как-то так:
VAR
a : ARRAY [*] OF INTEGER;
...
NEW( a, 5 );
RESHAPE( a, 10 );
RESHAPE( a, 20);
...
PROCEDURE P( arg: ARRAY [*] OF INTEGER );
Или без скобок, просто ARRAY * OF INTEGER
-
Лучше, позаимствовать из Активного Оберона, чтобы не городить лисапеты. Как-то так:
RESHAPE - можно (хотя длиннее).
Зачем нужен NEW - не понял.
Звездочки мне кажутся плохой идеей, потому что они уже задействованы для экспорта. Уж лучше тогда открытые массивы оставить как есть в O7, а динамически писать со скобочками. Это, кстати, позволит указать больше, чем одну размерность:
VAR a1: ARRAY [] OF INTEGER; a2: ARRAY [,] OF INTEGER; a3: ARRRAY [,5,] OF INTEGER;
-
Зачем нужен NEW - не понял.
Так динамический массив же - его ж создать нужно.
Звездочки мне кажутся плохой идеей, потому что они уже задействованы для экспорта.
Так не возникает разночтений - сразу видно, что массив динамический.
То, что звёздочка используется как метка экспорта для имён, нисколько не мешает, как не мешает то, что она используется для оператора умножения. Просто я исходил из той идеи, что тем, кто использует в работе Активный Оберон будет привычно и понятно, а тем, кто только начинает использлвать oberonJs - по-сути, всё равно.
-
Зачем нужен NEW - не понял.
Так динамический массив же - его ж создать нужно.
Зачем? Никто ж не создает RECORD-переменные или INTEGER. Динамический массив сразу имеет валидное значение - пустой массив. Без всяких специальных "несозданных" состояний типа NIL. С точки зрения реализации он может быть нулевым указателем, но для пользователя это пустой массив для которого валидны все те операции, которые валидны для пустого массива (LEN, RESHAPE и даже FOREACH, если будет).
Так не возникает разночтений - сразу видно, что массив динамический.
То, что звёздочка используется как метка экспорта для имён, нисколько не мешает, как не мешает то, что она используется для оператора умножения.
Хорошо, пусть будет звездочка.
-
Зачем? Никто ж не создает RECORD-переменные или INTEGER.
Динамические как раз так и создаются, через NEW. А статика она и есть статика.
-
1. Почему не POINTER TO ARRAY OF (как в ББ)
- Потому что оно не обязано всегда лежать в хипе - оставим компилятору возможность оптимизировать тривиальные случаи.
А функция возвращать динамический массив может? Или процедура возвращать через параметры (но это можно и упразднить)? Основная польза такого массива (и вообще строк) именно в этом (передаче между подпрограммами). Если я правильно помню пролог функции, то он выглядит так: возвращаемое значение, параметры, локальные переменные. Функция отрабатывает, чистит за собой стек, но возвращаемый результат не затирает. Или вообще хранит результат в ячейке, специально отведённой вызывающей процедурой. Как вызывающая процедура или пролог смогут определиться с объёмом памяти под строку, если он станет известен только на этапе работы вызванной функции? А определиться надо - иначе стек перетрётся.
-
Зачем? Никто ж не создает RECORD-переменные или INTEGER.
Динамические как раз так и создаются, через NEW. А статика она и есть статика.
Динамический массив - то не динамическая RECORD. Это массив, который может менять свой размер. Все. Представь, что компилятор за тебя делает NEW(array, 0) сразу после блока VAR с объявлением динамического массива, чтоб оградить тебя от ошибки этот NEW не сделать.
Разница с указателем на RECORD (для которого надо делать NEW) принципиальная. Указатель на рекорд может быть проинициализирован другим указателем, а не только NEW. В случае массива ничего такого нет.
-
1. Почему не POINTER TO ARRAY OF (как в ББ)
- Потому что оно не обязано всегда лежать в хипе - оставим компилятору возможность оптимизировать тривиальные случаи.
А функция возвращать динамический массив может?
В рамках текущего предложения - нет, все остается как в оригинальном репорте для массивов.
А вообще, как я уже говорил, ограничение на возврат массивов/рекордов должно быть снято, никакого большого смысла в нем нет (опять пресловутая простота компилятора/оптимизатора - типа результат всегда в регистре R).
Или процедура возвращать через параметры (но это можно и упразднить)?
Да, динамический массив может быть передан как VAR-параметр и в таком виде его можно рассматривать как "результат" вызова процедуры (процедура задаст нужный размер и содержимое).
Как вызывающая процедура или пролог смогут определиться с объёмом памяти под строку, если он станет известен только на этапе работы вызванной функции? А определиться надо - иначе стек перетрётся.
Динамический массив может быть реализован как обычный указатель. Вызывающей процедуре достаточно положить этот указатель на стек. Размер памяти, на который будет указывать этот указатель может быть любой.
-
Но я тут подумал и решил, что в стэке тоже возможно разместиться при особом подходе. Правда, придётся локальные данные процедур двигать, что приведёт к некоторому усложнению компилятора и непонятно как скажется на производительности.
-
Отлично. :)
Опять мэйнстримщики испортили детище Вирта, сейчас дин массивы, а завтра дженерики. :D
-
Отлично. :)
Опять мэйнстримщики испортили детище Вирта, сейчас дин массивы, а завтра дженерики. :D
А пусть делают, только Обероном не называют.
Ну, можно назвать хуероном, норм будет. А полуёбок-дизер сделает свой Дизерон, для олимпиадников, с printf и гомонеграми.
-
А пусть делают, только Обероном не называют.
Ну, можно назвать хуероном, норм будет. А полуёбок-дизер сделает свой Дизерон, для олимпиадников, с printf и гомонеграми.
:D :D :D :D :D - странно... я думал что "педотрон(ака)" - это ваша родная стихия...
-
Отлично. :)
Опять мэйнстримщики испортили детище Вирта, сейчас дин массивы, а завтра дженерики. :D
А пусть делают, только Обероном не называют.
Ну, можно назвать хуероном, норм будет. А полуёбок-дизер сделает свой Дизерон, для олимпиадников, с printf и гомонеграми.
Назови, пожалуйста, хотя бы одну реализацию Оберона без расширений.
-
А пусть делают, только Обероном не называют.
Ну, можно назвать хуероном, норм будет. А полуёбок-дизер сделает свой Дизерон, для олимпиадников, с printf и гомонеграми.
:D :D :D :D :D - странно... я думал что "педотрон(ака)" - это ваша родная стихия...
Мне всё норм, это у тебя ебальник недовольный тут постоянно.
-
А пусть делают, только Обероном не называют.
Ну, можно назвать хуероном, норм будет. А полуёбок-дизер сделает свой Дизерон, для олимпиадников, с printf и гомонеграми.
:D :D :D :D :D - странно... я думал что "педотрон(ака)" - это ваша родная стихия...
Мне всё норм, это у тебя ебальник недовольный тут постоянно.
клевета, вон сколько смайлов за раз распространил...
-
Назови, пожалуйста, хотя бы одну реализацию Оберона без расширений.
Дык, oberonjs версии 1.1 имеет только одно расширение - IMPORT JS. Т.е., любой желающий может оценить сей pure Oberon (tm) by Wirth (c) просто не используя "IMPORT JS". Правда hello world на нем не написать... Но зато Цикл Дейкстры работает.
P.S. Кстати, я все расширения уже решил делать под отдельным названием. Так что поклонники pure oberon могут не беспокоиться.
-
Назови, пожалуйста, хотя бы одну реализацию Оберона без расширений.
Если ты посмотришь на дерево развития всяких около-оберон хуёвин, то увидишь, что развитие, как ты это назвал, расширений, шло в эволюционном порядке, в рамках проектов, типа EthOS и прочих. А тут хуяк-хуяк, и в репорт, потому что не осилили без плюшек, одно слово, мейнстримщики.
-
Назови, пожалуйста, хотя бы одну реализацию Оберона без расширений.
Дык, oberonjs версии 1.1 имеет только одно расширение - IMPORT JS. Т.е., любой желающий может оценить сей pure Oberon (tm) by Wirth (c) просто не используя "IMPORT JS". Правда hello world на нем не написать... Но зато Цикл Дейкстры работает.
Да, надо было добавить - кроме oberonjs :-) Кстати, а как понять правильно работает цикл дейсткры или нет без вывода результатов? Ассертов понавставлять?
P.S. Кстати, я все расширения уже решил делать под отдельным названием. Так что поклонники pure oberon могут не беспокоиться.
А не в виде ключей компилятора, как сделано скажем в ghc (по умолчанию он делает вид что умеет только стандартный Haskell).
-
Назови, пожалуйста, хотя бы одну реализацию Оберона без расширений.
Если ты посмотришь на дерево развития всяких около-оберон хуёвин, то увидишь, что развитие, как ты это назвал, расширений, шло в эволюционном порядке, в рамках проектов, типа EthOS и прочих. А тут хуяк-хуяк, и в репорт, потому что не осилили без плюшек, одно слово, мейнстримщики.
Дык это тоже эволюция - расширение не на ровном месте появилось.
Кстати, посмотри на применение оберона в промышленности, скажем на Astrobe. В рамках какого проекта исследовательско-эволюционного там появились все эти расширения? :-)
-
....одно слово, мейнстримщики.
Vlad, комплимент, однако... :)
-
Если ты посмотришь на дерево развития всяких около-оберон хуёвин, то увидишь, что развитие, как ты это назвал, расширений, шло в эволюционном порядке, в рамках проектов, типа EthOS и прочих. А тут хуяк-хуяк, и в репорт, потому что не осилили без плюшек, одно слово, мейнстримщики.
Проект обозначен (на виках) как "статически типизированный язык на вебе". Так что пока все укладывается в традиции других оберонов.
-
Назови, пожалуйста, хотя бы одну реализацию Оберона без расширений.
Дык, oberonjs версии 1.1 имеет только одно расширение - IMPORT JS. Т.е., любой желающий может оценить сей pure Oberon (tm) by Wirth (c) просто не используя "IMPORT JS". Правда hello world на нем не написать... Но зато Цикл Дейкстры работает.
P.S. Кстати, я все расширения уже решил делать под отдельным названием. Так что поклонники pure oberon могут не беспокоиться.
SYSTEM - это не дженерики/массивы/фп/енумы/туплы и прочее. Какбэ.
-
Назови, пожалуйста, хотя бы одну реализацию Оберона без расширений.
Если ты посмотришь на дерево развития всяких около-оберон хуёвин, то увидишь, что развитие, как ты это назвал, расширений, шло в эволюционном порядке, в рамках проектов, типа EthOS и прочих. А тут хуяк-хуяк, и в репорт, потому что не осилили без плюшек, одно слово, мейнстримщики.
Долго эволюционирует. В аде дженерики доступны аж с 83 года. В обероне....
Мне не понятно, чем плохи данные возможности в языке? Только лишь потому, что без них можно обойтись?
Кто мешает не юзать, дополнительные фичи.
-
Назови, пожалуйста, хотя бы одну реализацию Оберона без расширений.
Если ты посмотришь на дерево развития всяких около-оберон хуёвин, то увидишь, что развитие, как ты это назвал, расширений, шло в эволюционном порядке, в рамках проектов, типа EthOS и прочих. А тут хуяк-хуяк, и в репорт, потому что не осилили без плюшек, одно слово, мейнстримщики.
Долго эволюционирует. В аде дженерики доступны аж с 83 года. В обероне....
Мне не понятно, чем плохи данные возможности в языке? Только лишь потому, что без них можно обойтись?
Кто мешает не юзать, дополнительные фичи.
Дженерики нужно сильно думать и пилить прежде чем лепить в среду исполнения аля Оберон/ББ - просто потому, что мы в этом случае теряем независимость компиляции модулей (хотя через константы модули и так зависят друг от друга в плане компиляции в том же ББ, но тем не менее).
Если же у нас Оберон используется для создания монолитных приложений, то проблем с дженериками нет.
-
valexey_u
Если же у нас Оберон используется для создания монолитных приложений, то проблем с дженериками нет.
Да я об этом.
-
valexey_u
Если же у нас Оберон используется для создания монолитных приложений, то проблем с дженериками нет.
Да я об этом.
Ну, при разработке и доработке языка неплохо бы ориентироваться на разные его применения. Поэтому очень хорошо когда в дискуссии о дальнейшем развитии языка участвуют несколько разработчиков разных компиляторов и решений для Оберона. Иначе может случиться какой-нибудь перекос куда-нибудь, язык снова разорвет на 100500 несовместимых диалектов.
-
valexey_u
Если же у нас Оберон используется для создания монолитных приложений, то проблем с дженериками нет.
Да я об этом.
А кому нужно терять возможность динамической загрузки?
-
valexey_u
Если же у нас Оберон используется для создания монолитных приложений, то проблем с дженериками нет.
Да я об этом.
А кому нужно терять возможность динамической загрузки?
Динамическая загрузка имеет свою цену. Огромный класс задач не требует её, более того, она там противопоказана. И нет никакого смысла там эту цену платить.
-
Конечно, но нельзя, как ты выше и отметил, вносить в язык нечто, что сделает её в принципе невозможной.
Можно внести это нечто в какой-нибудь хитрой форме, но это ещё придумать надо.
-
Конечно, но нельзя, как ты выше и отметил, вносить в язык нечто, что сделает её в принципе невозможной.
Можно внести это нечто в какой-нибудь хитрой форме, но это ещё придумать надо.
Не очень понимаю. Нужна динамическая загрузка с макимальной "индивидуальностью" модулей - ну не используй дженерики. Зачем сразу ставить вопрос ребром - не включать в язык вообще все, что потом затруднит динамическую загрузку? Тем более, что подобный подход (не платишь за то, что не используешь) уже работает в C++: надо втиснуться в контрлеер в 512 байт - не используешь исключения и RTL (кстати, шаблоны при этом тебе доступны).
Да что там дженерики. Те же енумы зарезали (типа) из соображений динамичесакой загрузки... Хотя это больше похоже на оправдание свершившегося факта, чем на хоть сколько-то серьезные технические трудности.
-
Отсутствие enum'ов действительно никак не спасает, ибо оставили константы которые намертво связывают разные модули. Вот если бы семантику констант несколько изменить... То и enum'ы можно было бы сделать :-)
-
Отсутствие enum'ов действительно никак не спасает, ибо оставили константы которые намертво связывают разные модули. Вот если бы семантику констант несколько изменить... То и enum'ы можно было бы сделать :-)
Стоп. Компилятор ББ, не подставляет значение констант в код? Свёртывание констант вроде называется.
-
Отсутствие enum'ов действительно никак не спасает, ибо оставили константы которые намертво связывают разные модули. Вот если бы семантику констант несколько изменить... То и enum'ы можно было бы сделать :-)
Стоп. Компилятор ББ, не подставляет значение констант в код? Свёртывание констант вроде называется.
Именно поэтому модули друг от друга и зависят. Изменение одного вызывает перекомпиляцию других.
-
Поэтому если нужна, типа, константа, которая не вызывает перекомпиляции других модулей, делается read-only переменная, инициализируемая в BEGIN модуля.
-
Странно. По идее константы тоже должны быть ReadOnly
И потом, если судить по таким книгам как Porable Oberon 2,
При компиляции модуля нужно смотреть на ревизию модуля и символьного файла (в который записываются константы)
-
Да что там дженерики. Те же енумы зарезали (типа) из соображений динамичесакой загрузки... Хотя это больше похоже на оправдание свершившегося факта, чем на хоть сколько-то серьезные технические трудности.
В Активном Обероне перечисления есть. И динамическая загрузка модулей при этом никуда не делась.
-
В Активном Обероне чего только нет. Там и инициализация массивов по месту объявления присутствует.
-
В Активном Обероне чего только нет. Там и инициализация массивов по месту объявления присутствует.
Ну, с классическими Обероновскими массивами такое не прокатит.
-
Чем дженерики мешают динамике?
Из модуля торчат абстракции. Как он хранит, записывает или вычисляет, нам не нужно знать. Обращение идёт только через абстрактные функции. Те же библиотеки. Чем дин модули, лучше концепции библиотек к примеру dll?
-
Чем дженерики мешают динамике?
Из модуля торчат абстракции. Как он хранит, записывает или вычисляет, нам не нужно знать. Обращение идёт только через абстрактные функции. Те же библиотеки. Чем дин модули, лучше концепции библиотек к примеру dll?
Дженерики/шаблоны никак не мешают динамической загрузке модулей времени выполнения. Они (дженерики) выступают лишь как схема, по которой происходит генерация обобщенного кода или в код целевого языка программирования, или сразу в промежуточное представление( если таковое используется) или в код целевого процессора. При изменения самого дженерика, равно как и при изменении любого импортированного модуля требуется перегенерация/перекомпиляция клиента, и это понятно, но на возможность/невозможность использования динамической загрузки это не влияет.
У нас в Сириусе была обобщенка и никаких проблем по этому поводу ди мы не испытывали. Отказались от обобщёнки по совершенно другой причине - получается некоторое рассогласование исходного и скомпилированного кода, когда кода на яп как бы нет, а машинный код присутствует. Наиболее правильный подход в этом плане в Модуле-3, где система сборки, встречая имплементацию дженерика генерует модули на языке Модула-3, которые присутсвуют в каталоге проекта, и затем уже всё это компилируется, т.е. всё присутвует и все можно посмотреть и удостоверится, что там нет кода активации ядрёной бонбы.
Чтокасается dll в windows, то сама концепция мало отличается от динамической загрузки модулей в Оберонах, просто разные системы и разная реализация, и в dll может присутсвовать несколько таких "модулей". Кстати, старый компилятор Активного Оберона (paco) поддерживал экспериментальный механизм компиляции нескольких модулей в один объектный файл(dll в WinAOS).
-
Кемет спасибо за развёрнутый ответ.