Qod. Опубликовал исходники компилятора, над которым работаю

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

void Statement_WHILE(char @Buff; word @P1; word @SkipFinalScan)

	word  BODY = Peek();
	word  COND = Peek();
	Node [P1].ID = iWHILE;
	Node [P1].pLeft = BODY;

	Node [BODY].ID = iBODY;
	Node [BODY].pRight = COND;

	Node [COND].ID = iCOND;

	char @End2 = NULL;

	select
	case str_eq(@Buff,"while"):
		@End2 = "while";
		Node[COND].pLeft = Expr(PRIO_ZERO, @Scan(@Buff));
		word pType = Node[Node[COND].pLeft].pType;

		if pType != st_bool then
			Error(@eTYPE);
		end

		if str_ne(@Buff,"do") then
			Stop(@eDOEXP);
		end
	case str_eq(@Buff,"forever"):
		@End2 = "forever";
		Scan(@Buff);
		if str_ne(@Buff,"do") then
			Stop(@eDOEXP);
		end
	case str_eq(@Buff,"do"):
		Deprecated("'do' should be replaced with 'forever do'");
	default:
		StopInternal(__FILE__, __LINE__);
	end:select

	word pLoop1=pLoop;
	pLoop=P1;

	Scan(@Buff);
	Node[BODY].pLeft = Statements(@Buff, "end", NULL, NULL);

	SkipFinalScan = EndOf(@Buff, "do", @End2, true);

	pLoop=pLoop1;

	CTE_WHILE(@P1);
end

и код взрослых дядек

///while statement
	Stat* whileStat() {
		Attr la;
		Stat* lbody;
		getSy();

		boolExpr(la);
		if (la.isConst()) {
			if (Sy() != colonSy) { ///colon or block begin
				testSy(blockBeginSy);
			}
			lbody = loopStat();
			if (la.boolValue()) {
				Helper::warning("while condition always true","infinite loop");
				return lbody;
			}
			else {//false condition
				Helper::warning("while condition always false","body skipped");
				return nullptr;
			}
		}

		//here condition is not const
		if (not canSkip(colonSy)) {
			skipSy(blockBeginSy);
		}
		_context.incLoopDepth();
		lbody = declBlock(BlockEndStops);
		_context.decLoopDepth();

		skipSy(blockEndSy);
		blockEndAnnotation("while");
		return Slan::WHILE(la.ex(),lbody);
	}

это я чтоли тебе написал

https://en.wikipedia.org/wiki/Lexical_analysis

Lexical token

Разбей последовательность a<b<c>>d на lexical tokens.

А почему не получается?

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

Тухлые понты вижу, конкретики не вижу. Что сказать хотел? =)

Разбей последовательность a<b>d на lexical tokens

легко

ident(a), left_angle_bracket, indent(b), left_angle_bracket, ident(c), right_angle_bracket, right_angle_bracket… :)

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

так что со всеми фокусами с угловыми скобками в с++ будет уже разбираться парсер

легко ident(a), left_angle_bracket, indent(b), left_angle_bracket, ident(c), right_angle_bracket, right_angle_bracket… :)

так что со всеми фокусами с угловыми скобками в с++ будет уже разбираться парсер

То есть следующий код валиден:

unsigned foo(unsigned a, unsigned b)
{
  unsigned x = a > > b;
  return x;
}

Это ровно тот случай, когда чтобы сойти за умного, стоило просто промолчать.

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

язычок твой слабый… вот скажи почему ты не пишешь

return a>b;

а пишешь повсеместно длинный эквивалент

when a>b: return true
return false

не умеет твой язык возвращать результат булева выражения? или это порок стиля программирования?

хотел сказать, что парсер описывает семантику конструкции, а не ее реализацию ее парсинга

Охренеть. Парсер описывает семантику конструкции. А синтаксис конструкции тогда кто описывает, дядя Стёпа?

вот скажи почему ты не пишешь

Потому что в кодогенераторе еще недописал соответствующую ветку генерации кода.

язычок твой слабый…

Это настолько провальная попытка до**бки, что даже неловко за тебя. Попробуй еще раз?

