Тот же вопрос.
@admin, @ibond если мы с @Gleb-ом сможем добавить фичу для создания собственных видов операторов (и успешно проведём все тесты) - вы примите пулл реквест?
Нет
Что такого принципиального в этом?
Любое усложнение языка мусором плохо влияет на все его части - в частности, ошибки для начинающих вылазят очень мудрёные. Например, мы запретили введенный ранее оператор => потому что школьники иногда путали >= с ним и сообщение об ошибке было ужасающим. Особенно ужасно выглядит предложение переопределения >>, которое легко путается с двумя < <. Так что даже не просите
Конечно, не сломать то что есть - самое важное при добавлении фичи. Мне стоило лучше объяснить идею: новые виды операторов не просто так позволяет добавлять, типа operator*+*(i1,i2:integer):integer, его надо будет сначала объявить чем то типа type *+* = operator(integer,integer):integer (это пример, вряд ли так же будет выглядеть, кстати директива компилятора была бы особо удобна тут), так, вроде, случайно сломать ничего нельзя. И можно не использовать эту фичу, без объявления оно работать не будет. Я обдумал эту идею с момента написания этого сообщения перед тем как писать, и в принципе ещё открыт для других предложений.
Тут есть следующая проблема: новый значок оператора - это новая лексема, вводится в грамматику и требует перекомпилировать компилятор. Динамические лексемы в стандартных грамматиках я не встречал. Обратите внимание, что в нескриптовых языках этого в принципе нет - в частности, Страуструп писал, что он в свое время думал сделать это для C++, но отказался из-за гигантской сложности.
Ну то что вряд ли получится я понимаю, но отрицательный результат тоже результат, в этом случае так особенно.
Я считаю, что в этом есть смысл. Могу предложить следующий синтаксис:
class integer.Operator *+*(a: integer; b: integer);
Begin
End;
То есть просто определять новый оператор в виде переопределения существующего.
Тогда это обычная перегрузка. оператора. Она и так есть. Разработчики пытаются довести свою мысль, что они категорически возражают против введения новых символов операций. А существующие - да ради бога! Если хотите, перегрузите + и замените его, к примеру, знаком деления. Английская разведка будет в полном дауне, пытаясь понять Вашу программу.
Вы меня не правильно поняли. Я имею ввиду определение нового оператора в виде переопределения существующего. То есть, допустим, мы придумали какой-то метод для целого числа (integer). Да хоть операцию выделения корня n-ной степени или модуля. Разумеется, мы не будем для этого использовать существующие на данный момент операторы, так как это приведёт не к расширению, а лишь замещению, причём критически важных действий. Пусть оператор выделения корня будет выглядеть так: *!, а его использование так: sqrt := a *! 2;. Где a - значение, из которого извлекаем корень, а 2 - степень. Соответственно в программе мы пишем это :
class integer.function operator *!(value: integer; sqr: integer): real;
Begin
<Код>
End;
Таким образом мы объявили для текущей сборки новый оператор и можем им пользоваться. При этом добавить ограничения, например: максимальная длина - 3 символа, допустимые символы: !, %, *, &, -, +, =, >, <, ?, , |, /.
Я понял так, как было написано. А сейчас Вы пишете о введении новых лексем, против чего разработчик высказался однозначно и категорически. Мне вот тоже не нравятся многие “генетические болезни” Паскаля, которые с моей колокольни куда более важны, чем введение новых лексем в операции, но вот живу с этим и “не рыпаюсь” особо, хотя вчера при решении задачи на работу с типизированным файлом так вслух “пронес по кочкам” Н.Вирта, что домашние аж диву дались… Ну вот оно нормально разве, когда чтобы увеличить на единичку содержимое записи №5 я должен сначала выполнить поиск записи №4, потом выполнить чтение в некую переменную, далее, увеличить ее на единицу, снова выполнить поиск записи №4 и потом выполнить вывод модифицированного значения в файл?
Проблема этого варианта в том что его грамматика похожа на грамматику других фич, если написать что то среднее (как то ошибиться) - компилятор не поймёт что вы пытались сделать. Если добавлять эту фичу - надо чтоб её никак нельзя было спутать с чем то другим.
То что я предложил это предописание оператора:
{$defop '*!'}
function integer.operator*!(a: integer; b: integer):real;
begin
end;
begin end.
И я считаю очень важным сделать так, чтоб до явного указания, что мы будем создавать свои операторы - эта фича никак не проявлялась.
@RAlex я в основном согласен, но идеология “сидеть и не рыпаться” мягко говоря мне не нравится. Кстати что у вас не так с типизированными файлами - я не понял.
Это не у меня, а в Паскале. Типизированный файл - суть файл прямого доступа с фиксированной длиной записи, когда нужное место в файле находится путем вычисления смещения от его начала на величину, равную произведению длины записи на её порядковый номер - примерно, как в С элемент массива находится по номеру и длине элемента. Казалось бы, все необходимые процедуры (ну или функции, процедуры, свойства, методы) для работы с такими файлами сто лет как известны. Но нет, Вирт пошел по принципу минимально необходимого, подобно как при решении не делать возведения в степень выше второй, не делать циклов с шагом отличным от единицы (минус единицы) и т.п. В результате простая в принципе задача по обработке типизированного файла меня вчера буквально довела до белого каления. Да блин поминальный, еще в 1964 году в стандарте языка PL/1 был определен нормальный набор операторов для подобных файлов типа REGIONAL(1), так что Вирту он был известен. Но вот правда говорят - языки создают так, что языки для обучения и для работы - два противоположных полюса.
Кстати, обратите внимание, насколько разработчики РАВС 3.3 расширили работу с текстовыми файлами. А вот типизированные практически остались “за бортом”.
А почему за бортом? Весь PABCExtensions этому посвящён
Написать, какой бы хотелось видеть работу с типизированными файлами? )))
Давайте в отдельную тему с примером что именно выходит громоздким…
Вы правы, так будет правильнее.
Если сравнить, сколько всего добавлено для текстовых файлов с тем, что есть в PABCExtensions для типизированных (а половина там - просто “сахарок”), станет понятно, почему я назвал это “практически за бортом”. Ведь реально добавлен только обмен с последовательностью а процедуры всего лишь стали одноименными расширениями.
А хотелось бы иметь Skip(n) для относительного смещения по записям, сахарок Seek(Top) и Seel(Bottom), а также чтение и запись без смещения указателя ReadNoSkip, WriteNoSkip (или опциональный параметр у Read/Write, разрешающий выполнять операции обмена без смещения указателя)
Вышла версия PascalABC.NET 3.3.5, сборка 1644 от 23.03.2018.
В выводе посредством Write/Writeln появилась возможность использовать своеобразный аналог интерполированных строк C#. Своеобразие их в том, что используется смесь форматов традиционного Pascal и среды .NET. Методом проб и ошибок удалось выявить следующее:
Оператор вывода записывается в виде
Write($'форматная строка');
Форматная строка - это произвольный текст, в который в нужных местах внедрены элементы вида {элемент вывода}, а каждый элемент вывода - это имя переменной (не массива, но записи и кортежи понимаются верно), за которым могут следовать паскалевская спецификация ширины поля для вывода и количества цифр в дробной части, как обычно, предваряемые двоеточиями:
begin
var (a,b,c):=(3.156,8,False);
Writeln($'Вещественное a: {a:5:2}, целое b={b} и булево {c:10}')
end.
Без спецификации ширины форматные строки можно также писать в расширении .Ptint/.Println:
begin
var (a,b,c):=(3.156,8,False);
($'Вещественное a: {a}, целое b={b} и булево {c}').Println
end.
форматные строки могут оказаться удобно читаемой альтернативой уже имеющимся средствам вывода. Вариантов с программным созданием форматирующих строк я не нашел. Но зато вместо имени переменной в фигурные скобки можно ставить произвольное вычисляемое выражение. А вот дважды повторять один и тот же элемент вывода почему-то запрещено.
begin
var a:=1;
Writeln($'Первый раз {a} и второй {a}')
end.
Будет сообщение “Program1.pas(3) : Встречена неправильная форматная строка”
2 лайка
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021