Blaise - новый компилятор языка Pascal

with statement Source of hard-to-diagnose symbol resolution bugs; breaks static analysis

Хмм, неосилятор. А так проект годный, будем смотреть.

используется QBE

Должно быть быстро. Догонит ли TurboPascal? :)

используется единая система автоматического управления основанная на подсчете ссылок.

javaw.exe?

Предложен единственный строковый тип заменяющий ShortString, AnsiString, WideString, OpenString и UnicodeString.

сложно, если правильно приводить к UTF - то годно.

Удалены устаревшие операторы ввода/вывода assign, reset, rewrite, blockread и типы file и text.

А blockwrite оставили? :)

Что теперь вместо них?

Предложен единственный строковый тип заменяющий ShortString, AnsiString, WideString, OpenString и UnicodeString.

Как собираются обеспечить обратную совместимость?

походу «Array of byte» во все совместимые поля .
Или как вариант всю «совместимость» выпустят в бескрайние поля и помашут ручкой.

A modern, self-hosting Object Pascal compiler built for the 2020s.

Modern build system. PasBuild with project.xml; no makefiles.

Мда.

Array of byte

Знаешь, или гадаешь?

Догонит ли TurboPascal?

С LLVM бывает быстро?

Перепроверил, но нет – я процитировал не LLVM.

Добавлено определение переменных в месте использования.

Стоит добавить пример: var x := 42; Иначе не сразу поймёшь, что это значит :)

я процитировал не LLVM.

Да, не LLVM. Но я имел в виду: если дальнейшая цель — LLVM, приоритетна ли скорость для разработчика?

Когда как. Вот, например: Kefir 0.5.1 (комментарий).

Вот тут разнообразные размышления о выборе подходов: https://github.com/graemeg/blaise/blob/master/docs/design.adoc

1. Автор за это взялся потому, что в FP не торопятся наводить порядок. Не справляются с обработкой пулл-реквестов (висит ~140).

2. Отказ от совместимости с легаси — в одиночку или небольшой командой это не вытянуть, а сосуществование 5 диалектов совместимости по его мнению осложняет работу над FP.

3. Есть лямбды и дженерики.

4. Почему-то автор очень не любит GUID-ы.

5. Поддержку QBE планируется оставить. Как минимум, для бутстрэппинга.

6. ABI привязаны к QBE (cdecl) и LLVM и несовместимы со старыми. То есть куча наработок с Дельфи и FP оказываются несовместимы.

7. Формат строк:

+--[4 bytes]--+--[4 bytes]------+--[4 bytes]--+--[N bytes]--+--[1 byte]--+
| RefCount    | Length (bytes)  | Capacity    | UTF-8 data  | NUL        |
+-------------+-----------------+-------------+-------------+------------+

Строки нулевой длины тождественны nil, nil можно складывать со строками.

8. Файловый ввод-вывод через потоки, деталей не упомянул.

9. Планируется «миграционный инструмент», который будет автоматически конвертировать программы с FPC и Delphi в новый Паскаль.

10. У автора всего 2 вопроса без ответа: как назвать новый язык, и как организовать хранилище пакетов.

Удален тип object, вместо него предлагается использовать record

Не взлетит.

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

Один Оберон (даже два) от самого Вирта у нас уже есть, зачем ещё один кастрат?

FPC в какой-то степени взлетел не в последнюю очередь благодаря весьма высокой совместимости с Delphi.

Удален оператор with часто приводящий к трудно обнаруживаемым ошибкам

А это вообще жирнота.

https://github.com/graemeg/blaise/discussions/2:

Background information on my development process with AI
I was asked the following question in another forum, and I thought it might be useful to share it here too:

can you provide some ballpark idea of how much guidance Claude required to understand and ultimately write the compiler pieces?

I know you didn’t say it, but let me put it out there: I don’t use «vibe coding,» and I’m not a fan of the term. I rather use AI guided programming and use it as a pair-programmer. I do the architecting and design. I use AI to review my plans and reason through both sides—the pros and the cons. I play to AI’s strengths, as it can analyse faster than any human and play through various scenarios.

Not everything was written by AI, either. The parser and tokeniser code both came from the fpGUI IDE project I previously wrote, which I adapted with minimal effort for the Blaise Compiler. AI implemented the thin C wrapper to bootstrap the System and RTL units, as well as the QBE backend.
…

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

Хмм, неосилятор. А так проект годный, будем смотреть.

with - неплохой синтаксический сахар для хеллоу-ворлдов, но я вот лично даже не знаю, как оно едёт себя с неоднозначными идентификаторами из внешнего уровня вложенности. А если with вложенные друг в друга?

от обработки XML белым мишкам на севере слишком тепло

Целью автора было создать язык, свободный от накопившихся за десятки лет устаревших, и часто дублирующих друг друга, особенностей.

Ещё немного усилий и автор переизобретёт Oberon.

А я не вытерпел и спросил: https://github.com/graemeg/blaise/discussions/1#discussioncomment-16854567.

уоу-уоу, полегче с такими вопросами. Благородные доны могут быть непривычны к такой конкретной и резкой формулировке вопроса…

графического пользовательского интерфейса fpGUI