Это ровно тот случай, когда чтобы сойти за умного, стоило просто промолчать.

если лексер возвращает позицию символа в потоке или наличие разделителя перед символом - парсер разберется.

Потому что в кодогенераторе еще недописал соответствующую ветку генерации кода.

вово. чуть что - «недописал» пока. у тебя такое повсеместно, а ты - недописал. а я сразу увидел что тут явно дырка у тебя. гы.

если лексер возвращает позицию символа в потоке или наличие разделителя перед символом - парсер разберется.

А если еще литературную критику «Войны и мира» в парсер передавать вместе с токенами, то вообще зашибись.

Внезапно понятие токена как изолированной абстракции стало зависеть от метаданных. Кросивое. Продолжайте ваши рассуждения про хорошую архитектуру, пожалуйста.

еще чую дырку…

у тебя может в левой части выражения стоять вызов функции?

f(x) = 100;

а я сразу увидел что тут явно дырка у тебя. гы.

Дырка в жопе у тебя, а это - баг.

Ты же знаешь, как опенсорс устроен? Можешь прислать патчи. Если конечно есть мозги.

у тебя может в левой части выражения стоять вызов функции?

Сходи, проверь. Доступ в issues вроде по дефолту открыт на гитхабе, если что-то не так.

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

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

есть и другие преимущества. но я их не скажу.

)))))

Soooqa! Мне работать надо, а я не могу перестать угорать с этого диалога!

у тебя правило есть такое, для левой части? по жизни есть оно? я откуда знаю-то. language report у тебя нет, правила в голове у хохлова и у тебя.

а конструкция компилятора настолько школьно-примитивная, что сразу возникают вопросы о таких вот правилах.

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

Мне работать надо

вот. работай там давай. труд делает человека свободным

можно кодировать then спец.комбинацией пробивок в одной колонке, и символ не будет путаться с идентификаторами

у тебя правило есть такое, для левой части?

Какое правило для левой части, ты на коммент в ветке про return отвечаешь щас)

нашел дурака

Особо не искал, ты сам нашелся)

https://github.com/wandrien/qod/blob/master/src/tests/no_lvalue_1.qd

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

пока что «язык» представляет из себя примерно 25 процентов паскаля.

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

ты вроде не понял о чем речь.

речь о том, что функция в левой части возвращает ссылку! и присваивание в нее корректно.

короче тебе задание.

2000 р./час по скидке. Пользуйся, пока есть возможность.

https://github.com/wandrien/qod/blob/master/src/tests/lvalue_0.qd

ну и чудьненько

2000 р./час по скидке. Пользуйся, пока есть возможность.

да ты прям как доставщик еды цены задираешь.

guard?

Или гард, или так

(defn do-something-cool [x] 
  (when (< x 0) (throw (Exception. "Not cool enough")))
  "Definitely cool")

будешь спотыкаться глазами

Какие-то странные придирки. Наоборот, логично — если when, то else уже не будет, если заменили на if, то скорее всего ради того, чтобы добавить ветку else

потому что они ограничивают юзера в выборе имен для собственных сущностей

Ерунда какая. Сишные ограничивают мою свободу: я так хотел назвать свои переменные if, while, for, auto и особенно int и char, а в питоне так хотел назвать переменную def, но эти языки страшно ограничили меня в выборе сущностей.

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

Влезу.

Разговор про патчи (patch). Нелокальность изменений (patch) вызовет проблемы со слияниями (merge) изменений. Будут проблемы с совместной разработкой. Особенно с изменением логики

Судя по Qod. Опубликовал исходники компилятора, над которым работаю (комментарий)

А ЯП предназначены в первую очередь для чтения человеком.

создается «красивый» язык программирования для увековечивания программ.

создается «красивый» язык программирования для увековечивания программ.

Создаётся язык, синтаксис которого будет способствовать минимизации незамеченных ошибок.

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

Чем, парой дополнительных ключевых слов? И как на форте люди пишут, ведь это же невозможно должно быть — столько слов нужно «учить».

И как люди вообще разговаривают? Ведь в естественных языках столько слов. Ужас просто. Новое ключевое слово when однозначно нарушит весь баланс, и программист позабудет, как его зовут.

