Проект V-LITE

Проект V-Lite - создание нового языка программирования и компилятора этого языка. Все это затевается исключительно в образовательных целях и не планируется занимать передовые места на IT-рынке.


Страничка проекта


Сегодня я выложил очень сырой и до конца не законченный (пардон за тавтологию) проект спецификации языка V-Lite. Меня интересуют следующие вопросы:

1. Конкретно ваше мнение о базовом синтаксисе - удобства, неудобства, предложения, замечания и т.д.
2. Особо меня интересует мнение о этом ужасном select.
3. Идеологически верная работа с указателями - какая она? Авто-разыменовывание, как описано у меня, или как в Java, или в С?
4. Нужны ли унарные операторы ++ --, может быть, даже ?:
5. Должна ли операция присваивания возвращать значение?
6. Нравится ли вам универсальный цикл for?

Найдете ошибки, неточности - смело тыкайте, буду благодарен.

Интересно! Всё довольно просто. Select case, вроде, больше похож на if..elseif..endif, так как там указывается условие а не только равенство.

Привет!

Я ещё не качал и не тестил, только глянул спецификацию.
Вот мои мысли и комментарии. Не обижайся. Если с чем-то не согласен, или я чего-то недопонял, можем обсудить.


= присвоение (не возвращает значения!!!) Или все таки возвращает???

Это уже тебе решать. Тут надо смотреть в первую очередь на идиалогию языка.
Но судя потому что ты сделал оператор "==", то оператор "=" должен возвращать значение.

a = b= c = 12

Тогда будет возможна конструкция вида
if( handle = get_handle())

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

for и лучше закрывать его уже привычным next.
Хотя endfor можешь оставить.

А вот петли... Всё же продублируй, хотябы do ... loop.

На счёт select.
Не знаю... Я считаю, что выражение case должно быть более простым.
case 10
case 666

Но если хочеться взять выражение, то задействуй ключевое слово is

case is == 10
case is <= 666
Тут в бэйсике всё очень сздорово сделано и нет смысла переиначивать.
Я не заметил преимуществ от твоего варианта, а только лишние символы "==".


goto?
Не нужно!


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

А вот объявлять... Возьми лучше слово "var"
var {атрибуты} имя {тип} { = значение}
Или как-нибудь так. Слово "as" совершенно не в тему.


В качестве имени последнего аргумента может быть указано ... - в таком случае функция принимает переменное число аргументов. Тип переменных должен быть
указан. Например: proc MyProc(as int arg1, as int ...);


Как у тебя проработана безопастность?
Я бы рекомендовал дополнительным (скрытым) параметром в функцию передавать число аргументов.
Тем более у тебя есть свой litecall.


retval - можно ли из неё читать или только задавать новые значения?



4. Нужны ли унарные операторы ++ --, может быть, даже ?:
А почему бы и нет? Конечно сделай.


3. Идеологически верная работа с указателями - какая она? Авто-разыменовывание, как описано у меня, или как в Java, или в С?
Тут вообще трудно сказать. требо подумкать.

С одной стороны указатели это хороший инструмент для оптимизации. Но это один из источников ошибок.

В принципе в C разъименование сделано логично.
Но на самом деле... Если ты не собираешься двигать свой язык на рынок и всё такое. То почему бы не попытаться избавиться от указателей вообще? Или ограничить их как-нибудь, во имя безопастности?

Хотя, я сейчас затрудняюсь представить прогу без указателей. Но ведь в php без них живут и всё вроде ок!

А твой механизм... Тут всё ещё сложнее. Как я понимаю, у тебя компилятор самостоятельно пытаеться разыменовать указатель. А есть ли гарантия, что он не запутаеться? Или может быть программер имелл в виду нечто совсем другое?
С этой стороны вариант как в C выглядит проще. Что программер указывает, то и получает.

Но проблема действительно, стоит того чтобы над ней ещё подумать.

Я ещё не качал и не тестил

Качать пока нечего. Рабочей версии еще нет, сейчас работаю над генератором кода.


Я имел в виду грабли, на которые уже наступали сишные программеры - когда начинающие кодеры пишут вместо
if (a == b) - if (a = b), а потом удивляются почему ничего не работает. Так все же возвращать или нет?

