В этой статье я хочу осветить основные этапы своей работы и для начала описать созданный концепт языка и его первую реализацию над которой сейчас работаю.
Заранее скажу, что писал весь проект на Free Pascal, т.к. проги на нем можно собрать под огромное число платформ, да и сам компилятор выдает очень даже оптимизированные бинарники (собираю все составляющие проекта с O2 флагом).
Среда выполнения языка
Первым делом стоит рассказать о виртуальной машине, которую мне пришлось писать для выполнения будущих приложений на моём языке. Решил я реализовывать стековую архитектуру, пожалуй, потому что так было проще всего. Ни одной нормальной статьи как мне это сделать на русском я не нашел, так что после ознакомления с англоязычным материалом я засел за проектирование и написание своего велосипеда. Далее буду приводить свои «передовые» идеи и разработки в этом деле.
Реализация стека
Очевидно, во главе ВМ лежит стек. В моей реализации он работает блоками. По сути это простой массив указателей и переменная для хранения индекса вершины стека.
При его инициализации, создается массив на 256 элементов. Если в стек закидывается большее число указателей, то его размер увеличивается на следующие 256 элементов. Соответственно, при удалении элементов из стека — его размер регулируется.
В ВМ используется несколько стеков:
- Основной стек.
- Стек для хранения точек возврата.
- Стек сборщика мусора.
- Стек обработчика try/catch/finally блоков.
Константы и переменные
С этим все просто. Константы обрабатываются отдельным небольшим куском кода и доступны в приложениях в будущем по статическим адресам. Переменные представляют собой массив указателей определенного размера, доступ к его ячейкам осуществляется по индексу — т.е. статическому адресу. Переменные можно помещать в вершину стека или читать её оттуда. Собственно, т.к. у нас переменные по сути хранят указатели на значения в памяти ВМ, то в языке преобладает работа с неявными указателями.
Сборщик мусора
В моей ВМ он полуавтоматический. Т.е. разработчик сам решает когда нужно вызвать сборщик мусора. Работает он не по обычному счетчику указателей, как в тех же Python, Perl, Ruby, Lua и т.д. Он реализован через систему маркеров. Т.е. когда подразумевается, что переменной присваивается временное значение — указатель на это значение добавляется в стек сборщика мусора. В дальнейшем сборщик быстро пробегается по уже готовому списку указателей.
Обработка try/catch/finally блоков
Как и в любом современном языке, обработка исключений — важная его составляющая. Ядро ВМ обернуто в try..catch блок, который может вернуться к исполнению кода, после поимки исключения, поместив в стек немного информации о нем. В коде приложений можно задавать try/catch/finally блоки кода, указывая точки входа на catch (обработчик исключения) и на finally/end (конец блока).
Многопоточность
Она поддерживается на уровне ВМ. Это просто и удобно для использования. Работает без системы прерываний, так что код должен выполняться в нескольких потоках в несколько раз быстрее соответственно.
Внешние библиотеки для ВМ
Без этого никак не обойтись. ВМ поддерживает импорты, подобно тому, как это реализовано и в других языках. Можно написать часть кода на Mash и часть кода на нативных языках, затем связав их в одно целое.
Транслятор с высокоуровневого языка Mash в байткод для ВМ
Промежуточный язык
Для быстрого написания транслятора со сложного языка в код для ВМ я сначала разработал промежуточный язык. Получилось ассемблероподобное страшное зрелище, которое рассматривать здесь нету особого смысла. Скажу лишь то, что на этом уровне транслятор обрабатывает большинство констант, переменных, вычисляет их статические адреса и адреса точек входа.
Архитектура транслятора
Выбрал я не самую хорошую архитектуру для реализации. Транслятор не строит дерево кода, как подобает прочим трансляторам. Он смотрит на начало конструкции. Т.е. если разбираемый кусок кода имеет вид «while <условие>:», то очевидно, что это конструкция while цикла и обрабатывать её нужно как конструкцию while цикла. Что-то вроде сложного switch-case.
Благодаря такому архитектурному решению транслятор получился не очень уж быстрым. Однако простота его доработки возросла в разы. Нужные конструкции я добавлял быстрее, чем мог остыть мой кофе. Полная поддержка ООП и вовсе была реализована менее чем за неделю.
Оптимизация кода
Тут конечно можно было реализовать и лучше (и будет реализовано, но позже, как руки дойдут). Пока что оптимизатор только умеет отсекать неиспользуемый код, константы и импорты от сборки. Также несколько констант с одинаковым значением заменяются одной. Вот и все.
Язык Mash
Основная концепция языка
Основной идеей было разработать максимально функциональный и простой язык. Считаю, что со своей задачей разработка справляется на ура.
Блоки кода, процедуры и функции
Все конструкции в языке открываются двоеточием : и закрываются оператором end.
Процедуры и функции объявляются как proc и func соответственно. В скобках перечисляются аргументы. Все как у большинства других языков.
Оператором return можно вернуть из функции значение, оператор break позволяет выйти из процедуры/функции (если он стоит вне циклов).
Пример кода:
...
func summ(a, b):
return a + b
end
proc main():
println(summ(inputln(), inputln()))
end
Поддерживаемые конструкции
- Циклы: for..end, while..end, until..end
- Условия: if..[else..]end, switch..[case..end..][else..]end
- Методы: proc <имя>():… end, func <имя>():… end
- Label & goto: <имя>:, jump <имя>
- Enum перечисления и константные массивы.
Переменные
Транслятор их может определять автоматически, либо если разработчик пишет var перед их определением.
Примеры кода:
a ?= 10
b ?= a + 20
var a = 10, b = a + 20
Поддерживаются глобальные и локальные переменные.
ООП
Ну вот и подобрались мы к самой вкусной теме. В языке Mash поддерживаются все парадигмы объектно-ориентированного программирования. Т.е. классы, наследования, полиморфизм (в т.ч. динамический), динамические автоматические рефлексия и интроспекция (полная).
Без лишних слов, лучше просто приведу примеры кода.
Простой класс и работа с ним:
uses <bf>
uses <crt>
class MyClass:
var a, b
proc Create, Free
func Summ
end
proc MyClass::Create(a, b):
$a = new(a)
$b = new(b)
end
proc MyClass::Free():
Free($a, $b)
$rem()
end
func MyClass::Summ():
return $a + $b
end
proc main():
x ?= new MyClass(10, 20)
println(x->Summ())
x->Free()
end
Выведет: 30.
Наследование и полиморфизм:
uses <bf>
uses <crt>
class MyClass:
var a, b
proc Create, Free
func Summ
end
proc MyClass::Create(a, b):
$a = new(a)
$b = new(b)
end
proc MyClass::Free():
Free($a, $b)
$rem()
end
func MyClass::Summ():
return $a + $b
end
class MyNewClass(MyClass):
func Summ
end
func MyNewClass::Summ():
return ($a + $b) * 2
end
proc main():
x ?= new MyNewClass(10, 20)
println(x->Summ())
x->Free()
end
Выведет: 60.
Что на счет динамического полиморфизма? Да это же рефлексия!:
uses <bf>
uses <crt>
class MyClass:
var a, b
proc Create, Free
func Summ
end
proc MyClass::Create(a, b):
$a = new(a)
$b = new(b)
end
proc MyClass::Free():
Free($a, $b)
$rem()
end
func MyClass::Summ():
return $a + $b
end
class MyNewClass(MyClass):
func Summ
end
func MyNewClass::Summ():
return ($a + $b) * 2
end
proc main():
x ?= new MyClass(10, 20)
x->Summ ?= MyNewClass::Summ
println(x->Summ())
x->Free()
end
Выведет: 60.
Теперь уделим минутку интроспекции для простых значений и классов:
uses <bf>
uses <crt>
class MyClass:
var a, b
end
proc main():
x ?= new MyClass
println(BoolToStr(x->type == MyClass))
x->rem()
println(BoolToStr(typeof(3.14) == typeReal))
end
Выведет: true, true.
Об операторах присваивания и явных указателях
Оператор ?= служит для присвоения переменной указателя на значение в памяти.
Оператор = изменяет значение в памяти по указателю из переменной.
И теперь немного о явных указателях. Добавил я их в язык чтобы они были.
@<переменная> — взять явный указатель на переменную.
?<переменная> — получить переменную по указателю.
@= — присвоить значение переменной по явному указателю на неё.
Пример кода:
uses <bf>
uses <crt>
proc main():
var a = 10, b
b ?= @a
PrintLn(b)
b ?= ?b
PrintLn(b)
b++
PrintLn(a)
InputLn()
end
Выведет: какое-то число, 10, 11.
Try..[catch..][finally..]end
Пример кода:
uses <bf>
uses <crt>
proc main():
println("Start")
try:
println("Trying to do something...")
a ?= 10 / 0
catch:
println(getError())
finally:
println("Finally")
end
println("End")
inputln()
end
Планы на будущее
Все присматриваюсь да присматриваюсь к GraalVM & Truffle. У моей среды выполнения отсутствует JIT компилятор, так что в плане производительности он пока что может составлять конкуренцию разве что питону. Надеюсь, что мне окажется под силу реализовать JIT компиляцию на базе GraalVM или LLVM.
Репозиторий
Вы можете поиграться с наработками и проследить за проектом сами.
Сайт
Репозиторий на GitHub
Спасибо, что дочитали до конца, если вы это сделали.
Комментарии (185)
mobi
02.01.2019 12:06+1оператор break позволяет выйти из процедуры/функции (если он стоит вне циклов)
А что при этом вернет функция?
RoPi0n Автор
02.01.2019 13:58Ничего. Но можно в стек закинуть что-нибудь если уж нужно сильно. Просто: push
Amomum
02.01.2019 17:18+9Эээ, а чему тогда будет равна переменная, которая принимает возвращаемое значение? Случайному значению со стека?
RoPi0n Автор
02.01.2019 20:15Эээ, а чему тогда будет равна переменная, которая принимает возвращаемое значение? Случайному значению со стека?
Если ожидается значение от функции, а в функции оно в стек не ложится, то да. Либо значение с вершины стека, либо access violation.
Amomum
02.01.2019 23:54+1А чем вы руководствовались, когда давали оператору break такой функционал? Ни в одном известном мне языке break такого не делает.
RoPi0n Автор
03.01.2019 12:23Если использовать exit внутри циклов, то это черевато мусором в стеке.
Amomum
04.01.2019 18:40У вас еще и exit есть, помимо return и break?
RoPi0n Автор
04.01.2019 19:18Нет, но могу добавить :)
Amomum
04.01.2019 19:19Лучше поясните, о чем был предыдущий комментарий :)
RoPi0n Автор
04.01.2019 19:31Добавил в язык оператор exit для выхода из процедур или функций.
Теперь break позволяет выйти только из циклов, case и try/catch блоков.Amomum
04.01.2019 19:32Так, а exit возвращает значение или нет? И чем он от return'a отличается?
RoPi0n Автор
04.01.2019 19:33Отличается тем, что ничего не возвращает.
Amomum
04.01.2019 19:36+1Погодите, то есть у вас был break из функций, который ничего не возвращал, а теперь у вас есть exit из функций, который ничего не возвращает? :D
И точно так же можно словить мусорное значение со стека? Чем это лучше тогда?
Зачем вообще из функций возвращаться, не возвращая значение?RoPi0n Автор
04.01.2019 19:46Можно даже из процедуры вернуть значение, если сильно нужно.
Пример:
proc test(): push 123 end ... x ?= test()Amomum
04.01.2019 19:50+1А как вызывающий должен догадаться, что функция не возвращает значения, если это функция, а не процедура (раз уж у вас есть разделение на функции и процедуры)?
К тому же, внутри функции может быть ветвление и по одной ветке значение возвращается, а по другой — нет.
Извините, но по-моему вы как будто специально footgun в язык вносите такими фишками :)
gnomeby
02.01.2019 12:45+2Какую задачу решает ваш язык программирования лучше чем любой другой?
shai_hulud
02.01.2019 12:53+4Я думаю, задачу изучения компиляторов и VM RoPi0n. Ведь если бы цель была в создании «языка решения X задач», то выбран был бы какой нибудь LLVM, а лексинг/парсинг отдан сторонней либе. Ведь это затратные по времени пункты, которые не релевантны цели. А автор решил сам всё писать.
RoPi0n Автор
02.01.2019 14:01+2Это пожалуй самый верный ответ который только можно дать на этот вопрос. Как много можно найти мануалов по построению современных ЯП на русском языке? В рунете не особо много людей, кто озадачивал себя написанием языка.
pnovikov
03.01.2019 14:18ИМХО, потому что это никому не нужно. Делать ещё одного "Неуловимого Джо", если ты не MS или Oracle и даже не JetBrains — такая себе идея. Разве что только поиграться. Но как мне кажется, гораздо больше опыта можно получить в попытках написать каких-нибудь расширений для уже существующих языков.
RoPi0n Автор
04.01.2019 15:24Каждому своё. Многие ЯП писались не крупными компаниями, а инициативными людьми.
eclipse20
04.01.2019 16:53Но на Гитхабе вы пишете следующее:
Основные цели и идеи проекта:
1) Создать максимально простую для разработчиков (и главное — для конечных пользователей!) среду разработки и выполнения кода.
2) Создать максимально простой, удобный, гибкий, функционально полный, кроссплатформенный и быстрый язык.
На Гитхабе пишете:
Нетипизированный кроссплатформенный язык программирования, поддерживающий базовые парадигмы ООП.
а здесь в статье:
В языке Mash поддерживаются все парадигмы объектно-ориентированного программирования.
Так где правда, в статье или на Гитхабе? :)
phantom-code
02.01.2019 14:05+2Лексер — весьма тривиальная вещь. Не особо сложнее, чем описать набор правил для того же flex. Парсер контекстно-свободной грамматики тоже не является rocket science. Другое дело, что при разработке парсера, придется в любом случае как-то описывать грамматику, что по сути эквивалентно созданию входных данных для bison. Тем не менее, при использовании готовых библиотек-построителей персеров, вы становитесь зависимы от них при весьма сомнительном уменьшении времени на разработку. Насколько оправдана такая зависимость — решать только вам.
KvanTTT
02.01.2019 14:31Тем не менее, при использовании готовых библиотек-построителей персеров, вы становитесь зависимы от них при весьма сомнительном уменьшении времени на разработку.
Сможете доказать этот тезис? Глядя на грамматики SQL (T-SQL, PL/SQL, MySQL) с кучей ключевых слов в такое что-то не верится...
phantom-code
02.01.2019 16:01В случае реализации парсера самостоятельно, придется написать больше текста и потратить больше времени — это правда. Но время, необходимое на написание самого парсера, сильно меньше времени, необходимого на реализацию остальных компонентов компилятора/интерпретатора/VM. Тем более, что многие элементы парсера похожи, копипаст хорошо ускоряет процесс. Доказать я вам ничего не могу, мои высказывания основаны на небольшом личном опыте. Ученых степеней по теме не имею, в разработке серьезных компиляторов участия не принимал.
0xd34df00d
02.01.2019 18:15+1По опыту разработки парсеров, вещи вроде attoparsec/trifecta (на хаскеле) или boost.spirit (на плюсах) очень помогают в повышении эффективности разработки и, что важнее, поддержки.
Особенно когда вам нужно сделать хорошие сообщения об ошибках, тут trifecta вообще на высоте.phantom-code
02.01.2019 18:32+1При реализации парсера вручную, хорошие сообщения об ошибках получатся без проблем сами собой.
Тут весь вопрос в том, какая именно у вас задача. Если требуется каждый день писать парсер для чего-то нового, конечно вариант готовой либы заруливает все остальное.0xd34df00d
02.01.2019 18:35+1Сообщения об ошибках в парсерах — это на самом деле не самая тривиальная задача для хоть немного сложного языка. Могу только снять шляпу, если у вас полезные для пользователей сообщения об ошибках получаются сами.
phantom-code
02.01.2019 18:48Я не работал над серьезными компиляторами (честно говоря никогда не слышал о коммерческой разработке компиляторов в РФ), поэтому не претендую на объективную истину. В моих велосипедах контекст ошибки был всегда понятен и проблемы сформировать хорошее сообщение с указанием точной позиции в тексте не возникало.
RoPi0n Автор
02.01.2019 18:54+3Есть Jet Brains, Excelsior — уже как минимум 2 ру компании, которые занимаются разработкой компиляторов.
phantom-code
02.01.2019 18:56Да, вы правы, о JetBrains я забыл. Можно сказать, что они вообще специализируются на парсерах.
AnutaU
02.01.2019 12:57+7Мне хотелось создать на мой взгляд максимально простой, функциональный и удобный язык
Когда видишь в описании языка слово «функциональный», ожидаешь увидеть нечто другое.fukkit
02.01.2019 13:41+1Некоторые уже настолько упоролись, что и на «функциональные обязанности» в должностной инструкции будут триггерить.
RoPi0n Автор
02.01.2019 14:04Ну, под функциональностью я подразумевал гибкость и потенциал языка. Как по мне, все очень даже хорошо получилось в этом плане. Есть поддержка взаимодействия с натив кодом через простые и удобные импорты, поддержка callback-вызовов ВМ кода из внешних методов, простая в использовании многопоточность, неявные указатели на каждом шагу (а это очень даже как по мне удобно).
TheShock
03.01.2019 08:49Ну, под функциональностью я подразумевал гибкость и потенциал языка
Подошло бы слово «гибкий»)
Jamdaze
02.01.2019 13:35+2Лет 10 программирование моё основное «хобби».
И что я понял за это время — ещё один способ интерпретирования текстового файла (plain text) не нужен.
Нужен качественный переход, например как переход от текста к гипертексту.
И самое главное это ориентированность на средства разработки, а не на то какой последовательностью символов заканчивается блок кода\функции\etc.
В общем, если уж решили потратить свое время и силы, могли бы запилить дополнительный уровень абстракции между бэкендом llvm\gcc и ide.
Доступны десятки потоков, гигабайтый памяти, а мы всё мусолим эти текстовые файлы, ну бред же.
Сколько лет уже с++, а до сих пор я не видел ide с его полной поддержкой.
Ну вот вы сделали язык, а где ide, которая будет разматывать ваш синтаксис в абстрактное дерево? Как рефакторить код на вашем языке?RoPi0n Автор
02.01.2019 13:56ide тоже реализована. Если бы вы чекнули сайт или репозиторий, то увидели бы её. Вы ожидаете от меня супер новую и мощную технологию с комплексом инструментария, так может поможете мне?) Репозиторий открыт, код доступен всем для ознакомления. Если у вас ести идеи по проекту и руки дотянутся до их реализации, то жду ваши пулы на github.
Проект изначально не был нацелен на обход современных языков по производительности или в чем-либо. Хотелось попробовать самому реализовать свой ЯП с полностью моими архитектурными решениями и концептами. Получился простой и гибкий язык, как по мне. В ВМ отсутствуют лишние абстракции. Поддержка всех парадигм ООП реализована.
Написал же, что хочу на GraalVM либо на LLVM направить транслятор. Тут как бы вопрос времени и того, как скоро я наковыряю достаточно информации для реализации транслятора под целевую ВМ. Если буду копать в сторону LLVM, то поддержка GraalVM уже и так будет, т.к. она может и биткод LLVM выполнять. Да и плюсом WebAssembly подтянется.
Стоит понимать, что архитектуры всех этих вм, в т.ч. и моей реализации по сути схожи. Разница лишь в том, что LLVM и GraalVM заточены под работу со строгой типизацией, а моя ВМ наделена функционалом для автоматического приведения типов и выделения/перевыделения памяти, т.к. нетипизированный язык же писал изначально.
Идея переноса проекта на новые ВМ у меня появилась не так уж и давно, когда я в серьез задумался над оптимизацией. (К слову, мб месяц назад ВМ выполняла код примерно в 8-10 раз медленней чем сейчас).
AnutaU
02.01.2019 15:26+2У вас немного кони и люди смешались. LLVM — это не ВМ.
RoPi0n Автор
02.01.2019 15:32-1LLVM (Low Level Virtual Machine) — это ВМ с JIT компилятором на борту.
Исполняет она абстрактный упакованный биткод. Над LLVM существует куча надстроек и окружений (возможно вы думали именно о них, когда писали этот комментарий). Ничего у меня не путается.ZaMaZaN4iK
02.01.2019 15:36+5Но это не отменяет того факта, что LLVM — не ВМ.
RoPi0n Автор
02.01.2019 15:44-3ru.wikipedia.org/wiki/LLVM
Универсальная система анализа, трансформации и оптимизации программ, реализующая виртуальную машину с RISC-подобными инструкциями.ZaMaZaN4iK
02.01.2019 15:56+3А давайте пройдём на официальный сайт LLVM: llvm.org
Почитаем. А потом на главной странице поищем слово «virtual». Их там два — одно это сразу "…. Despite its name, LLVM has little to do with traditional virtual machines. ...".
Второе — это klee, действительно ВМ. Только вот это проект на базе LLVM, а не сам LLVM.RoPi0n Автор
02.01.2019 16:04-1Слов «virtual» там не так уж и много, потому что их роль выполняют другие формулировки.
LLVM может использоваться, как компилятор абстрактного биткода в нативный. Так что это по-сути сложная ВМ.
RoPi0n Автор
02.01.2019 15:49-7Достаточно уметь читать и гуглить, чтобы разобраться с тем, что такое LLVM. Можно даже скачать проект и покопаться в нем, если у вас есть на это время.
К сожалению, ваше мнение не обоснованно и не является весомым. Оно скорее показывает, что один из двух требуемых навыков у вас отсутствует.
Для вашего блага могу посоветовать вам для ознакомления азбуку и/или поисковую строку google.com
AnutaU
02.01.2019 15:39+2The name LLVM was originally an initialism for Low Level Virtual Machine. This initialism has officially been removed to avoid confusion, as the LLVM has evolved into an umbrella project that has little relationship to what most current developers think of as virtual machines
RoPi0n Автор
02.01.2019 15:59-2llvm.org
The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Despite its name, LLVM has little to do with traditional virtual machines. The name «LLVM» itself is not an acronym; it is the full name of the project.
…
In addition to official subprojects of LLVM, there are a broad variety of other projects that use components of LLVM for various tasks. Through these external projects you can use LLVM to compile Ruby, Python, Haskell, Java, D, PHP, Pure, Lua, and a number of other languages. A major strength of LLVM is its versatility, flexibility, and reusability, which is why it is being used for such a wide variety of different tasks: everything from doing light-weight JIT compiles of embedded languages like Lua to compiling Fortran code for massive super computers.
LLVM — это JIT компилятор с абстрактного биткода в машинный, для его дальнейшего выполнения. Т.е. этот проект можно рассматривать как ВМ. Также он может компилировать абстрактный биткод в натив. Но это уже немного другое.
Не пойму, от чего так вы зацепились за это.alhimik45
02.01.2019 17:16+2LLVM — это JIT компилятор
Вот именно. А не виртуальная машина
А то так можно сказать, что "GCC — это компилятор C в машинный код, для его дальнейшего выполнения. Т.е. этот проект можно рассматривать как ВМ". Чувствуете нелогичность?
RoPi0n Автор
02.01.2019 20:03+3Отличие GCC от LLVM в том, что GCC компилирует C/C++ в нативный код, а LLVM может выполнять абстрактный биткод и во время выполнения компилировать его в машинный для оптимизации. Так что я считаю, что LLVM — это ВМ, подобно JVM, Parrot и прочим.
alhimik45
02.01.2019 20:30Почитал, действительно в составе LLVM есть тулза с помощью которой можно запустить биткод. Думаю все придрались именно к определению
LLVM — это ВМ
LLVM — это всё таки "a collection of modular and reusable compiler and toolchain technologies". И одной из технологий (не самой популярной, кмк) является запускалка биткода.
Jamdaze
02.01.2019 16:01+3Объём проделанной вами работы, поражает.
Просто жаль что такие усилия не оставят инфраструктуры для будущего.RoPi0n Автор
02.01.2019 16:35+2Самое главное, что эти усилия оставят для будущего — это мои приобретенный скилл и опыт (и возможно что-то большее, если дойдут руки до более детального изучения LLVM или GraalVM). Проект само собой не с первой попытки был реализован. К самой оптимальной на мой взгляд архитектуре ВМ я пришел далеко не сразу. Но все решения и реализации мне пришлось проектировать и кодить самому. Этот процесс был весьма сложным и интересным.
sumanai
03.01.2019 12:57ide тоже реализована.
ИМХО, сейчас актуально реализовывать что-то типа Langserver.org, намного удобнее для разработчиков.
NeoCode
02.01.2019 14:05А какие вам нужны файлы? Двоичные чтоли?
На самом деле правильный подход — оставить текстовые файлы, но предусмотреть синтаксис настолько простой и эффективный, чтобы анализ и построение синтаксического дерева выполнялись буквально «на лету» в любой IDE начиная от профессиональных систем и заканчивая сверхлегкими блокнотоподобными. В С++ этого нет, потому что С++ создавался тогда когда об этом не задумывались.Jamdaze
02.01.2019 14:56Я думаю лучше текстовый формат файлов, будет проще использовать системы контроля версий.
А что если просто сохранять дерево в json\xml?RoPi0n Автор
02.01.2019 15:35Стоит понимать, что дерево кода можно строить не полное, дабы сэкономить время анализа кода (и сохранять не обязательно никуда его). Да и многопоточность никто не мешает использовать, чтобы анализировать все «на лету».
atamanenko
02.01.2019 22:22А что если просто сохранять дерево в json\xml?
Это называется придумывать решение, сначала придумав инструмент. Надо наоборот
Чем json с xml полезнее?
AnutaU
02.01.2019 15:24+5На самом деле правильный подход — оставить текстовые файлы, но предусмотреть синтаксис настолько простой и эффективный, чтобы анализ и построение синтаксического дерева выполнялись буквально «на лету» в любой IDE начиная от профессиональных систем и заканчивая сверхлегкими
И получается Lisp!
oisee
02.01.2019 19:18Отож! Вот Sinclair Basic токенизировал все ключевые слова — опечатку было сделать невозможно! Встроенный Autocomplete с IntelliSense в 1982 году!
DaneSoul
03.01.2019 09:49+1но предусмотреть синтаксис настолько простой и эффективный, чтобы анализ и построение синтаксического дерева выполнялись буквально «на лету» в любой IDE
Синтаксис должен быть максимально простой и эффективный для чтения, написания и понимания ПРОГРАММИСТОМ, а не IDE.
IDE может быть очень сложной «под капотом» — это не помешает разрабатывать на языке, в конце концов, таких IDE много не надо, достаточно одной хорошей кросс-платформенной.
rustacean137
04.01.2019 17:04ИМХО, не стоит чрезмерно упрощать ЯП, лучше когда IDE будут поддерживать и развивать LSP, а ЯП пуст сам реализует LSP сервер.
amarao
02.01.2019 15:01+2Э… Язык в 2019 году без алгебраических типов, pattern matching'а и исчерпывающих перечислений?
RoPi0n Автор
02.01.2019 15:08Первое и второе возможно будет реализовано позже. У меня не так уж и много времени, чтобы круглосуточно кодить.
Перечисления в языке есть:
enum MyEnum [meA, meB, meC, meD]
Также поддерживается объявление массивов, содержащих перечень типов данных. Пример:
a ?= [10, 20, 3.14, "Test", new MyClass(1, 2, "Test"), func1(10, 20, 3.14)]
Из не упомянутого — также в языке поддерживается реализация методов с неограниченным числом аргументов.
func SummAll(...): ... end ... r ?= SummAll(10, 20, 3.14, "337", 0xFF)
Для получения аргументов есть переменная argcount — хранящая число переданных аргументов и стек — аргументы ложатся в обратном порядке, соответственно принять в методе их весьма просто.amarao
02.01.2019 15:14+2Отлично, а как бы теперь обработать ситуацию, что MyEnum игнорируется? Основная польза от алгебраических типов не в том, что кто-то может положить перечисления, а в том, что попытка использовать перечисления требует полного исчерпания этого перечисления при match.
RoPi0n Автор
02.01.2019 15:37-1У вас есть идеи для реализации? Или может у вас имеется готовое решение, которое идеально встанет в код проекта? Пожалуйста — github.com/RoPi0n/mash-lang, жду pull
amarao
02.01.2019 15:43+1На паскале? Спасибо, как-нибудь без.
Готовое решение есть.
Грамматрика: github.com/rust-lang/rust/blob/master/src/grammar/parser-lalr.y#L1713
Имплементация match: github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/_match.rs
0xd34df00d
02.01.2019 18:28Основная польза от алгебраических типов не в том, что кто-то может положить перечисления, а в том, что попытка использовать перечисления требует полного исчерпания этого перечисления при match.
Я не уверен, что это хорошая идея в языке без зависимых типов или хотя бы GADTs + DataKinds.
amarao
02.01.2019 18:43В расте прекрасно без GADT приносит массу пользы.
0xd34df00d
04.01.2019 15:29Я не спорю с тем, что оно способно приносить массу пользы. Однако, как вы обрабатываете случаи, когда семантика окружающего кода означает, что некоторые варианты ADT в данном месте невозможны, и паттерн-матчиться на них не имеет смысла? Не ленитесь создавать новый ADT или просто пишете panic/error/что там в расте?
amarao
04.01.2019 15:50В Rust есть (для наиболее распространённого типа Result) синтаксический сахар — знак вопроса, он говорит "передать ошибку дальше по стеку, т.е. вернуть
Result(Err(_)), или.unwrap(), который паникует, если неOk(т.е.Err).
Вообще, если у вас по типу не пологается какого-то значения, зачем оно в типе присутствует?
0xd34df00d
04.01.2019 16:36В Rust есть (для наиболее распространённого типа Result) синтаксический сахар — знак вопроса
А для других типов?
Но это, кстати, немножко не то. Это просто сахар поверх частного случая для do-нотации.
Вообще, если у вас по типу не пологается какого-то значения, зачем оно в типе присутствует?
Потому что оно не полагается вот прямо в этом месте (может, его вызывающий код уже обработал, например). Через GADT + поднятый на уровень типов ADT для возможных состояний это выразить куда проще и легче.
TheShock
03.01.2019 08:53Э… Язык в 2019 году без алгебраических типов, pattern matching'а и исчерпывающих перечислений?
Кстати, что мешает добавить алгебраические типы данных в более старые языки? Вроде того же c#? Я вот недавно решал одну задачу и очень жалел, что таких нету.
Akon32
02.01.2019 16:11+2Немного критики синтаксиса:
1) Двоеточия для управляющих структур излишни. Можно и без них. Особенно это заметно в try, но и в других конструкциях тоже не нужны.
try: ... catch: ... finally: ... end
Без двоеточий это выглядело бы чуть проще.
2) Не вижу цикла с постусловием, аналог do..while или repeat..until.
3) Разделение proc-func, наверно, излишне.
4) Знак $ в переменных и методах лишний.
5) Синтаксисa ?= 10непонятен для неподготовленного человека.
6) Скобки вuses <bf>лишние.
7) Можно придраться к->, точка всё же короче.
8) Оператор@=(разыменование с присваиванием) нелогичен. В паскале для этого используютсяvariable ^ := value, у вас почему-то @ означает то взятие указателя, то разыменование.
9) Чем отличаются jump и goto? Если ничем, достаточно одного.
10) Самое главное. Отдельные объявления и определения классов совершенно не нужны.
И ещё немного замечаний. Типизация, я так понимаю, динамическая? Генераторы (yield), как в питоне — хорошая штука, рекомендую добавить. "Полуавтоматический" сборщик мусора будут постоянно забывать вызывать, это странная идея.
В языке Mash поддерживаются все парадигмы объектно-ориентированного программирования. Т.е. классы, наследования, полиморфизм (в т.ч. динамический), динамические автоматические рефлексия и интроспекция (полная).
Это не парадигмы. ООП и есть парадигма. И если уж говорить о всех идеях из ООП, не вижу поддержки мультиметодов.
RoPi0n Автор
02.01.2019 16:311) Мне наоборот кажется, что немного строгости языку не помешает, а то будет совсем уж аморфный синтаксис :)
2) Вместо do..while в Mash реализован until <условие>:… end
Пример:
until a > 0: a-- end
Получается как в паскале цикл.
3) Возможно. Но так же код представляется более строго и однозначно. Если разработчик бегло осматривает код, то ему будет удобнее сразу видеть, процедура перед ним или функция.
4) Знак $ заменяет «this->» — он нужен только для обращения к классовым методам и переменным.
5) Возможно. Но обычно люди в нашей сфере готовы к многому.
6) В uses можно добавлять файл через "<имя файла>" или же через <>. В первом случае, транслятор будет искать файл с исходниками возле собираемого файла. Во втором — в папке inc возле транслятора.
7) Ну, тут уж кому как.
8) Ну, как сделал…
9) goto нету, есть jump.
10) Мне наоборот больше привлекателен код, когда объявление классов и определения раздельны. Если разработчик будет знакомиться с незнакомыми ему либами, то думаю, ему будет удобнее смотреть на объявление классов без их реализации.
Да, типизация динамическая. Полуавтоматический сборщик мусора — наоборот как по мне забавная штука. Всегда знаешь когда мусор очищен. Сам контролируешь это. Генераторы конечно попробую реализовать в будущем, вещь несомненно полезная.
Я рассматривал ООП как набор основных парадигм. Мультиметоды и шаблоны считаю немного лишними в языке с динамической типизацией и интроспекцией.
Можно typeof() или x->type использовать.AnutaU
02.01.2019 16:35until a > 0: a-- end
Какова семантика? Условие проверяется до выполнения тела цикла или после? Тело цикла выполняется в случае, если условие истинно или ложно?
RoPi0n Автор
02.01.2019 17:11Условие проверяется после выполнения итерации. Цикл выполняется пока условие ложно. Как в pascal сделал это. Только until вверх объявления цикла перенес.
amarao
02.01.2019 17:12+10Большой WTF для любого, читающего код. Написано в одном месте, проверяется в другом.
Akon32
02.01.2019 17:24+1Это фейл. Синтаксис until(cond){… } читается как while (! cond) {… }, то есть цикл с предусловием. Рекомендую как-то переставить условие в конец.
Ещё к паскалевскому repeat… until можно придраться в том ключе, что while выполняется пока условие истинно, а repeat..until — пока условие ложно. С-подобное do… while в этом плане логичнее.
Кажется, в visual basic я видел все варианты: while(){}, do{}while(), until(){}, do{}until() (но синтаксис там чуть другой).
AnutaU
02.01.2019 18:11+3Цикл выполняется пока условие ложно.
Тогда не стоит в качестве примера такой конструкции приводить бесконечный цикл.
mas
04.01.2019 18:57JFYI в J парой к while идёт whilst. Получается очень красиво: во-первых, это тоже английское слово, тоже while; во-вторых, оно в J расшифровывается как while-s-t = while + skip test, т.е. тест в первый раз не выполняется.
Akon32
02.01.2019 17:37+2Могу слегка одобрить только $ в качестве замены this->. 2,8,10 категорически не одобряю, они не логичны (ну, ничего страшного, учебный язык). Остальные пункты вызывают меньше WTF.
Я рассматривал ООП как набор основных парадигм.
"Парадигма" — это и есть набор. "Совокупность идей и понятий" (см.вики). ООП как набор идей — парадигма, отдельные идеи до "парадигмы" не дотягивают. Высказывание в вашем варианте режет глаз.
michael_vostrikov
02.01.2019 17:41+2Если разработчик бегло осматривает код, то ему будет удобнее сразу видеть, процедура перед ним или функция.
Зачем?
RoPi0n Автор
02.01.2019 20:06Доводилось ли вам работать с неизвестным вам кодом? Мб с объемными библиотеками? Несмотря на гибкость языка, строгость должна присутствовать. proc & func реализованы исключительно для этого. Можно было и обойтись без них оставив например только func.
michael_vostrikov
02.01.2019 20:36+1Вы не ответили на вопрос. Какая практическая польза от того, что программист будет знать, функция это или процедура? Что случится, если он будет рассматривать все куски кода как функции?
Я много работал с неизвестным кодом, и мне ни разу не надо было знать, процедура это или функция.
RoPi0n Автор
02.01.2019 22:00-1Я решил сделать разделение на функции и процедуры, ведь это все же мой язык. Раз вам нет пользы до того, функция перед вами или процедура, то это ваше дело :)
Тут вопрос в том, как кому больше нравится.TheShock
03.01.2019 08:55Я решил сделать разделение на функции и процедуры, ведь это все же мой язык
С таким подходом он останется только вашим. Только тогда непонятно зачем вы о нём написали на Хабре?
Lex20
02.01.2019 18:16Почему синтаксис языка не на русском основан?
RoPi0n Автор
02.01.2019 18:18+1Это был бы ужас.
iig
02.01.2019 19:23Until не ужас, а "пока не" почему-то ужас. Или парсеру не все равно?
RoPi0n Автор
02.01.2019 19:25+3Считаю, что ЯП на английском языке будет выглядеть лучше.
iig
02.01.2019 22:21+1Пока видно pascal (end в конце блока кода, разделение на процедуры-функции), python (: в начале), php ( $ как префикс переменной), ?= — know-how автора; всё это заботливо перемешано. Не иначе, чтобы всех запутать :). Вот где ужас, а не в способе кодирования ключевых слов.
RoPi0n Автор
02.01.2019 22:25$ — сокращение this->
Они стоят только в классовых методах, как вы можете посмотреть.
Разве pascal & python плохие языки?)
Мне кажется, что Mash больше смахивает на Ruby.iig
02.01.2019 22:48У всех языков своя изюминка. C — лаконичный, с его {} и ?:. Pascal — строгий. Python — навороченный из коробки. Ruby — продукт сумрачного японского гения одно слово в:) Mash… даже не знаю… адский микс.
DaneSoul
02.01.2019 23:55Python — навороченный из коробки
Python хорош тем, что он позволяет писать как очень просто, так и навороченно.
То есть можно ничего не знать о функциональщине, ООП и даже работе с функциями, но уже начать писать простые скрипты, например для автоматизации каких-то действий в консоли.
А потом войти во вкус, изучить тонкости и начать писать компактный и эффективный код, со всякими генераторами, итераторами и т.п.
Именно по этому он хорош как язык для обучения программированию — можно не меняя язык показать разные подходы и парадигмы.iig
03.01.2019 00:06+1И ещё в нем, как правило, нельзя просто взять и скопировать кусок кода; надо ещё и выровнять отступы ;) один из базовых паттернов говнокода нельзя просто использовать.
Хороший язык, и синтаксис интересный.
mSnus
03.01.2019 05:06Сделайте уж совсем эпично-патриотично, на дореволюционном русском. И капсом все ключевые слова:
ФУНКЦIЯ
...
КОНЕЦЪ
GreyStrannik
02.01.2019 18:24+1К сожалению, из статьи не видна киллер фича (она есть?), зато виден убийственный недостаток — автор одинок.
alan008
02.01.2019 20:50+2Если статью назвать по-другому, значительная часть комментариев была бы гораздо менее токсичной.
Я бы назвал статью "Еще одна попытка создать ЯП на основе транслятора и ВМ" или "Попытка разобраться с тем, как создаются языки программирования и ВМ". Тогда бы все поняли, что проект в большей степени учебный, и что реализация больше велосипедная, нежели академическая/профессиональная/промышленная. Я уверен, автор получил классный опыт, разрабатывая всё это. И пусть это велосипед, многие комментаторы-критики и такой бы не создали, причем возможно даже не от нехватки опыта, а чисто из лени. А автор не поленился, разобрался и сделал, еще и выложить не постеснялся. Плюс статье, плюс в карму автору. Давайте уважать старания, а не хаять их.RoPi0n Автор
02.01.2019 21:03Про звезду репозиторию забыли упомянуть :)
alan008
02.01.2019 23:04+1Звезда на гитхабе — это немного про другое. Звёзды на Хабре выражают отношение к вашей активности тут (на Хабре), а звезды в гитхабе — это скорее отметки юзеров гитхаба, кому интересен проект, наподобие закладок. Я бы не стал ставить звезды всем подряд проектам на гитхабе, про которые просто "только что" услышал.
GeMir
02.01.2019 21:11+1Картофельное пюре (mash) — любый гарнир автора? :)
Аудитория вас интересует только русскоязычная или по какой причине на сайте из международночитаемого лишь «write, compile and run anywhere»?
Ну и мелочи…Заглушки «Company Name, Company Name, Company Name, Company Name» и «Чтож… Эта страница тоже в скором времени будет заполнена.» как и ваш ник на Patreon (RoPi0n) и выпрашивание «звёзд» на официальном форуме не добавляют серьёзности (а следовательно и доверия) сайту проекта, над которым вы трудитесь на протяжении нескольких лет.RoPi0n Автор
02.01.2019 21:57Сайт не слишком давно поднят.
Ему приоритет особо не выделял, т.к. времени небыло. Пока ещё не заполнен как следует. Хочется все по красоте сделать.
domix32
03.01.2019 01:01За использоване $var для переменных людей надо пожизненно отправлять в goto лапшу.
Вывод типа передачи данных в переменную будет довольно неудобным. Сложил так две переменных, а они по указателю передавались и в итоге попадаем в непонятный раздел памяти.RoPi0n Автор
03.01.2019 02:09Чтож, пишу в который раз для внимательного талантливого кодера domix32. Оператор $ используется лишь для сокращения записи "this->". В языке нет "$var" переменных. Ваш комментарий вообще не связан с проектом и не несет никакой смысловой нагрузки. Не следует отправлять в непонятный раздел памяти информацию сразу после её прочтения. На хабре предпочтительна конструктивная критика.
TheShock
03.01.2019 08:59омментарий вообще не связан с проектом и не несет никакой смысловой нагрузки
Автор, вам следует поумерить свой пыл, серьёзно. Тут вы неправы.
Не следует отправлять в непонятный раздел памяти информацию сразу после её прочтения
Думаете, люди никогда не ошибаются?
domix32
04.01.2019 18:14Не имеет принципиальной разницы для чего используется такой синтаксис, это сразу выкидывает из определения языка слово «простой». Перл уже использует аналогичное различие переменных, мало кто в восторге от его синтаксиса. Тут та же ситуация — вместо синтаксического сахара выходит перец. Набор символов !@#$%^ далеко не самый быстрый для набора, а при частом использовании мизинчик начинает страдать. Едва ли гуманно пересаживать людей за спецраскладки только ради языка.
Вторая часть относилась к присвоению переменных вообще. Вывод типа хорошо, но открыть блокнот и написать программу без ошибок из-за особенностей присвоения становится на порядок сложнее. То есть по хорошему нужен линтер или что-то подобное. Тоже далеко не аргумент в пользу простоты языка.
А так — успехов в своем начинании.
SBC
03.01.2019 11:44Вероятно это нужно чтобы однозначно определять, что это поле экземпляра класса, а не локальная или глобальная переменная
iig
03.01.2019 12:27Тогда $->var, пожалуй, более наглядно и логично. И немного на perl похоже ;)
$ — синоним this
-> — признак указателя
var — имя.
RoPi0n Автор
03.01.2019 12:47Тут же целых 2 символа можно сократить.
- При передаче $ как аргумента, допустим так:
MyMethod($) — передается просто this без ->
iig
03.01.2019 13:01Я не о том.
Внутри класса к его методам вы обращаетесь так:
$rem()
снаружу — так:
x->rem()
Зачем 2 разные формы записи одного и того же действия?RoPi0n Автор
04.01.2019 15:43Изнутри можно использовать обращение:
this->rem()
Которое можно сократить так:
$rem()
Также и с любыми другими переменными и методами класса.
Ну ведь удобнее же так :\iig
04.01.2019 15:51+1Указатель this есть, ок.
Нотация для записи указателя есть, вот она ->
Синоним для this есть, вот он $
Почему вместо $->name использовать дополнительный вариант написания $name, годный только внутри класса? Так короче, да. Но удобнее ли… это дополнительное правило в синтаксисе простого языка.
- При передаче $ как аргумента, допустим так:
RegisterWindowClassExA
03.01.2019 01:39Респект Вашему труду, но не ясна концепция языка. Вот в Python всё ясно — это современный крутой аналог бейсика, типизации нет, переменные объявлять не надо, даже поля классов объявлять не обязательно, пиши функционал, никакого занудства. В Си тоже ясно — строгая типизация, переменные объявлять обязательно, ну Вы понимаете. У Вас получилось нечто среднее, причём не ясно, а в чем изюминка? Т.е. для Вас это крутой учебный проект? Тогда ок… На первый взгляд, он ничего не даёт. Никакой крутой концепции, кроме того, что Вы написали свой язык, а я не написал.
И да, у Вас ведь нет компилятора под некоторую ОС? Ни байт-кода… Т.е. есть синтаксический анализатор, который разбирает строку на команды и тут же исполняет инструкции? Ну мне почти всё ясно тогда, кроме того, как Вы реализовали динамическое построение классов в трансляторе. На чём транслятор написан?
Т.е. на мой взгляд самое ценное здесь — реализация транслятора, но эта тема в статье не раскрыта. А так — Вашему уровню респект, конечно…RoPi0n Автор
03.01.2019 02:19Транслятор преобразует код в промежуточное представление (ассемблер-подобный листинг) и затем собирает уже его в абстрактный байткод для написанной ВМ. Исходя из вашего текста, делаю вывод о том, что вам не почти все ясно, а почти ничего не ясно. Рекомендую пост к прочтению повторно.
Динамическое построение классов реализовано через структурные таблицы и генератор конструктора и деструктора структуры классов.
На чем написано? Серьезно? Вам сложно клацнуть по ссылке на репозиторий?
RegisterWindowClassExA
03.01.2019 03:16Ну ок, мне было почти ничего не ясно, теперь немного яснее, спасибо :)
0xd34df00d
04.01.2019 15:37Вот в Python всё ясно — это современный крутой аналог бейсика, типизации нет, переменные объявлять не надо
И это типа хорошо?
В Си тоже ясно — строгая типизация
А, ну понятно.
RegisterWindowClassExA
04.01.2019 15:44Пардон, имелась в виду явная и неявная типизация, а не «строгая» и «типизации нет».
И это типа хорошо?
В этом есть своё очарование. Иногда это очень удобно. Возможно, мне так кажется лишь потому, что Бейсик был одним из первых языков, который я освоил.0xd34df00d
04.01.2019 16:37Пардон, имелась в виду явная и неявная типизация, а не «строгая» и «типизации нет».
Но ведь в питоне она строгая и динамическая (хотя динамическая типизация — это немножко оксюморон, если подумать о предназначении типов), а в С явная, слабая и статическая.
RegisterWindowClassExA
04.01.2019 16:53Да, это так. В Питоне лично мне понравилось то, что в нем не нужно объявлять переменные, а также поля классов. Этим он мне и напомнил Бейсик. А «очарование» здесь в том, что это снижает бюрократическую составляющую при написании кода. В этом есть определенное удовольствие, просто садиться и «фристайлить». Необходимость объявлять переменные это удовольствие резко снижает. ИМХО.
Строгость типизации — это да, это тоже немного мешает, т.к. усложняет текст программы явными преобразованиями.
Это не значит, что я говорю, что Python лучше чем Си. Скорее, мне кажется наоборот. Как перфекционист я бы вообще кодил на Асме, но увы, это коммерчески нежизнеспособная идея. А в Python как и в Бейсике есть своё очарование. Я знал классных кодеров, которые начинали с Бейсика. Именно потому, что неявная типизация позволяет сосредоточиться на задаче, а не на бюрократии… Это как кафе открыть — одно дело классно готовить и людей кормить, а другое — соблюдать положенный документооборот. Немного разные задачи. Хотя конечным итогом должно стать именно классное обслуживание клиента.0xd34df00d
04.01.2019 17:20Ну, это уж кому что. Мне больше нравятся строгие и выразительные системы типов, когда компилятор бьёт меня по рукам и помогает отлавливать ошибки ещё до запуска программы. И это, кстати, совсем не значит, что переменные надо как-то заранее объявлять.
Да и проектировать типы тоже помогают, ещё как.
FreeBa
03.01.2019 01:53+1максимально простой, полнофункциональный и удобный язык
Взаимоисключающие понятия, имхо. Шарп и ява тоже задумывались такими, а в итоге получилось, то что получилось. Простыми языки может и являются (весьма условно, без хорошего опыта в «строгих» языках, с ходу в них не войдешь), но обвешаны таким количеством библиотек являющимися отраслевыми стандартами, что изучение «обвеса», занимает на порядок больше времени чем изучение непосредственно языка.
При разработке языка есть смысл ориентироваться либо на функциональность, либо на простоту, имхо совмесетить это невозможно.
forcam
03.01.2019 04:57Уважаю всех кто берется за глобальные вещи и написание языка программирования явно одна из них. Все языки программирования либо служат определенной цели, либо нескольким целям, либо помогают решить что-то быстрее, эффективнее ну или оптимальнее других.
Бегло пробежав по коду я понял в нем все очень легко, это несомненно круто, потому что я не имею никакого отношения к программированию и учил когда-то только паскаль.
Ваш язык это тот же паскаль, но со всеми наваротами, которые присущи современным языкам и ваш вектор явно лежит в сторону того, что бы язык сделать таким же как и любой другой. Но мне кажется вы не осознаете, где именно ниша вашего языка. Есть Goland, есть Python, отличие от них будет в том, что ваш язык будет еще проще.
Ok, тогда вам нужно понять кому будет полезен ваш язык и я делаю вывод, что в первую очередь он будет полезен тем же, кому полезен паскаль, т.е. новичкам, по этой причине я думаю имело бы смысл сделать сильный док материал, с хорошими туториалами, что бы ваш язык мог освоить любой. Проблема вхождения в язык в его сахарности, если человеку сложно осмыслить логическую цепочку последовательности того как строится программа, то он может бросить пытаться учиться, ваш язык своей простотой помог бы очень многим, а учитывая то, что теоретически он позволит писать все, да еще и будет актуален в плане постоянной поддержки всех современных веяний в языках — такой язык идеален для того, что бы начинать с него изучать программирование.Я не знаю считаете ли вы, что чем больше будет в мире новых программистов — чем-то хорошим, но если да, то лучшим вариантом было бы сделать максимально возможное количество примеров для реализации. Т.е. написание простейших программ с подробным описанием всех кирпичиков работы. Ну и общая исчерпывающая документация. Конкретно такого языка, который бы максимально просто вводил человека в программирование сейчас нет, паскаль давно безнадежно устарел, так что ваш язык помог бы очень многим открыть дверь в мир программирования.
Panzerschrek
03.01.2019 06:09Исключения, сборка мусора — не самые актуальные сейчас элементы в новых ЯП (Rust и т. д.). Не рассматривается ли отказ от них?
RoPi0n Автор
03.01.2019 12:33Как же без них? Мне кажется, что от этого нельзя уходить.
0xd34df00d
04.01.2019 15:38От исключений можно и нужно уходить.
KaminskyIlya
04.01.2019 10:03От исключений можно и нужно уходить
Прошу прощения, а можно про это по-подробнее? Есть какая-то техника, или какие-то тренды в этом направлении?
unC0Rr
03.01.2019 10:18Хочу заметить, что хоть количество поддерживаемых платформ у фрипаскаля велико, оно очень туго расширяется. Уже несколько лет идут разговоры о бэкенде llvm, но реализации до сих пор нет. У нас была попытка сделать браузеры одной из платформ для программы, пришлось реализовать самописным конвертатором из паскаля в си, дальше цепочка из llvm (вот и пригодился бы родной llvm-бэкенд!) и emscripten. Самое интересное, что программа после прямой конвертации в совершенно неидеоматичный си и компиляции с оптимизациями оказывалась быстрее любой сборки фрипаскалем. Кроме того, за 14 лет использования фрипаскаля я уже трижды натыкался на баги релизного компилятора, что тоже несколько удручает.
RoPi0n Автор
03.01.2019 12:44Поэтому и хочу на llvm перенести выполнение кода. Только различие в работе с памятью и пока что недостаток моих знаний по LLVM.
SBC
03.01.2019 11:48Добро пожаловать в клуб любителей трансляторов и компиляторов.
Для целых чисел 32 бита фундаментальное ограничение? Чтобы поближе к машине?
Не смотрели в сторону длинной арифметики?
impwx
03.01.2019 13:48+1Добро пожаловать в клуб! Теперь, однако, вам необходимо ответить на самый тяжелый вопрос — нужен ли данный язык кому-то, кроме вас? Дело в том, что синтаксис по большому счету никому не сдался, а действительно важно удобство решения задач. Если, как вы пишете в комментариях, основная задача была в том, чтобы получить опыт — считайте, что вы его уже получили. Поставьте данный проект на почетное место на полке и двигайтесь дальше, с опытом и новыми силами, исходя от какой-нибудь конкретной задачи, решение которой с помощью языка принесет кому-то конкретную пользу.
rkfg
04.01.2019 14:23Коммиты не оформлены практически никак, это ужасно. Похоже, для вас Git — это какая-то обязанность (все делают, ну и мне придётся, эххх, а мог бы по-старинке projname-2018-12-20.zip делать и не мучаться), а не инструмент работы. Советую почитать, как оформлять коммит-сообщения, чтобы всем стало лучше.
WRONGWAY4YOU
04.01.2019 17:41Для того, чтоб язык был полезен хоть кому-то после выхода (кроме самого разработчика), он должен обладать некоторым количеством отличающих черт, каждая из которых хоть как-то упрощала б задачу реализации программного обеспечения.
Извините, конечно, но Вы представили еще один generic язык, который ничего особо нового и не дает людям. Однако, для всего нужен опыт, и, даже один законченный ЯП, я уверен, смог Вас очень многому об этой области CS научить, и, следовательно, следующая попытка будет уже лучше. Нужно просто сделать его уникальным и полезным.
А вообще, могу точно сказать, что 99% всех программистов никогда в своей жизни не реализуют ничего своего и не напишут об этом статью. К тому же Вы за эту статью (скорее всего) получили приглашение на Хабр. Так что поздравляю!
feyd12
04.01.2019 18:40Присоединяюсь к поздравлениям, хотя статью можно и попроще забацать для такой цели, как приглашение, мою гляньте))
Vitter
04.01.2019 00:34Вопрос стоит — зачем язык создавался? Единственно, что его хоть как-то отличает — синтаксис питоно-паскале-подобный.
Что критически важно — на сайте добавить синтаксис! Говорить про язык программирования без синтаксиса (даже с репозиторием компилятора) как-то не серьёзно. Я, например, даже не понял — есть ли в этом языке комментарии или нет.
Далее критически важно — версификация. Какую версию вы нам описали в этой статье? 0.4.12? Или всё же — хэ его зэ? Это уже ближе к правде.
Ну, а по мелочи — есть к чему придраться.
Зачем делать until (false)… end постусловием, если уже придуман repeat… until (false)?
Или зачем создавать процедуры, если есть функции?
voidptr0
Если честно, то на первый взгляд Паскаль и получился, дополненный, правда, полиморфизмом, сборщиком мусора и посыпанный синтаксическим сахаром. Может, правда, Вы так и задумывали, но тогда задача сформулирована не очень убедительно.
RoPi0n Автор
Мне кажется, что язык похож на Pascal очень отдаленно.