Версия PascalABC.NET 3.3


#21

А пространства имён уже можно считать рабочими или как? Вроде ключевое слово есть и типо как компилятор принимает, но нигде не сказано что оно должно работать (искал в справке, на pascalabc.net и в твитере).


#22

Тот же вопрос.


#23

@admin, @ibond если мы с @Gleb-ом сможем добавить фичу для создания собственных видов операторов (и успешно проведём все тесты) - вы примите пулл реквест?


#24

Нет


#25

Что такого принципиального в этом?


#26

Любое усложнение языка мусором плохо влияет на все его части - в частности, ошибки для начинающих вылазят очень мудрёные. Например, мы запретили введенный ранее оператор => потому что школьники иногда путали >= с ним и сообщение об ошибке было ужасающим. Особенно ужасно выглядит предложение переопределения >>, которое легко путается с двумя < <. Так что даже не просите


#27

Конечно, не сломать то что есть - самое важное при добавлении фичи. Мне стоило лучше объяснить идею: новые виды операторов не просто так позволяет добавлять, типа operator*+*(i1,i2:integer):integer, его надо будет сначала объявить чем то типа type *+* = operator(integer,integer):integer (это пример, вряд ли так же будет выглядеть, кстати директива компилятора была бы особо удобна тут), так, вроде, случайно сломать ничего нельзя. И можно не использовать эту фичу, без объявления оно работать не будет. Я обдумал эту идею с момента написания этого сообщения перед тем как писать, и в принципе ещё открыт для других предложений.


#28

Тут есть следующая проблема: новый значок оператора - это новая лексема, вводится в грамматику и требует перекомпилировать компилятор. Динамические лексемы в стандартных грамматиках я не встречал. Обратите внимание, что в нескриптовых языках этого в принципе нет - в частности, Страуструп писал, что он в свое время думал сделать это для C++, но отказался из-за гигантской сложности.


#29

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


#30

Я считаю, что в этом есть смысл. Могу предложить следующий синтаксис:

class integer.Operator *+*(a: integer; b: integer);
Begin
End;

То есть просто определять новый оператор в виде переопределения существующего.


#31

Тогда это обычная перегрузка. оператора. Она и так есть. Разработчики пытаются довести свою мысль, что они категорически возражают против введения новых символов операций. А существующие - да ради бога! Если хотите, перегрузите + и замените его, к примеру, знаком деления. Английская разведка будет в полном дауне, пытаясь понять Вашу программу.


#32

Вы меня не правильно поняли. Я имею ввиду определение нового оператора в виде переопределения существующего. То есть, допустим, мы придумали какой-то метод для целого числа (integer). Да хоть операцию выделения корня n-ной степени или модуля. Разумеется, мы не будем для этого использовать существующие на данный момент операторы, так как это приведёт не к расширению, а лишь замещению, причём критически важных действий. Пусть оператор выделения корня будет выглядеть так: *!, а его использование так: sqrt := a *! 2;. Где a - значение, из которого извлекаем корень, а 2 - степень. Соответственно в программе мы пишем это :

class integer.function operator *!(value: integer; sqr: integer): real;
Begin
<Код>
End;

Таким образом мы объявили для текущей сборки новый оператор и можем им пользоваться. При этом добавить ограничения, например: максимальная длина - 3 символа, допустимые символы: !, %, *, &, -, +, =, >, <, ?, , |, /.


#33

Я понял так, как было написано. А сейчас Вы пишете о введении новых лексем, против чего разработчик высказался однозначно и категорически. Мне вот тоже не нравятся многие “генетические болезни” Паскаля, которые с моей колокольни куда более важны, чем введение новых лексем в операции, но вот живу с этим и “не рыпаюсь” особо, хотя вчера при решении задачи на работу с типизированным файлом так вслух “пронес по кочкам” Н.Вирта, что домашние аж диву дались… Ну вот оно нормально разве, когда чтобы увеличить на единичку содержимое записи №5 я должен сначала выполнить поиск записи №4, потом выполнить чтение в некую переменную, далее, увеличить ее на единицу, снова выполнить поиск записи №4 и потом выполнить вывод модифицированного значения в файл?


#34

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

То что я предложил это предописание оператора:

{$defop '*!'}

function integer.operator*!(a: integer; b: integer):real;
begin
end;

begin end.

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

@RAlex я в основном согласен, но идеология “сидеть и не рыпаться” мягко говоря мне не нравится. Кстати что у вас не так с типизированными файлами - я не понял.


#35

Это не у меня, а в Паскале. Типизированный файл - суть файл прямого доступа с фиксированной длиной записи, когда нужное место в файле находится путем вычисления смещения от его начала на величину, равную произведению длины записи на её порядковый номер - примерно, как в С элемент массива находится по номеру и длине элемента. Казалось бы, все необходимые процедуры (ну или функции, процедуры, свойства, методы) для работы с такими файлами сто лет как известны. Но нет, Вирт пошел по принципу минимально необходимого, подобно как при решении не делать возведения в степень выше второй, не делать циклов с шагом отличным от единицы (минус единицы) и т.п. В результате простая в принципе задача по обработке типизированного файла меня вчера буквально довела до белого каления. Да блин поминальный, еще в 1964 году в стандарте языка PL/1 был определен нормальный набор операторов для подобных файлов типа REGIONAL(1), так что Вирту он был известен. Но вот правда говорят - языки создают так, что языки для обучения и для работы - два противоположных полюса.

Кстати, обратите внимание, насколько разработчики РАВС 3.3 расширили работу с текстовыми файлами. А вот типизированные практически остались “за бортом”.


#36

А почему за бортом? Весь PABCExtensions этому посвящён


#37

Написать, какой бы хотелось видеть работу с типизированными файлами? )))


Работа с типизированным файлом
#38

Давайте в отдельную тему с примером что именно выходит громоздким…


#39

Вы правы, так будет правильнее.


#40

Если сравнить, сколько всего добавлено для текстовых файлов с тем, что есть в PABCExtensions для типизированных (а половина там - просто “сахарок”), станет понятно, почему я назвал это “практически за бортом”. Ведь реально добавлен только обмен с последовательностью а процедуры всего лишь стали одноименными расширениями.

А хотелось бы иметь Skip(n) для относительного смещения по записям, сахарок Seek(Top) и Seel(Bottom), а также чтение и запись без смещения указателя ReadNoSkip, WriteNoSkip (или опциональный параметр у Read/Write, разрешающий выполнять операции обмена без смещения указателя)