++ и --... Ну тут тоже горький сишный опыт. Эти операторы не совсем безопасны... Например - func(a++, a++). Какие аргументы получит функция? Это зависит от реализации компилятора (так как порядок вычисления аргументов не документирован). Кроме того, мешают макросы - если в func(a++, foo(b), a) foo является не функцией, а макросом, то макрос совершенно внезапно может оказаться таким: #define foo(arg) a++... и результат ясен. точнее, совсем не ясен. Но если порядок вычислений в V-Lite будет определен (ну и макросов тоже не планируется), то возможно, появятся и ++ с --.

retval - полноценная переменная, имеющая тип, возвращаемый функцией.

И еще парочка вопросов:

Стоит ли заменять операторы || && и т.д. чем-то вроде or and? Или оставить оба варианта (хотя я такое не люблю)?

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

Проскальзывала такая идея - имена типов предварять специальным символом - например, @. Упрощение парсера не так важно, важна удобочитаемость кода. Или нет?

Атрибуты переменных - ну тут все относительно просто.
align(size) выравнивает переменную в памяти так, что первый ее байт имеет адрес, кратный size. Иногда это очень критично, хотя в винде редко встречается... Но тут еще и проблема оптимизации - у выровненной переменной меньше риска попасть на границу двух страниц памяти. К ошибке это не приведет, но производительность может снизиться.
deprecated заставляет компилятор выводить предупреждение при каждом обращении к переменной. Тоже бывает полезно.
section(name) - действительно только для статических переменных. Заставляет компилятор размещать переменную в определенной секции исполняемого файла. Это, наверно, больше для понта, в реальной жизни не пригодится, удалю его.
dllexprort - заставляет экспортировать переменную (только если билдим dll-ку). Переменные могут быть экспортированы точно так же, как и функции.
static, local - делает переменную статической (обычно расположена в секции данных) или локальной (в стеке).
thread - а вот это уже нечно оригинальное. Хотя подобное я уже видел в PowerBasic, идея мне пришла задолго до этого. Переменная становится локальной по отношению к потоку - то есть каждый поток будет иметь свою уникальную копию этой переменной.
const - ну тут все понятно. Константа она и есть константа.

А вот объявлять... Возьми лучше слово "var"

А смысл? Какая разница? Var здесь, имхо, не подходит, так как точно такой же синтаксис используется и в типизации инициализаторов, и в объявлении членов структур и аргументов функций, к котором определение "переменная" как то не подходит.

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

Я сомневаюсь, чтоб компилятор мог ошибиться. Но в конце концов, операторы * и & в языке все равно есть. Компилер ошибется только если не будет знать настоящий "уровень адресации" указателя. А в С, не зная настоящего уровня адресации, тоже ничего сделать не получится. Никто не отменял преобразование типа указателя к типу с другим уровнем адресации (кстати, V-Lite строго типизированный язык). К тому же, в Fortran-90 авто-разыменовываемые указатели прекрасно работают и никто на них не жаловался.
Хотя я могу чего-то не понимать... Приведи пример, в котором компилер потенциально может запутаться.

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

operator=() - не возвращает значения.
operator++() и operator--() вообще не допустимы.
да и лучше без операторов += -= *= /= и так далее.

Таким образом мы убережом многих новичков от граблей, а ещё уменьшим объём который они будут изучать.


А вообще оператор ++ когда с права, возвращает изначальное значение переменой.
Когда же слева, то он возвращает новое значение. И это прописано в спецификации.
Причом имеет наивысший приоритет.


Вычислять нужно с права на лево.
Это, например для того, чтобы
a = b = c = 123

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

number a, b, x.
a = 2: b = 3.
a + b = x?
print x.

Может быть перейдём на такой синтаксис?


Про макросы... Я уже говорил, что считаю их злом! И от них нужно избавляться!

Префикс для переменной. Я бы предложил символ "$" это более традиционно.
Префикс "@" для сообщений.
А префикс "%" для переменных шаблона.

Это не только сделает код более читабельным, но и позволит упростить разбор кода и отлов ошибок.
Опять же это лично моё мнение!

