Замечания и предложения


#1167

Наконец-то мы переплюнем знаменитое бейсиковское Mid(s,3,5) = Mid(s,7,5) (идущее с 60-х годов прошлого века) и приблизимся к Фортрановскому a(3:7:2) = b(::3)


#1168

Ага. А потом ещё добавить list comprehensions, и получится Питон с синтаксисом Паскаля, преферансом и блудницами :slight_smile:


#1169

4 сообщения перенесены в тему Болталка PascalABC.NET


#1170

Я понимаю, что это сказано с иронией, но всё же, стоит отметить, что это уже (где-то давно, где-то недавно) есть в Скале, Котлине, Джаве и Хаскеле.


#1171

Дурной пример заразителен…


#1172

У нас были проблемы с константами - помнят все. :slight_smile: Сейчас с ними, кажется, всё нормально. Но, константам нельзя присваивать значения-результаты функций. Я предлагаю сделать особый вид констант: constexpr-константы, которые могут равняться результату работы constexpr-функции. Ссылка на статью скажет больше, чем могу сказать я. Как представляю себе это всё я:

function F(): integer; constexpr := 12 * 3;

constexpr
  x = F();

begin
end.

Ну, теперь, Ваше слово, разработчики и остальные участники форума.


Бесполезные улучшения PascalABC.NET
#1173

А посмотрите, как это сделано во Free Pascal. C++ - это всё-таки другой язык, очень сложный к тому же, и компиляторы для него - архисложные.

И - почему всё же не писать

const x = 12 * 3;

?


#1174

Ну, я это привёл как пример. А остальные, что скажут на счёт этой фичи?


#1175

Вычисляемая константа, ограничения на которую описаны почти сотней строк. Разработчикам виднее, конечно, стоит ли вступать в это гуано, но на мой взгляд, такие константы могут интересовать только в статусе пьяного ёжика. Трезвый-то на кактус не полезет… Паскалевских констант с четырьмя действиями арифметики за глаза хватает.


#1176

Ну почему же. Следующий код работает:

const a = sin(1);

#1177

Это встроенная функция. Чтобы это имело какой-то смысл, константа должна быть вычислена до загрузки программы в память, т…е. на этапе компиляции. Расширяя идею использования функций, можно докатиться до того, чтобы попытаться проделывать подобные фокусы и пользовательскими функциями, а там возможна рекурсия и т.д… и мы приходим к необходимости еще и интерпретатор языка иметь. Более того, по правилам Паскаля мы должны интерфейс такой функции описать до описания константы. А все ради чего?


#1178

Вряд ли. Для .Net, в котором программу на .Net можно быстро и просто собрать и запустить средствами .Net из другой программы, которая опять же, на .Net - существующего функционала, с небольшими дороботками, должно хватить. То есть, я имею в виду, можно собрать и запустить отдельно константные методы, до того как генерировать IL код для всего остального.

С другой стороны, мне кажется этот функционал легче, и что важнее - правильнее, было бы реализовать в качестве функционала IDE (не того огрызка что сейчас, а нормальной IDE). Ну а пока что - я бы лично реализовывал (да и не бы, вот пример) в качестве ещё 1 программы - упаковщика.

В отличии от призрачной возможности, что кому то будет не лень сделать нормальную IDE - собрать простенький упаковщик своего проекта, собирающий константные значения (как у меня - версия) и правильно добавляющий все компоненты (иконки .exe, манифест и т.п.) - не так уж и сложно.

Хотя, пример, наверное, не лучший, ибо константа версии у меня костыль)). Но, что я считаю там правильным - так это использование $include чтоб вставить значение константы, которую перед компиляцией сгенерирует упаковщик.

А чтоб работало всё как const функции - надо лишь ещё 1 .pas файл, который будет содержать эти все const функции. Упаковщик их компилирует и запускает, чтоб получить значения. И далее заменяет $include значения на то, что дал файл с const функциями.


#1179

Т.е. PascalABC.NЕТ уже без IDE рассматриваться не должен? Консольные там компиляторы, - они идут лесом?


#1180

IDE расширяющие функционал основного компилятора - совсем не новость. Редкость, но в данном случае, по моему, уместная. И - никто не отменял консольный вызов функционала IDE, который в свою очередь будет вызывать консольный компилятор паскаля))) Но да, это уже жуткие костыли пошли… Это всё должно быть ужасно медленно.


#1181

Есть хорошая поговорка: “Гора родила мышь”. Вам не кажется, что в данном случае она может быть уместной? А вот от полноценного прекомпилятора/препроцессора я бы не отказался. Хоть это тоже не часто нужно, а учебному процессу не нужно вообще.

P.S. Ностальгически вспоминается интерпретатор REXX в СВМ на ЕС-ках. Мощный и удобный самостоятельный язык, который мог быть и препроцессором для PL/1. Rexx оказался настолько хорош,что жив и сейчас в OpenSource виде. Язык доступен для платформ AIX, Linux, Mac OSX, Solaris, Windows


#1182

Проще не морочить голову компилятору, а запустить программу, узнать значение функции и подставить в константу.

НЕ ИЩИТЕ В ПРОГРАММИРОВАНИЕ ЛЁГКИХ ПУТЕЙ! Программист Моисей


#1183

Товарищи, приведенный тут пример из С++ вообще не из реалий .NET. Зачем оно в нем нужно - иметь возможность объявлять всякие массивы на стеке с вычисляемым количеством значений(int Arr[N]), генерить шаблоны с переменными-аргументами, значения которых должны быть известны на этапе компиляции (template <int N>)… Таких проблем в Паскалях нет, и делать костыли для их решения абсолютно бессмысленно.

Кстати, вроде ж когда-то кто-то писал в качестве дипломной, или еще какой работы, плагин для Eclipse? Мертв?


#1184

Простите, генерация магических чисел в коде - вообще не лучший паттерн. Совсем.


#1185

Все плагины для Эклипса пишутся в расчёте на конкретную версию Эклипса и с другими не работают. По крайней мере, с другими я не талкивался. Тот плагин благополучно 4 года назад работал с какой-то версией Эклипса.

Собственно, нет проблем. Если кто-то хочет взяться - можно внедрить консольный компилятор в Visual Studio Code - говорят, очень хороший редактор.


#1186

Так и не надо!