вот зачем-то посмотрел ;-) я такой лаконичной документации давно не видел. Про каждый класс - автосгенерено от кого он и ВСЁ. https://fpgui.sourceforge.net/apidocs/index.html

то есть видны перспективы Blaise.

PS/ да и фамилия у него забавная :-)

Чтобы добавить в него концепции посвежее?

Или чтобы писать присваивание :=, но объявлять переменные в любом месте.

Для концепций посвежее есть и языки посвежее, с ненастолько уродским синтаксисом.

Да нет, ответил:

XML definitely has its uses. I work with JSON on a daily basis, but not everything needs to be JSON or YAML. For one, the latter two are less descriptive and cannot be self-validated against a schema. Furthermore, JSON still doesn’t support inline comments, which I find very useful in XML.

Ну XML сам по себе не приговор, он в меру избыточен, равно хорошо читаем человеком и машиной (при хорошо спроектированной номенклатуре элементов, что умеют далеко не все, кстати), и для него много хороших инструментов описания, валидации и многого другое.

Другое дело, что класть XML в основу сборочной системы – из этого слишком хорошо торчат уши людей, укушенных Visual Studio.

Другое дело, что класть XML в основу сборочной системы – из этого слишком хорошо торчат уши людей, укушенных Visual Studio.

Компилятор C3 раньше использовал TOML для проектов. Но потом автор переделал на JSON. Но так как в нём тоже были нужны комментарии, то на JSON5.
Вот и думаю, стоит ли писать об этом Грэму? :)

Другое дело, что класть XML в основу сборочной системы – из этого слишком хорошо торчат уши людей, укушенных Visual Studio.

но что-то ведь всё равно надо покласть

Ну, вообще говоря, он частично прав в отношение валидации JSON. Потому что JSON - это тупо сериализированный объект языка JS (прости, госспади). Т.е. подразумевается система типов, которая была в какой-то реализации этого JS. И какая там размерность int, а хрен его знает… А XML схема знает о таких вещах как разрядность и знаковость.

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

Поэтому серьезные вещи, где нужна строгость работы с данными - это XML. А где хуяк-хуяк и в прод - это JS.

Яркий пример говна с морем JSON - vscode.

А про комменты - так тут вообще спору нет, он прав на все 100%.

Яркий пример супер-матёрых и надежных технологий с XML - maven.

Один Оберон (даже два) от самого Вирта

А второй это который?

Но так как в нём тоже были нужны комментарии, то на JSON5. Вот и думаю, стоит ли писать об этом Грэму? :)

Хуже не будет.

Оберон-2.

Удален оператор with

Эх, это одна из паскалевских штук, которой мне больше всего не хватает в плюсах. (Фамилия у товарисча правда хорошая:))

Что-то как-то сомнительно. Ощущение что хотят сделать клон какого-то из других языков но с паскалевским синтаксисом. Не знаю зачем такое.

и как организовать хранилище пакетов.

Мда, и туда же.

development process with AI

А, ну ясно, у меня почему-то такие подозрения и были когда новость читал, но я их отбросил: вроде в среде Паскаля весьма консервативно всё обычно и от них не стоит такого ожидать. Но нет, и туда эта зараза уже проникла.

Not everything was written by AI, either

Да, немножко и сам что-то сделал.

А второй это который?

Таймлайн семейства © (wikimedia.org).

А это вообще жирнота.

Это не жирнота. Width давно объявили legacy, но удалять боятся. :)

Почему-то автор очень не любит GUID-ы.

Он не GUID не любит. Ему не нравится, что паттерн интерфейс в Delphi гвоздями прибит к COM и GUID. Хочет просто интерфейсы.

разработчик графического пользовательского интерфейса fpGUI, системы сборки PasBuild, системы тестирования FPTest и отладчика opdebugger представил Blaise - компилятор для диалекта языка программирования Object Pascal.

В этом списке проектов нехватает ещё одного инструмента - машины времени. Как ещё в 2026 мог появиться новый паскаль, избавленный от легаси и ни с чем не совместимый. Или он её уже изобрел, только не говорит?

Неосилятор

Как и Никлаус Вирт. Так что автор в хорошей компании.

А какой современный язык имеет синтаксис лучше Паскаля? Чтобы знать что с чем сравниваем.

Зачем нужен еще один язык с концепциями сорокалетней давности?

Это не переизобретение велосипеда, а попытка закрыть нишу близкого к индустрии Паскаля (насколько это возможно). Хороший мост для тех, кому нравится Паскаль, но кто не особо готов сопровождать этот выбор в современных системах.

Но вообще, о каких концепциях «сорокалетней давности» идёт речь и что с ними не так? Ведь сам по себе возраст — не приговор.

А я не вытерпел и спросил: https://github.com/graemeg/blaise/discussions/1#discussioncomment-16854567.

Ответ там классный: «XML definitely has its uses»... ;P ;))))))))))))))

А «доны» те там, часом, не «ган...»??? ;))

что умеют далеко не все, кстати

Вот-вот!.. :))

Вот и думаю, стоит ли писать об этом Грэму? :)

А зачем? Если бы ему надо было, он сам узнал бы что используют другие проекты в схожей области.

А сравнивать TOML с XML некорректно. Ближе всего к XML по духу - YAML.