В прочем, смотря в C++ я склоняюсь к тому, что для переменных шаблона, наверное, префикс не нужен.. Или всё же нужен, но только для, так называемых "констант", а не для "типов".


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


Ага, с атрибутами понял.
Можно ещё расширить.
global или shord для того чтобы сделать глобальной или указать, что переменная глобальна. Причом для нескольких копий подной программы
session переменная сохраняемая и легко востанавливаемая, даже если программа была выгружена и вновь загружена. Но только для одной копии программы с определённым идентификатором.
enviroment а этот атрибут показывает, что переменнная придлежит операционной системе, проще говоря переменная среды окружения.

Хотя это уже тоже изврат.

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

А я вот ещё раздумываю над одной жосткой мерой.

имена переменных писать малеьнкими начиная с символа "$".
Слова разделять символом подчоркивания "_".
mi_vareable()

имена, процедур, функцийй и методов писать маленькими, без префикса.
Слова разделять символом подчоркивания "_".
mi_function()

константы писать большими буквами, без префиксов.
Слова разделять символом подчоркивания "_".
MI_CONST

именна типов и классов писать маленькими буквами, без префикса.
Но каждое слово начинать с заглавной буквы, в т.ч. первое.
Символ подчоркивания "_" не допустим.
SomeClass

Причом вложить это в парсер, чтобы он мог уже сразу проверять корректность.


Кстати, на счёт слова "var". Ну да, в свойствах класса оно не подходит.
Но слово "as" не подходит ещё больше.

freebasic перенял из c++ способ указания публичности члена класса, я с этим не очень согласен.
Так вот в visual basic да и в php у каждого члена указываеться его публичность.
А для php, так там вообще слово var опускаеться для свойства.

[code=php5]
class SomeClass
{
public property1;
private property2;
}
[/code]
Очень не плохое решение. Они в пользу него отказались именно от
[code=php4]
class SomeClass
{
var property1;
var property2;
}
[/code]

А поле класса, это действительно не переменная.

но "переменная" (variable) всё же лучше чем "как" (as).

Извиняюсь за длительное молчание - на пару дней пришлось отвлечься от работы.

Не стоит ориентироваться на грабли, по которым бегают начинающие.

К сожалению, ошибки делают не только новички. В большом проекте намного сложнее отловить один засевший в мегабайтах кода жучок (= вместо ==), чем в хелловорде на пару строк. Одна из задач любого ЯП - максимально обезопасить код от подобных ошибок (не доходя, конечно, до паранойи)

А вообще оператор ++ когда с права, возвращает изначальное значение переменой.

Мда... Ошибочка вышла. Я хотел привести пример с func(++a, foo(b), a)... Вот что значит последний месяц кодить только на ФБ...

Вычислять нужно с права на лево.
Это, например для того, чтобы
a = b = c = 123

Упс. Вот этого тоже не учел. Спасибо. Итак, вопрос решен - вычисляем справа налево. Тогда надобность в litecall потихоньку отпадает, переходим на cdecl.

Про макросы... Я уже говорил, что считаю их злом! И от них нужно избавляться!

А кто-то предлагал макросы?

А чем плох тот вариант, что будет два имени у одного действия?

Тем, что, например, лично меня раздражало бы, если в одном файле везде было бы написано && и ||, а в другом and и or, а еще хуже, если сразу в одном выражении. (хотя последнее можно запретить - сделать директиву компилятора, которая устанавливала бы способ записи для текущего файла).

Можно ещё расширить.

Интересно. И совсем не изврат. Очень даже полезно. Я когда-то думал о чем-то вроде session, но в конце концов эта мысль у меня превратилась во что-то вроде "нужно написать специальную библиотеку, которая бы обеспечивала удобную и быструю работу с настройками программы"

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

А я вот ещё раздумываю над одной жосткой мерой.

Имхо, это уже вопрос стиля. Есть, конечно, ЯП, которые строго ограничивают стиль (вроде Eiffel), но мне это не нравится. Но сам стараюсь придерживаться определенного стиля.

но "переменная" (variable) всё же лучше чем "как" (as).

