вообще немного странно звучит вопрос. а чем Вас такой вариант развития собственно не устраивает?
Ну так Pascal уже развивал сам же товарищ Никлаус Вирт. Он сделал язык Modula, но после пары экспериментов понял, что чего-то не хватает, забросил его и сделал язык Modula-2, который имел все лучшие черты Pascal, но при этом исправлял его недостатки и добавлял недостающие возможности.
Так вот, если задачей авторов PascalABC было развитие паскаля как языка, почему они стали делать язык именно на основе исходного паскаля, а не уже улучшенной задолго до них версии, которая во всём лучше оригинального паскаля?
… И призадумался сэр Михалкович, не осчастливить ли ему мир версией Modula2.NET, но одолели его сомнения тяжкие и создал он PascalАВС.NЕТ. И увидел он, что это хорошо.
(Хроники ЮФУ. Из неопубликованного)
Я, конечно, совсем не автор, но ответить попробую, как пользователь. Первая реализация .NET-проекта, как известно, появилась в 2007 году. Загляните в школьные учебники и программы тех лет. Что изучалось? Паскаль и Бейсик, кое-где - “сумасшедшие плюсы”. Какая Модула-2, Вы вообще о чем? РАВС, появившись, начал потихоньку отвоевывать себе место у “турбопаскалей”. Ну какой учитель, находясь в здравом уме и трезвой памяти, рискнул бы, имея программу и учебники с ориентацией на Паскаль, начинать использовать эту самую Модулу? По которой, к тому же, отсутствовали учебники в принципе. А РАВС - ну что, для начала он использовался как обычный Турбо Паскаль в режиме практически полной совместимости. ТР был вытеснен прогрессивной русскоязычной IDE и все были довольны. Авторы выиграли время для того, чтобы начинать расширять язык. А Вы сейчас попробуйте учителям предложить Модулу-2 - много желающих найдете, сами как думаете? Несмотря даже на то, что у Вас сам Никлаус Вирт в товарищах ходит…
1 лайк
А в чём может быть причина проблемы, когда при добавлении в WinForms приложение MenuStrip'а весь внешний вид меняется?
Например:
{$reference System.Windows.Forms.dll}
{$reference System.Drawing.dll}
##
var f:= new system.Windows.Forms.Form;
var but:= new System.Windows.Forms.Button;
but.SetBounds(20, 20, 70, 25);
but.Text:= 'кнопка';
but.parent:= f;
//var m:= new System.Windows.Forms.MenuStrip;
system.Windows.Forms.Application.EnableVisualStyles;
system.Windows.Forms.Application.Run(f);
а если раскомментировать строку с MenuStrip, то уже
при этом менюшка даже не была подключена к форме. достаточно неприятное поведение. заметил, что в конструкторе форм такая проблема не выявляется
Как это точно написано! Лучше и не скажешь…
или это очередные проблемы винды и воспроизводится только у меня?
У меня тоже воспроизводится, на Win10x64.
Конструктор форм не делает магию - попробуйте найти минимальный код, исправляющий это поведение.
Естественно я первым делом полез искать отличия. Однако не нашёл ничего подходящего. .inc файл можно сократить до пары строк и это никак не повлияет на отображение. Unit1.Form1.resources тоже ничего не решает, хоть и пытается постоянно залезть в ресурсы. по особому выставленных свойств менюшки или формы тоже не наблюдаю… Может у меня глаз замылился, но я уже склоняюсь к версии про магию.
Возможно эту магию организовывает Unit1.fmabc который просто так уже не прочитать
Ну, даже если магия - её всё равно можно занаучить. К примеру открыв то что должно было быть проектом WF - как обычные .pas файлы, удалив сам файл проекта.
1 лайк
короче, MenuStrip оказался самым капризным контролом и Application.EnableVisualStyles; нужно вызывать до того, как под меню выделяется память, а не после…
Спасибо, что натолкнули на верный путь
Чисто случайно наткнулся на статью, где pabc оказался подопытным кроликом для двух анализаторов c# кода. Статья уже не новая, но возможно будет полезна
не могу сообразить, почему первый print работает, а второй не компилируется
function f(a,b:integer; g:(int,int)->int) := g(a,b);
var g : (int,int) -> int := (a,b) -> a<b ? a : b;
print(f(5,7, g)); // напечатает 5
print(f(5,7, (a,b) -> a>b ? a : b)); // напечатает 7
print(f(5,7, (a,b) -> if a>b then a else b)); // не компилируется
в скобки оберните своё if выражение, а вообще ошибка там должна быть другая
В лямбдах if-выражения конкурировали с if-операторами на уровне грамматики, поэтому их там убрали
3 лайка
Я прочитал, что в PABC поддерживается, и даже рекомендуется описывать счётчик цикла прямо внутри заголовка цикла for.
Но что если в программе встречается несколько циклов for, например несколько проходов одного и того же массива. Разве не будет разумнее описать переменную-счётчик всё таки вне цикла? Например var i: integer; или как-то так и использовать одну и ту же переменную для всех циклов, где нужен счётчик, если они не вложенные.
А какой Вы в этом видите особый смысл? Есть четкое правило для языков программирования: после выхода из цикла значение управляющей переменной не определено. Это означает, что разработчик транслятора имеет право после выхода из цикла значение управляющей переменной не менять, либо занести в нее любой значение. И это может как угодно меняться в каждой новой версии. Следовательно, значение такой переменной после выхода из цикла мы использовать не можем. Тогда что мы выиграем от описания управляющей переменной переменной цикла вне этого цикла?
Сокращение объёма кода и совместимость с нормальным паскалем.
В нормальном паскале локальные переменные описываются в var непосредственно перед begin процедуры или функции (включая безымянную главную процедуру). Вот там объявить один раз i, а при необходимости j или даже k и их использовать во всех циклах в пределах этой процедуры, а за пределами не использовать. Зачем удлинять код переописывая ту же переменную в каждом заголовке каждого цикла? А если какой-то цикл вложенный и его заголовок выполняется множество раз, то это ещё и улучшит быстродействие за счёт отсутствия необходимости пересоздавать переменную на стеке на каждой итерации внешних циклов.
То есть pabc ненормальный паскаль?
На сколько Вы планируете сократить код, убрав var в описании цикла?
В таком случае зачем вообще нужна эта переменная до первого цикла? К чему тянуть за собой наследие древности?
Может быть в качестве оптимизации и имеет смысл.
Вам же никто не запрещает создавать переменную вне описания цикла по тем или иным причинам. Просто в большинстве случаев описывать её по ходу дела как раз таки логичнее.
Ну а писать в старом стиле только в угоду совместимости это уже ваш выбор
В смысле пересоздавать? Это вам не куча, перевыделение памяти на стэке существует только на бумаге. А на практике для этого перевыделения никаких телодвижений не производится.
После таких эпитетов я считаю, что имею дело с троллингом. Троллей я не кормлю. Чава-какава.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021