синтаксис

несильно поможет в выявлении семантических ошибок.

А вот усложнить изменение (семантики) может, будет язык для красивописателя, writeonly-язык.

несильно поможет в выявлении семантических ошибок.

Бороться против семантических ошибок должна система типов. Пока она крайне примитивная. Экспериментировать с системой типов – это пока в будущем.

А вот усложнить изменение (семантики) может, будет язык для красивописателя, writeonly-язык.

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

• C++
• C
• JS
• Python

Qod планируется как ЯП, который будет пунктом выше С++.

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

у автора самого разброд и шатание. то он пишет через when, то рядом - через if … then… end

еще у автора какие-то селекты подозрительное похожие на if elsif..elsif..end.

но он не сказал в чем их тайна.

система типов

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

имхо снова utf8

можно(нужно!) выбрать скобки

такие что одна пара это блок где первое выражение предусловие превратник остального циклически

другая пара где превратник последнее выражение в блоке

ну а третья классическое с проверкой по середине

ваще эта императивщина вроде как вся исхожена возможно даже есть компиляторы компиляторов где скармливаешь желаемые формы операторов и лексемы а оно выдаёт язык которым не повернёшь

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

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

это и есть разработка синтаксиса. синтаксис это лицо языка. с кондачка такое не делается.

Тоже палка о двух концах.

Да.

сложно менять

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

История развития выразительных средств это по сути история эволюции подходов борьбы со сложностью.

Qod планируется как ЯП, который будет пунктом выше С++.

с горшка на эверест. это по нашему.

Любую нетривиальную программу сложно менять.

Смотря, как срезать углы.

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

Можно писать с ошибками, контролируя (уменьшая) погрешность.

Вы еще забыли о целом классе ключевых слов, относящихся к встроенным в язык операциям.

Вы не можете перегрузить или локально переобъявить sizeof.

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

это и есть разработка синтаксиса. синтаксис это лицо языка. с кондачка такое не делается.

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

Спор вокруг when здесь в комментах это спор не пробовавших сыр о вкусе сыра.

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

если я не знаю и не вижу что у тебя значит a + b, и как оно вычисляется - это говорит, что я вообще не представляю о чем этот код.

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

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

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

Бездумно не надо, но и максимальная общность — ложная посылка. Так дойдём до того, что кроме «ленты», операций записи/чтения и правил перехода ничего больше не нужно. Все языки отменить, оставить один лишь bf.

но и максимальная общность — ложная посылка.

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

https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

по сути - вот:

    Любая программа, заданная в виде блок-схемы, может быть представлена с помощью трёх управляющих структур:

        последовательность — обозначается: f THEN g,
        ветвление — обозначается: IF p THEN f ELSE g,
        цикл — обозначается: WHILE p DO f,

    где f, g — блок-схемы с одним входом и одним выходом,

        р — условие,
        THEN, IF, ELSE, WHILE, DO — ключевые слова[14].

    Пояснение. Формула f THEN g означает следующее: сначала выполняется программа f, затем выполняется программа g.

и не надо изобретать тыщи вариантов трех базовых конструкций.

Спор вокруг when здесь в комментах это спор не пробовавших сыр о вкусе сыра.

Лично у меня вызвало удивление то, что when стал предметом спора. То, что синтаксис немного сыроват и нуждается в правках и уточнениях — да, но это нормальный процесс.
Но чтобы when? Особенно «хорош» аргумент, что это сокращает свободу программиста в выборе имен переменных. Удивительное рядом.

Выполнение операции с предикатом — совершенно логичная, удобная и естественная операция, и вовсе не тождественна if. То, что её обычно реализуют через if — ничего хорошего в этом нет.

Лично у меня вызвало удивление то, что when стал предметом спора.

Да. Аналогично.

Особенно на фоне намного более спорного select case case case вместо привычного if elif elif elif

структурное программирование

https://ru.wikipedia.org/wiki/Структурное_программирование#Двумерное_структурное_программирование

Даешь 3-мерное или даже 4-мерное (пространство и время)

А то застряли на одномерных строчках.