LINUX.ORG.RU
ФорумTalks

Идея для языка программирования


1

2

Давно меня посещает мысль о «принципиально новой концепции» языка программирования. Интересно насколько нова моя идея и что о ней подумает ЛОР. Я пока не бегу писать компилятор и объявлять его убийцей всех существующих сейчас языков, просто хочу обсудить теоретическую концепцию.

Итак, строго говоря компилятор этого языка не является таковым, это интерпретатор мощного макроязыка. Помимо циклов, ветвлений, подпрограмм, работы с переменными, этот интерпретатор имеет одну важную команду - вывод одного байта в выходной файл.

Для начала делается набор макросов для генерации кодов команд для целевого процессора. Типа такого (знающие ассемблер поймут):

macro mov dest, src {
        db 0x..., ...
}

macro add dest, src {
    ...
}

macro sub dest, src {
    ...
}

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

И таким образом строится набор библиотек макросов в том числе для работы с ООП и т. д.

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

Что же получается в итоге? Не больше, не меньше - универсальный язык программирования. Во-первых, программист может программировать на любом уровне абстракции - от ассемблерных команд до классов и интерфейсов. Причём в случае необходимости смешивать всё это в одном исходнике (например, при разработке драйверов или ядра ОС, да, я понимаю, что злоупотреблять этим нельзя, иначе исходник станет непортабельным и нечитабельным, но мой язык не для быдлокодеров). Во-вторых, в рамках этого языка (при должном качестве макроязыка) будет возможно эмуляция синтаксиса любого существующего сейчас языка.

Так что не считая падения производительности (но собирать то программу надо 1 раз), этот компилятор будет способен заменить все существующие, предоставив дополнительные плюшки.

★★★★★

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

PolarFox ★★★★★ ()
Ответ на: комментарий от x4DA

Нет. В Си, как и других языках, парсинг инструкций и кодогенерация жёстко задана компилятором, в моём же варианте компилятор вообще ничего не знает кроме своего макроязыка. 1 компилятор для всех архитектур и всех языков, просто меняются подключаемые файлы библиотек.

KivApple ★★★★★ ()
Ответ на: комментарий от PolarFox

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

Сам по себе компилятор будет достаточно примитивным - это всего лишь интерпритатор средненького по возможностям языка (даже ООП не нужно). Если грамотно спроектировать структуру макросов то каждый из них по отдельности тоже будет тривиален. А вот всё вместе...

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 1)

А я вот давно думаю о неком кроссплатформенном аналоге LabView, но с нижним уровнем на Java/Javascript. Чтобы перетащил мышой объект, написал скрипт внутри него, соединил мышой такие объекты и радовался готовой проге. Основная задача в том, чтобы это было удобно и наглядно + чтобы можно было запихать «под капот» много уровней абстракции без существенных потерь производительности.

UML-диаграммы были для меня чем-то похожим, но в моём любимом NetBeans их поломали давно.

Sadler ★★★ ()
Ответ на: комментарий от Bad_ptr

Можно конечно написать proof-of-concept... Только на чём? :-)

KivApple ★★★★★ ()

Что же получается в итоге?

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

nanoolinux ★★★★ ()
Ответ на: комментарий от Dark_SavanT

Ещё раз повторю - мой компилятор не умеет строго говоря компилировать. Он не знает даже под какой процессор генерирует код. Всё за него делает библиотека макросов.

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 1)

Идея очень походит на forth, только без RPN.

olibjerd ★★★★★ ()
Ответ на: комментарий от KivApple

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

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

всё таки С на мой взгляд. форт работает на виртуальной стековой машине, не?

nanoolinux ★★★★ ()

1. Ты выносишь то, что должен делать компилятор, в пользовательскую часть ЯП. Это приведет к тормозам: макросы безнадежно медленнее компилятора, написанного на С. Каждый раз развертывать макросы - это тормозная жесть. Если складировать уже разобранные макросы в отдельный файл и использовать его, то тогда следующий вопрос.

2. Как ты планируешь реализовывать оптимизацию (-O2,-O3, -OS и т.п.) в такой модели?

В общем, твоя модель хороша, однако будет очень тормозной.

bk_ ★★ ()

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

note173 ★★★★★ ()
Ответ на: комментарий от KivApple

Сам по себе компилятор будет достаточно примитивным - это всего лишь интерпритатор средненького по возможностям языка (даже ООП не нужно). Если грамотно спроектировать структуру макросов то каждый из них по отдельности тоже будет тривиален. А вот всё вместе...

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

На самом деле нужен язык чтобы можно было на лету менять и переопределять правила лексера/парсера + удобные средства манипуляции АСТом и другими внутренностями компилятора.

Bad_ptr ★★★★ ()
Ответ на: комментарий от bk_

А если он развернёт все макросы перед компиляцией и подсунет компилятору уже готовый код, который компилятор будет оптимизировать? Я так когда-то PBrain Assembler писал. Код, сгенерированный PBrain, был ужасен после преобразования в C. Но после штатной оптимизации компилятором работал весьма шустро.

Sadler ★★★ ()
Ответ на: комментарий от bk_

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

Оптимизация реализуется макросами. Просто надо предусмотреть удобные механизмы для этого. В том числе многопроходность, как у flat assembler.

KivApple ★★★★★ ()
Ответ на: комментарий от KivApple

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

