Nov 15, 2012 11:58
Сделать язык я мечтал со школы но реально заняться удалось лиш в 2012. Т.е. что-то я делал, думал-писал про устройство языка но до
реализации (компилятора) не доходило.
Ya основан на C++ и большую часть C++ берет как есть. Но совместимости с C++ нет, C++ программа не будет компилироваться как Ya.
Базовые концепции (идеи, основы) языка
- двойная компиляция - пока компилятор компилирует компилируемый код может тут же запускаться. Это нужно для возможности
расширять-изменять синтаксис языка, лексику и делать оптимизации, где оптимизатор написан программистом
- дополняемый синтаксис
. - можно добавлять новые операторы в язык. Например какой-нибудь foreach для своего типа контейнеров.
. - предполагается что можно будет даже добавить в синтаксис языка нетерминал и правила трансляции в базовые
нетерминалы-терминалы
- дополняемая лексика
. - можно добавить в выражения новую операцию.
. . - например для сортировок нужнен результат <0,0,>0 и можно ввести операцию, назовем ее <=>, которая это делает для стандартных типов.
. . - еще пример: пусть <-> означает обмен значений переменных (swap). int i,j; i <-> j;
. - можно добавить другие новые константы. Например время естественно писать как 10:53:17 - добавление новые константы
описывается как регекс а код по превращению текста константы в нужный тип программист пишет на Ya
- поддержка работы с базами данных и данными программы по структуре похожими на базу данных - видимо это будет не более чем
библиотека, но для языка важно
- мелкие изменения в базе С++ - это наверно концепцией не назовеш, но опять важно
. - отказ от файла проекта. В каждом Ya проекте есть _главный_ исходник и при запуске компилятора ему говорят компилировать один
главный исходник. Внутри главного исходника описывается какие модули в проекте и в каких файлах. Конечно это не обязано быть
описано в главном исходнике, лиш бы при компиляции используемых модулей было ясно в каком файле модуль
. - понятие модуля с именем: module name; в самом начале каждого компилируемого файла
. - убирание .hpp и введение using module, module..., что убирает разделение на хидер и реализацию т.к. в модуле пишут обе части
но using подключает только интерфейс модуля но не реализацию
. - слово class отменить (запретить) и писать структуры и новые типы так:
. . - type constint = int-;
. . - type StrC {тело cтруктуры} - заметим что ; в конце не нужна т.к. переменных тут быть не может
. - break for...; continue for; - в C++ часто приходится делать goto из циклов и switch если покидаеш более одного for-switch.
Потому теперь можно указать из чего break выходит, например break switch for; - значит надо выйти сначала из switch и еще из for
. - в switch каждый case автоматически заканчивается break кроме случая написания continue для продолжения в след case
. - в switch после case может быть несколько вариантов через запятую. И с диапазонами 10..20. '..' это лексема, не 2 точки. Пример: case 1,4,10..20:
. - описание типа - теперь описание типа будет в одном месте, не как в C++ где массивы пишут так char str[100]; - в Ya это будет
char[] str(100); или в структурах было описание длины напр int i:8; что значит что i 8 бит длиной - теперь будет int:8 i;
. - + unsigned. Пример int+ i; т.е. unsigned int i;
. - -+ signed: -+ щитается одной лексемой
. - - const. Пример int- i = 0; т.е. const int i = 0;
. - указание длины (в битах) перем: пример: int+:8 i; это unsigned int i:8; Или int+:16*- p; это ushort* const p; если short 16
бит
. - * указатель-ссылка, официально указатель, станет одним, ссылки официально отменяются. Для доступа к значению можно писать
*ptr а можно ptr, т.е. компилятор по типам аргумента и результата определяет сколько раз тут надо взять содержимое указателя. Это
делается чтобы проще было писать работу с указателями. -> станет не нужна. Указ на указ возможны. Взятие адреса - &
. - [] для массива, между [ и ] можно писать тип контейнера, например для создания массива который можно расширять будет писаться
[+]
- возможность пользователю-программисту дорабатывать реализацию языка - при помощи написания библиотек. Т.е. в языке есть
(предполагаются) возможности (типа полей-методов зависящих от нескольких аргументов), которые в базовой реализации сделаны
нормально для простых применений (типа зависимость лиш по одному аргументу для полей и функций), а для сложных реализованы кое-как
(скажем для 2х аргс реализацию я сделаю чтобы показать что возможность все же есть, но сделаю кое-как), или не реализованы (скажем
для 3х аргс можно и не делать - кому надо сам сделает).