Примерно это
Означает ли это возможность появления среза в левой части оператора присваивания?
Конечно означает
Наконец-то мы переплюнем знаменитое бейсиковское Mid(s,3,5) = Mid(s,7,5)
(идущее с 60-х годов прошлого века) и приблизимся к Фортрановскому a(3:7:2) = b(::3)
Ага. А потом ещё добавить list comprehensions, и получится Питон с синтаксисом Паскаля, преферансом и блудницами
Я понимаю, что это сказано с иронией, но всё же, стоит отметить, что это уже (где-то давно, где-то недавно) есть в Скале, Котлине, Джаве и Хаскеле.
Дурной пример заразителен…
У нас были проблемы с константами - помнят все. Сейчас с ними, кажется, всё нормально. Но, константам нельзя присваивать значения-результаты функций. Я предлагаю сделать особый вид констант: constexpr
-константы, которые могут равняться результату работы constexpr
-функции. Ссылка на статью скажет больше, чем могу сказать я. Как представляю себе это всё я:
function F(): integer; constexpr := 12 * 3;
constexpr
x = F();
begin
end.
Ну, теперь, Ваше слово, разработчики и остальные участники форума.
А посмотрите, как это сделано во Free Pascal. C++ - это всё-таки другой язык, очень сложный к тому же, и компиляторы для него - архисложные.
И - почему всё же не писать
const x = 12 * 3;
?
Ну, я это привёл как пример. А остальные, что скажут на счёт этой фичи?
Вычисляемая константа, ограничения на которую описаны почти сотней строк. Разработчикам виднее, конечно, стоит ли вступать в это гуано, но на мой взгляд, такие константы могут интересовать только в статусе пьяного ёжика. Трезвый-то на кактус не полезет… Паскалевских констант с четырьмя действиями арифметики за глаза хватает.
Ну почему же. Следующий код работает:
const a = sin(1);
Это встроенная функция. Чтобы это имело какой-то смысл, константа должна быть вычислена до загрузки программы в память, т…е. на этапе компиляции. Расширяя идею использования функций, можно докатиться до того, чтобы попытаться проделывать подобные фокусы и пользовательскими функциями, а там возможна рекурсия и т.д… и мы приходим к необходимости еще и интерпретатор языка иметь. Более того, по правилам Паскаля мы должны интерфейс такой функции описать до описания константы. А все ради чего?
Вряд ли. Для .Net
, в котором программу на .Net
можно быстро и просто собрать и запустить средствами .Net
из другой программы, которая опять же, на .Net
- существующего функционала, с небольшими дороботками, должно хватить. То есть, я имею в виду, можно собрать и запустить отдельно константные методы, до того как генерировать IL
код для всего остального.
С другой стороны, мне кажется этот функционал легче, и что важнее - правильнее, было бы реализовать в качестве функционала IDE
(не того огрызка что сейчас, а нормальной IDE
). Ну а пока что - я бы лично реализовывал (да и не бы, вот пример) в качестве ещё 1 программы - упаковщика.
В отличии от призрачной возможности, что кому то будет не лень сделать нормальную IDE
- собрать простенький упаковщик своего проекта, собирающий константные значения (как у меня - версия) и правильно добавляющий все компоненты (иконки .exe, манифест и т.п.) - не так уж и сложно.
Хотя, пример, наверное, не лучший, ибо константа версии у меня костыль)). Но, что я считаю там правильным - так это использование $include
чтоб вставить значение константы, которую перед компиляцией сгенерирует упаковщик.
А чтоб работало всё как const
функции - надо лишь ещё 1 .pas файл, который будет содержать эти все const
функции. Упаковщик их компилирует и запускает, чтоб получить значения. И далее заменяет $include
значения на то, что дал файл с const
функциями.
Т.е. PascalABC.NЕТ уже без IDE рассматриваться не должен? Консольные там компиляторы, - они идут лесом?
IDE расширяющие функционал основного компилятора - совсем не новость. Редкость, но в данном случае, по моему, уместная. И - никто не отменял консольный вызов функционала IDE, который в свою очередь будет вызывать консольный компилятор паскаля))) Но да, это уже жуткие костыли пошли… Это всё должно быть ужасно медленно.
Есть хорошая поговорка: “Гора родила мышь”. Вам не кажется, что в данном случае она может быть уместной? А вот от полноценного прекомпилятора/препроцессора я бы не отказался. Хоть это тоже не часто нужно, а учебному процессу не нужно вообще.
P.S. Ностальгически вспоминается интерпретатор REXX в СВМ на ЕС-ках. Мощный и удобный самостоятельный язык, который мог быть и препроцессором для PL/1. Rexx оказался настолько хорош,что жив и сейчас в OpenSource виде. Язык доступен для платформ AIX, Linux, Mac OSX, Solaris, Windows
Проще не морочить голову компилятору, а запустить программу, узнать значение функции и подставить в константу.
НЕ ИЩИТЕ В ПРОГРАММИРОВАНИЕ ЛЁГКИХ ПУТЕЙ! Программист Моисей
Товарищи, приведенный тут пример из С++ вообще не из реалий .NET. Зачем оно в нем нужно - иметь возможность объявлять всякие массивы на стеке с вычисляемым количеством значений(int Arr[N]
), генерить шаблоны с переменными-аргументами, значения которых должны быть известны на этапе компиляции (template <int N>
)… Таких проблем в Паскалях нет, и делать костыли для их решения абсолютно бессмысленно.
Кстати, вроде ж когда-то кто-то писал в качестве дипломной, или еще какой работы, плагин для Eclipse? Мертв?