извини, мне не сильно хочется тебе такой вопрос задавать, но ты здоров?

nanoolinux ★★★★ ()
Ответ на: комментарий от note173

Возможность мешать код разных уровней абстракции в одной программе (системщики спасибо огромное скажут, когда попробуют на таком языке написать ОС или драйвер).

Универсальный компилятор для самых разных парадигм - конец холивара какой язык лучше (начало холивара «какой пак макросов лучше»).

KivApple ★★★★★ ()
Ответ на: комментарий от Napilnik

Опять нет. Байткод это тоже компиляция под какую-то архитектуру процессора, просто не существующую на самом деле (для выполнения потом другая программа транслирует этот воображаемый набор инструкций в нужный). Мой компилятор и про байткод не знает ничего.

KivApple ★★★★★ ()
Ответ на: комментарий от Bad_ptr

Ну... тут уже зависит от возможностей макроязыка.

Даже достаточно простой вариант, который я описал, позволил бы сымтировать синтаксис языков вроде Pascal, C, C#, Java и т. д.

KivApple ★★★★★ ()
Ответ на: комментарий от KivApple

Возможность мешать код разных уровней абстракции в одной программе (системщики спасибо огромное скажут, когда попробуют на таком языке написать ОС или драйвер).

Плюсы с паскалем давно это умеют.

Универсальный компилятор для самых разных парадигм - конец холивара какой язык лучше (начало холивара «какой пак макросов лучше»).

Не забывай про синтаксис и совместимость твоих паков макросов.

Napilnik ★★★★★ ()
Ответ на: комментарий от KivApple

Даже достаточно простой вариант, который я описал, позволил бы сымтировать синтаксис языков вроде Pascal, C, C#, Java и т. д.

Сымитируй быструю однопроходную компиляцию не требующую makefile.

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

Плюсы с паскалем давно это умеют.

Когда я пытался написать красивую переключалку задач для своей ОС (не «убийцы Windows», а чисто в образовательных целях), я убедился, что это не так - либо писать кусок кода на чистом Assembler (а структуры то у меня на Си описаны! заново описывать?), либо извращаться нарушая стандарты и рискуя нарваться на глюки при разных версиях и настройках компилятора.

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от Xenius

Именно это я и беру за образец. Выкинуть оттуда генератор кода (оставить только макроязык и директивы объявления данных), немного расширить макроязык (аналога #define не хватает) и переписать на чём-нибудь кросс-платформенным, чтобы не зависеть от i386.

KivApple ★★★★★ ()
Ответ на: комментарий от KivApple

Универсальный компилятор для самых разных парадигм

Набор макросов для каждой будет являться фактически повторением существующих компиляторов.

note173 ★★★★★ ()
Ответ на: комментарий от note173

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

KivApple ★★★★★ ()
Ответ на: комментарий от KivApple

Когда я пытался написать красивую переключалку задач для своей ОС (не «убийцы Windows», а чисто в образовательных целях), я убедился, что это не так - либо писать кусок кода на чистом Assembler (а структуры то у меня на Си описаны! заново описывать?), либо извращаться нарушая стандарты и рискуя нарваться на глюки при разных версиях и настройках компилятора.

Уровней абстракции уже давно больше двух, можно в одной программе прыгать с ООП на процедурщину с goto. СИ для этого не предназначен, он больше для системных либ а не конечных программ.

Napilnik ★★★★★ ()
Ответ на: комментарий от Xenius

Я имел ввиду, что fasm написан сам на себе и запустить его можно только на машине, поддерживающей i386, поэтому без переписывания на любом другом языке его брать нельзя.

Кроссплатформенность у меня будет обеспечиваться сменой набора низкоуровневых макросов на новый. Благодаря стандартизированному интерфейсу высокоуровневые макросы не заметят разницы.

KivApple ★★★★★ ()
Ответ на: комментарий от Xenius

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

KivApple ★★★★★ ()
Ответ на: комментарий от KivApple

Кроссплатформенность у меня будет обеспечиваться сменой набора низкоуровневых макросов на новый. Благодаря стандартизированному интерфейсу высокоуровневые макросы не заметят разницы.

Скачай что-ли исходники FPC и замени понятие «макрос» на «модуль», ты удивишься.

Napilnik ★★★★★ ()
Ответ на: комментарий от KivApple

Но если кроссплатформенность не нужна, а нужна работа с аппаратурой программист наравне с высокоуровневыми командами может вставить и ассемблер, и даже непосредственно машинные коды.

Ого, к фичам современных языков добавили спектрумбейсик, там вставки машинных кодов рулили и педалили.

Napilnik ★★★★★ ()
Ответ на: комментарий от Xenius

Это уже потом его переписать можно, но первую версию придётся делать на чём-то другом, компилировать в уме я не умею и не хочу :-)

KivApple ★★★★★ ()

Наконец-то! Это будет годный компилятор для диагонального программирования!

imul ★★★★★ ()
Ответ на: комментарий от KivApple

Метод раскрутки: пишешь на чём-то другом кусок ядра компилятора, после компилируешь на своём компиляторе его новые версии.

Napilnik ★★★★★ ()
Ответ на: комментарий от Xenius

Зависит от подключенного набора макросов. Можно подключить эмуляцию любого существующего языка, а можно свой собственный синтаксис (и его, как самый правильный, я и хотел бы использовать, но компилятора для него пока нет)

KivApple ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.