Если быстро нажимать на кнопку “Выполнить”, возможно выполнение предыдущей скомпилированной программы, несмотря на то, что в окне IDE есть уже код другой программы с ошибкой.
Только что зависла IDE:
При этом она не отвечая целиком жрала 1 ядро процессора.
Я сделал дамп и посмотрел на стек вызов: stack dump.txt (25.1 КБ)
Похоже там бесконечная рекурсия в анализаторе кода, блокирующая поток окна.
Как насчёт добавить в список проверки здоровья программы метки и слишком большое кол-во вложенных блоков begin-end
?
Метки - да, это хорошо.
Второе я не очень понимаю. В школьных программах такое мало где делается
Так вы же говорили что здоровье это для тех кто переходит со старого стиля? В старых программах часто встречается жуть как тут:
Вы ведь согласны что это всё надо разбивать на подпрограммы?
Это скорее не старые программы, а просто плохой код, не разбитый на процедуры. На настоящий момент Здоровье кода ориентировано на совсем простые задачи и на начинающих школьников - если человек пишет так, то это уже неплохо.
На обсуждение: Автоматический вывод результата выражения, если задано только одно выражение без структуры программы и, как вариант, без последней “;” или последнее выражение не заканчивается “;”
Зачем: быстрый режим калькулятора. Удобно что-то посчитать. (ну еще помечтаю о коротких \ и % вместо div/mod).
Как вариант на будущее:
- вообще не компилировать в файл, а прямо в память через Lambda.Compile (лишь часть IDE?)
- настройка автоматически подключаемых модулей
Дело в том, что выражение может заканчиваться расширением Print, которое само по себе функция.
## ArrRandom(ReadInteger, -99, 99).Sum.Print
Ваши условия выполняются. Все. Одна строка, в конце нет точки с запятой. Выводить сумму еще раз?
По моему @Danov имел в виду что то типа окна с режимом скрипта, как во вкладке Console
в Ctrl+Shift+C браузера. И, вроде, в студии где то есть такое для C#.
Но, таки да, в паскале от этого мало толку, ибо в отличии от C# - для минимальной программы на паскале не надо 20 строк, а в отличии от JS - паскаль не скрипт.
Да, я про режим близкий к интерактивному. Но хотя бы с одной строчкой уже было бы хорошо. Т.к. этот режим есть в Python и C#. Почему бы его в PabcN не запланировать?
Да, хорошая вещь. Работы только много
?:
и if
-выражения не работают в заголовках друг друга, если не ставить скобки:
##
// ok
var s1 := if if true then true else false then 'abc' else 'def';
// ok
var s2 := if (true ? true : false) then 'abc' else 'def';
//Ошибка: Встречено '?', а ожидалось then
var s3 := if true ? true : false then 'abc' else 'def';
// ok
var s4 := (if true then true else false) ? 'abc' : 'def';
//Ошибка: Встречено '?', а ожидалось ';'
var s5 := if true then true else false ? 'abc' : 'def';
Это так задумано?
теперь жди оператор $ =)
$ - это префикс интерполированных строк
Да. Ставьте скобки
Можете дать ответ поподробнее? Как я показал в примере кода - if
-выражение работает внутри заголовка if
-выражения и без скобок. И с ?:
внутри заголовка ?:
, конечно, тоже.
Это не очень интуитивно… И до меня дошло что можно попробовать скобки уже только когда начал все случаи тестировать. Надо хотя бы объясняющую ошибку. Особенно в случае s5
это странно выглядит.
А то вот в тут у меня изначально был случай s3
. Пока не начал разбираться - я написал ?:
внутри ?:
, хотя если внешний тренарный оператор заменить на if
- код выглядит значительно читабельнее.
Вообще то логично предположить, что работать должно и без скобок, потому что вот в этом примере выходит так, что код для s1 эквивалентен коду для s2, а значит выражение для ветки else
в s1 считается полностью до точки с запятой. Cтранно, что для if...then...else
с тернарником в else это не так.
var s1 := if false then 1 else 2 + 3; // 5
var s2 := if false then 1 else (2 + 3); // 5
var s3 := if true then 1 else 2 + 3; // 1
var s4 := (if true then 1 else 2) + 3; // 4
выражение для ветки
else
вs1
считается полностью до точки с запятой
Дело не в потоковом чтении, а в том что у if
, как и у тренарников, приоритет ниже чем у всего остального (кроме скобок). Поэтому если скобок нет - if
-выражение, как и ?:
становится внешним узлом ещё на стадии синтаксиса.
Парсер недописали. Пользуйтесь скобками =).
Мы хотели со временем убирать ? :
Да, старые и новые if выражения не могут быть вложены друг в друга - это дестабилизирует грамматику. В грамматике действительно в новых if не может быть ? :
Если использовать только новые или только старые, то всё ОК.
Вообще, запишите в Issue - я попытаюсь вспомнить, почему в грамматике так сделано. Скорее всего потому что смешение приводит к конфликтам в грамматике, и тогда Issue я закрою. Но если нет, попробую исправить.