Ну вот не нравится мне var. Сразу паскалем пахнет, дельфями...

var это не только паскаль. это и JavaScript и php и visual basic. И даже freebasic.
Очень такая традиционная фича.

Слово же "as" оно коректно в контексте "dim"
dim mivar as integer
переменная mivar как целое число

А вот
dim as integer mivar
или даже
as integer mivar
лично меня раздражает бессмысленностью.

Это из стиля
cd-диск

Если не хочешь var используй "let".
Или как в C тип, а потом имя.
int a;

Кстати, ещё про var.
Я сейчас на C++ писал одну фичу. Так там у меня универсальная оболочка для переменных, тоже var.

var a;
a = 1.23;
var b = a;
b = "Hello, world!";
var c = a.to_string();

Правда у меня var это класс. Но всё равно, объявление выглядит стильно.
Вообщем, кому как, а мне очень даже нравиться.

DiG. GeRR пишет:Например - func(a++, a++). Какие аргументы получит функция? Это зависит от реализации компилятора (так как порядок вычисления аргументов не документирован). Кроме того, мешают макросы - если в func(a++, foo(b), a) foo является не функцией, а макросом, то макрос совершенно внезапно может оказаться таким: #define foo(arg) a++... и результат ясен. точнее, совсем не ясен.

Про макросы... Я уже говорил, что считаю их злом! И от них нужно избавляться!

DiG. GeRR пишет:А кто-то предлагал макросы?

Не знаю... Вроде бы не предлагали...

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

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

1. компиляция операционной системы и системных утилит
2. компиляция пользовательского приложения.
3. компиляция динамических библиотек.
4. компиляция модулей / плагинов.\
5. встраивание как язык командной оболочки.
6. язык встраевымый в приложения.
7. в том числе в браузер, как клиентский скрипт.
8. в веб-сервер, как серверный скрипт.

При этом язык должен быть удобным для написания сверх малых и очень больших проектов.

Он должен быть компилируемым в быстрый код и легко интерпретируемым.

Соответственно это очень всё сложно и запутано. А ещё в языке появляються весьма спецефические для каждого применения моменты.

Например для сервера нужен простой доступ к GET, POST, FILE и ещё чему-то. А ещё эти самые SESSIONS.
Для браузера, нужен доступ к COOKIES.

Для консоли нужен ARGV

Причом для скриптов THREADS вообщем-то и не нужен.

А для системных программ, не нужна интерпретация.

Вообщем очень интересная помесь получаеться.

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

На данный момент проект "заморожен". Дело все в кодогенерации. Сначала я хотел делать генератор напрямую в асм-код для FASM, но потом начал присматриваться к gcc IR, LLVM... И по ходу дела начал осознавать, насколько объемная задача передо мной стоит. Нет, я не сдался (хотя в принципе - зачем нужен еще один ЯП, который не привносит ничего нового), а взял продолжительный тайм-аут - на обдумывание, планирование и т.д. Может, через год или пару лет что-то у меня и выйдет...

Большое спасибо всем, кто принял участие в обсуждении проекта, особенно Eric-S.

До встречи, V-Lite!

Ну да. Работы много!

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

Но по любому этапов для разбора многовато.

1. препроцессор
2. лексический анализ
3. выделение и корректировка лексем
4. синтаксический анализ
5. построение внутренних иерархических связей
6. вычисление констант и подстановка
7. оптимизация
8.формирование объектного кода
9. оптимизация
10 сборка выполняемого файла


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


Да и с библиотеками не всё так просто.


Мы немного выше обсуждали проблему символа присвоения "=" и оператор сравнения "==".
Я сам думал над этой проблемой ещё раньше и пришол к выводам, схожим с паскалевским синтаксисом.

":=" - оператор приссвоения
"==" - оператор сравнения.
А просто "=" считать ошибочным, о чём тут же сообщать, облажавшемуся кодеру!
Таким образом, мы избавимся от потенциальной ошибки с путаницей.

if( 0 == a:= get_handle() )
sys_error( invalid_handle );


А вот на счёт переноса строк и символов в конце инструкций, пока ещё не придумал, чего-то действительно красивого.