Ошибки PascalABC.NET

А об этом я уже написал в issue, как просил уважаемый @Admin Вот тут

Забавно, что я не только параллельно обратил внимание на ту же проблему, что и вы, но и, фактически, уже использовал в своем тестовом примере то же решение, которое предложил один из разработчиков. Хотя, конечно, это довольно банальный случай.

Я не стал ставить пустой оператор, потому что где-то уже нарвался на случай, когда его компилятор забраковал. Счел, что нарываться снова себе дороже)))

Исправим. Это не гигантская проблема.

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

Всё это ошибки конечно. Тут нет другого пути - надо всё это исправлять и всё.

ЗЫ. Если бы Вы знали, какой автогенерится код при раскрутке yieldа! Там - не только кишьмя кишит goto, да ещё есть goto внутрь блока.

Исправили ещё раз. Пробуйте.

Это внутренняя кухня, сгенерированная программой и её пользователь не видит. А исходники пишутся людьми и для людей. Ясно, что есть хорошие, правильные стили написания кода, а есть и совсем неудовлетворительные. Но даже самый непристойный исходник, если он синтаксически верен, все же должен давать работающий код. У меня есть старая программка, которая сделана была под ТурбоПаскаль в 1993 году. Я адресовал её @ibond - вот Она пока что работает в PascalABC.NET 3.2. И это правильно, так и должно быть. Код жуткий даже по уровню тех лет, потому что была в спешке портирована с Фортран-77. Вот сейчас хочу кое-что там модифицировать, причесать и поместить в пакет численных методов - это поиск минимума функции многих переменным достаточно забавным способом:модифицированным методом Монте-Карло с уточнением решения по Хуку-Дживсу. Изначально было писано в машинных кодах (!) для небольшой ЭВМ “Наири-К” с 2048 машинными словами оперативной памяти и к нам на кафедру очередь стояла по ней считать)))

В версии PascalABC.NET 3.2, сборка 1493 от 07.07.2017 баг с меткой L: var x:=0; пока остался.

Я имел в виду исправление вот этого кода

Тогда приношу извинения.

4 сообщения перенесены в новую тему: Шоб було

Все страньше и страньше! (Л.Кэррол. Алиса в Стране чудес)

С изумлением обнаружил сообщение:

Использование лямбда-выражений в подпрограмме при наличии вложенной подпрограммы запрещено

Ну хорошо, “Меткам - бой”, но зачем же махать саблей направо и налево? Какие-такие ужасы несет в себе локализация процедуры или функции в теле программы? Я не знаю, конечно, что там за такая странная реализация лямбд, требующая делать подобные запреты, но почти уверен, что это новация не должна быть абсолютом.

С удивлением начинаю замечать, что процесс написания программ в последнее время все больше начинает походить на прогулку по минному полю. Разработчики устали или сложность программы перешагнула пределы, в которых с ней могли справиться и приняли решение идти по наиболее простому пути: “не пущать!” *?

Если разработчики начинают безусловно запрещать лямбды, вместо того, чтобы подумать, когда действительно возможны коллизии - это плохой знак. Ну вот кто решил и где написано, что вложить в одну программную единицу другую - это “дурной тон” и должно быть закидано камнями? Почему я должен внутреннюю кухню одной программной единицы делать общей для всего модуля? В современном программировании утверждается, что глобальные объекты - это плохо и нужно максимально использовать локализацию, а тут мы наблюдаем прямо противоположное: какой-то “мелкий потрох” одной процедурки я должен тащить “наверх” и делать видимым во всем модуле. Неправильно это!

@Admin Сборка 1504, жесткий вылет на ровном месте (Win7 x64).

Я наблюдал ошибку с этим сообщением и раньше, но она проявлялась довольно редко и была “плавающей” – напр., случалась иногда при быстром открытии через историю некоторых исходников (в течение нескольких секунд сразу после старта среды). Скажем, было у меня такое одно время с PABCSystem.pas, потом вроде бы прекратилось после того как я отключил code folding в редакторе. Теперь вот падает через раз просто при попытке поставить точку после x в таком фрагменте, но только если я быстро набираю его вручную сразу после запуска среды, а не копирую. Похоже на какой-то race condition или stack overflow из-за рекурсии (причем, вроде даже не в managed коде!)

P.S.: PascalABCCompiler.Core v3.2.0.1504 (09.07.2017), debug version Runtime version: 4.0.30319.42000 OS version: Microsoft Windows NT 6.1.7601 Service Pack 1 Processor count: 2 WorkingSet: 71020 kb

О, коллега, это мой секретный эксклюзивный тюнинг :wink: А иконки такие выдаются вообще только заслуженным пионерам по указу президента, мне вон третью только недавно открыли! :smile:

Понятно, наверно поставили какой-нибудь электронный задачник))

У меня вроде бы и на ХРюше все всегда также было, ну кроме рубиновых звезд в заставке и красных циферок, конечно :slight_smile: Вы что в инсталляторе нарочно все галочки снимаете, там же урезанный “Абрамян” в комплекте идет! Немедленно требуйте отстоя и долива!

@RAlex секретный тюнинг (9,3 КБ)

1 лайк

С удивлением начинаю замечать, что процесс написания программ в последнее время все больше начинает походить на прогулку по минному полю

Ну, использование goto это как раз прогулка по минному полю. Что касается лямбд, то по техническим причинам запрет окончательный. Лямбды еще кое-где запрещены, например во вложенных подпрограммах. И это не разработчики устали, это просто новое иногда плохо ложится на старое.

Рискну утверждать, что запрет это появился не очень давно. Во всяком случае мне что-такое помнится, когда была вложенная подпрограмма и компилятор не вещал дурным голосом, что нельзя использовать ArrGen. Т.е. структура вида

procedure A;

   procedure B;
   begin

   end; // B

begin
   B;
   var x:=ArrGen(5,i->i*i);
   B; 
end;

begin
  A;
end.

у компилятора вопросов не вызывала. Ибо как нет тут вызовов В из ArrGen и повода лямбде что-то там захватывать из B тоже нет.

И в связи с со всем этим у меня вопрос возникает общего плана. Я сейчас пытаюсь сделать библиотеку, где будет много всяких программ. Возможно, очень много. Я не знаю способа раскидать это во множество файлов, чтобы потом подключать единым uses, а делать многоэтажное подобие сишных #include это тоже не метод. Посему получается, что файл должен быть один. И исходник тоже один. Но многие задачи в свою очередь используют различные вспомогательные подпрограммы - вот тут вложенность-то и нужна, чтобы их не светить. Делать из каждой процедуры класс с его локализациями - это не выход. Так мне что, из-за поголовного запрета сожительства лямбд и вложенных программных единиц теперь писать это все в стиле ТурбоПаскаль?

Объявлять их в implementation-части модуля. Если хочется еще вложенности, то в класс.

Когда-то давно висела в TODO реализация import. Это когда в корневой модуль можно импортировать имена из других модулей, чтобы избежать монструозных uses-ов в конечных программах, а подключать только корневой модуль.