LINUX.ORG.RU
ФорумTalks

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


1

2

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

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

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

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

macro add dest, src {
    ...
}

macro sub dest, src {
    ...
}

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

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

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

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

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

★★★★★

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

Ответ на: комментарий от Bad_ptr

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

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

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

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

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

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

ну да чёт типа этого только более удобное и чтобы этот antlr был написан сам на себе и т.д.

Bad_ptr ★★★★★
()

ты изобрел DSL с компиляцией в промежуточный язык? ) в комментах уже наверняка написали про форт, поэтому следующее предложение - .NET. Компилируется в IL (Intermediate Language), позволяет смешивать несколько языков в одном проекте, а возможности ILа позволяют довольно прозрачно выражать понятия всяких извратов. Наш Starview вообще создавался именно с целью писать новые DSL круглые сутки.

stevejobs ★★★★☆
()

Гениально! При компиляции каждого исходника собирать компилятор! Две нобелевки этому господину!

Relan ★★★★★
()

просто каждое ключевое слово на самом деле является вызовом макроса генерации кода

А оптимизацию кода кто делать будет?

Во-первых, программист может программировать на любом уровне абстракции - от ассемблерных команд до классов и интерфейсов

Всё это он может делать на C и C++ с ассемблерными вставками

Причём в случае необходимости смешивать всё это в одном исходнике

Стив Макконнел плачет кровавыми слезами

этот компилятор будет способен заменить все существующие

Тут уже один был такой — игру писал

предоставив дополнительные плюшки

Какие? Ручную кодогенерацию? Мало радости от этого, честно.

fang
()

Это что-то вроде PIR ассемблера для Parrot?

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

Еще раз, тебе говорят, что ты изобрел С.

Он не знает даже под какой процессор генерирует код.

Ассемблер в твоем понимании достаточно платформонезависимый? Так вот:

$ vi hello.c

#include <stdio.h>

void main()
{
        printf ("Cool\n");
        return;
}
:wq

$ gcc hello.c -S

$ cat hello.s

	.file	"hello.c"
	.section	.rodata
.LC0:
	.string	"Cool"
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	andl	$-16, %esp
	subl	$16, %esp
	movl	$.LC0, (%esp)
	call	puts
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE0:
	.size	main, .-main
	.ident	"GCC: (Gentoo 4.6.3 p1.7, pie-0.5.2) 4.6.3"
	.section	.note.GNU-stack,"",@progbits

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

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

Ты будешь удивлен. См. внизу код на С. Так?

#include <cstdio>
#define HelloWorld
#define BEGIN {
#define END }
#define PROGRAM int main()
#define WRITELN(a) puts(a);
 
PROGRAM HelloWorld
 
BEGIN
	WRITELN("Hello, World")
END

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

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

дальше не читал. Ответ очевиден: ненужно.

dikiy ★★☆☆☆
()

Мужики, которые пишут, что ТС изобрел Си — вы совсем упоролись. Он изобрел глючный, медленный и ненужный ассемблер.

// Да и как сказать «изобрел». Лично мне идея вполне очевидна и 100500 раз приходила в голову , например. И так же очевидно, что ненужно.

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

Поздравляю, ты изобрёл Форт.

Присоединяюсь к поздравлениям :)

Xenesz ★★★★
()

Компилятор — это не просто штука, которая делает цепочку синтаксических преобразований от высокоуровневых конструкций к ассемблерным инструкциям. Есть весьма нетривиальные задачи, которые просто так макросами и их подстановками не разрулить. Например, задачи оптимизации. Посмотри хотя бы внутрь LLVM или GCC, чтобы осознать глубину проблемы. Опять же, всякие механизмы нетривиальной типизации: системы вывода типов, частичные специлизации всяких там generic-ов и т.п. Подумай над этим.

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

Я это прекрасно знаю. Более того - его я и беру за образец.

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

Ну да :-)

Только я выкидываю из него собственно ассемблер, зато улучшаю макро :-)

KivApple ★★★★★
() автор топика

Итак, строго говоря компилятор этого языка не является таковым, это интерпретатор мощного макроязыка.

Уже есть NASM.

Не больше, не меньше - универсальный язык программирования.

Смотрим на тот же NASM, видим Fail.

Кстати, по ходу, систему команд x86 ты не знаешь. Там проще будет по битам выводить.

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

«Многие» понятие растяжимое, причины ненужности надуманы.

Я видел какой-то проект на Go, где в качестве идентификатора использовался ⚛ или что-то подобное.

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

Не-не. На конечном пользователе это отразиться не должно. Только на программистах

Хе. Как аукнется — так и откликнется :)

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

Так наоборот программистам будет стимул писать простые и короткие программы, чтобы компиляция шла быстрее. :-)

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

Нда.

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

for (i = 0; i < 0; i++) {}
и такой:
for (i = 0; i < 10; i++) {}
Будут отличаться только тем, что в первом случае стоит ноль, а во втором - 10. Это неверно, в первом случае строчка не генерит вообще никакого кода. Есть и второе соображение: как правило, человек генерит более тормозной машинный код, чем компилятор. Вот чем на самом деле занимается компилятор, он не транслирует конструкции в машинный код, всё на самом деле куда сложнее.
Плюс идеи в том, что синтаксис можно сделать любым. Это интересно, но не более того.

UFO-man
()
Ответ на: комментарий от PolarFox

Я видел какой-то проект на Go, где в качестве идентификатора использовался ⚛ или что-то подобное.

Go почти тотже C, только поновее и непопулярнее, Utf-8 не есть хорошо, IBM 866 наше всё. В принципе, если все нелатинские индентификаторы начинать с Ё то можно избежать путаницы и не нужно будет шепелявить на транслите. Символы за пределами IBM 866 в коде мне не нужны. Англоязычные привыкли к своему транслиту и всех на этот недозвуковой алфавит подсаживают.

Napilnik ★★★★★
()

man forth

man common lisp

man llvm

man front-end/back-end

P.S.: Автор упоролся

nanonymous
()

Мне такая идея приходила лет 12 назад в голову. Вот куда она забрела, после того, как я ее поматросил и бросил-то, оказывается...

shimon ★★★★★
()

Чем существующие макроассемблеры не устраивают?

madcore ★★★★★
()

Просто супер!

Вас уже взяли на работу в Кремниевую долину?

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