LINUX.ORG.RU

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

 , qod, ,


4

4

Финально определился с названием языка, подчистил разные хвосты и написал README. Теперь наконец-то можно посмотреть на нечто большее, чем просто фрагменты кода в постах на форуме: https://github.com/wandrien/qod/

Драфты по дизайну языка пока еще не готовы. Если перед НГ завала работы не будет, то может выложу их в течение пары недель. Черновики пишу на русском, осилить всё чётко сформулировать на английском в разумные сроки я точно не смогу. На русском-то не всегда получается.

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

А пока можно посмотреть на сам код вживую.

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

операторы чудесатые у тебя

1.while .. do end

2.if then else end

3.when .. :

  1. select … end

forever …

чем 2 3 4 отличаются? зачем forever? какие там еще операторы-то?

указатели, ссылки есть вообще?

как писать блоки типа сишных {…}?

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

чем 2 3 4 отличаются?

when guard : statement

Строго один guard и один statement.

Рассматривай это как аналог when в Аде: exit when A;

Однако читать выражения в обратную сторону, начиная с условия в конце, я рассматриваю как плохую практику. Потому в Qod такая запись будет выглядеть так: when A: exit;

if then else end подразумевает, что может быть else, а также что statements может быть больше одного.

select подразумевает, что guards может быть больше одного.

зачем forever?

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

указатели, ссылки есть вообще?

Есть. Хохлов синтаксически оформил указатели как ссылки, то есть с автоматическим dereference в выражении. Так что они одновременно и указатели, и ссылки. (Тоже в стиле Ады сделано.)

Это я планирую переделать, разбив на отдельные синтаксические формы: тип указателя будет а ля ^int, а тип ссылки а ля @int.

как писать блоки типа сишных {…}?

Никак. Си уже существует.

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

как писать блоки типа сишных {…}?

Никак. Си уже существует.

Может он про такие (Ada - Block Statements) блоки? Типа local scope.

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

Но пока из этого сделана только возможность обращаться с типом как со значением времени компиляции: https://github.com/wandrien/qod/blob/master/src/tests/typeof_0.qd

Закинул черновик на эту тему:

https://github.com/wandrien/qod/blob/master/drafts/comptime-and-runtime-expr.md

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

Рассматривай это как аналог when в Аде: exit when A; Однако читать выражения в обратную сторону, начиная с условия в конце, я рассматриваю как плохую практику. Потому в Qod такая запись будет выглядеть так: when A: exit;

Ну и получается такой же if, только кастрированный. Зачем ещё одно ключевое слово? Идея хвостовых операторов в том, чтобы сместить акцент внимания на саму операцию. А если у тебя будет кудрявый предикат, а где-то далеко справа запрятан exit, то это нифига читаемость не улучшает.

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

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

if (a < b)
  x = 0;
  y = 0;
if (foo())
  if (a < b)
    x = 0;
else
  y = 0;
wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от anonymous

Идея хвостовых операторов в том, чтобы сместить акцент внимания на саму операцию. А если у тебя будет кудрявый предикат, а где-то далеко справа запрятан exit, то это нифига читаемость не улучшает.

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

По итогу я пришел к выводу, что идея смещения акцента не работает. Она смещает акцент на то, что человек перестаёт внимательно читать условие.

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

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

while i < size do
  // бла бла на 10 строк
  ...
  ...
  ...
end when !foo() & bar();

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

Но как только мы это сделаем, сразу появятся те, кто спросит: а почему нельзя написать вот так?

x = ptr^.x when ptr != NULL;
wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

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

что вы там все сочиняете?

while (condition) do end; - это предусловие для охраняемого участка. то есть перед первым исполнением будет проверено условие.

do … while (condition); - это постусловие. оно не будет проверено перед первым исполнением. а бьудет проверяться после каждого исполнения

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

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

вот эта фраза неверно совершенно. идея там в пред- и постусловиях.

Ты не в теме. Попробую на пальцах:

vadim@aquila:/tmp/1$ cat 1.rb 
a = 0
b = 1

while a < 10 do
	puts(a)
	a += 1
end if b != 1
vadim@aquila:/tmp/1$ ruby 1.rb 
vadim@aquila:/tmp/1$ 
wandrien ★★
() автор топика
Ответ на: комментарий от Dr64h

Может он про такие (Ada - Block Statements) блоки? Типа local scope.

я про блоки плюсовые {…} блоки, что не просто являются «областями видимости», а еще и играют ключевую роль в RAII.

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

По итогу я пришел к выводу, что идея смещения акцента не работает. Она смещает акцент на то, что человек перестаёт внимательно читать условие.

А я с этим не спорю. Вводить дополнительное ключевое слово, вот что спорно. Допустим when на хвосте может и нормально (показать, что это не ветвление черезжопное). А так просто читатель будет спотыкаться об этот when, а писатель каждый раз чесать репу: тут when нужно или if. Это немножко уже perl way.

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

А так просто читатель будет спотыкаться об этот when, а писатель каждый раз чесать репу: тут when нужно или if. Это немножко уже perl way.

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

if лучше работает, когда ветвление делается в рамках алгоритма по его существу.

Да, это чисто сахар на усмотрение программиста. Но так-то вообще и все варианты цикла - это сахар. В том же Си можно просто прыгать по метке, вот вам и любой цикл готов без сахара.

perl way это когда ~!@#кровь$%^кишки&*.{сотона,}[]" интерпретируется без синтаксических ошибок. Немножко про другое)

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

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

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

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

Почему «приходится»?

Можно было бы просто сделать в лоб как в lua.

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

Кстати, фишка с select это идея Хохлова, и я сначала удивился… мягко говоря. А потом посмотрел-посмотрел. И понял, что это неплохо.

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

Perl way (timtowtdy) это про кудрявый синтаксис, когда какую-то тривиальную фигню типа if можно записать пятью разными способами, и кодер сидит и думает не про алгоритмы и архитектуру, а как покрасивше цикл изобразить.

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

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

Вопрос в том, какое содержание мы вкладываем в вариативность синтаксических форм. Помогают ли они сделать код надёжнее, или нет.

С одной стороны, есть экстремальные примеры с Ruby (тоже своего рода перловка по заложенным идеям) или мем про создание Си «мы остановились тогда, когда компилятор стал воспринимать случайный набор символов как корректную программу». С другой - Oberon почти без сахара.

Язык программирования всё-таки в той части, за которую отвечает слово «язык» - это про то, как мы читаем и понимаем тексты.

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

Можно было бы просто сделать в лоб как в lua.

Так не надо конечно делать. А кстати, что за фобия такая? Скобочки более декларативные же. begin…end это тяжелое наследие былых времен, когда прикладного программиста считали по дефолту тупым дятлом типа бухгалтерши, которому всё нужно разжевывать: вот начало процедуры, вася, а вот здесь конец, смотри не перепутай. Сейчас зачем это всё? Типа меньше шума? Все равно ведь нашумишь когда будешь структуры и типы описывать.

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

А кстати, что за фобия такая?

Никакой фобии. Пишу на Си-подобных чуть больше чем постоянно.

Скобочки более декларативные же.

Это утверждение лишено содержания. Более декларативной может быть суть, но не форма слов.

begin…end это тяжелое наследие былых времен, когда прикладного программиста считали по дефолту тупым дятлом типа бухгалтерши, которому всё нужно разжевывать: вот начало процедуры, вася, а вот здесь конец, смотри не перепутай.

Проблема begin…end не в том, что они «менее декларативные» (что бы это ни значило), а в том, что бессмысленные. Это тот же блок {}, только на на 6 бессмысленных нажатий на клавиатуре больше.

У меня никаких begin…end не водится.

Сейчас зачем это всё?

      }
    }
  }
}
      end:if
    end:loop_y
  end:loop_x
end:function
wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Проблема begin…end не в том, что они «менее декларативные» (что бы это ни значило)

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

end:function

Клёвая разметка, но вообще редактор может подсветить скобочки и подсказать, что там в начале блока. Даже xml лаконичнее.

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

Клёвая разметка, но вообще редактор может подсветить скобочки и подсказать, что там в начале блока.

Вот со скобочками и приходится очень часто смотреть, откуда растёт эта скобочка.

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

Как человек, который 20 лет пишет и читает код на разных {}-подобиях, вижу разницу.

Даже xml лаконичнее.

Лаконичность ты сам регулируешь. Можно писать просто end.

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

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

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

Переделывать я, конечно, не буду от того, что «анону на лоре что-то не понравилось». А вот поговорить о синтаксических формах - всегда пожалуйста. С одной стороны, другие люди могут мне сообщить интересные идеи, решения или намётки решений. С другой стороны, это позволяет лучше увидеть что именно я сам понимаю, а вот собеседники не особо понимают.

Относительно второго, вот это характерная штука: «На самом деле я терпимо отношусь к алгольщине.»

Фишка-то в том, что это как раз не алгольщина. Если брать синтаксические формы, то алгольщина - это Алгол, Паскаль и… внезапно Си и всего его деривативы.

Си воспроизводит структуру форм Алгола почти дословно. С разницей всего в одну лишнюю лексему. (У Си на 1 одну лексему больше).

Алгол:
WHILE   усл DO утвержд
Си:
while ( усл )  утвержд

Алгол:
IF   усл THEN утвержд
Си:
if ( усл )    утвержд

Алгол:
BEGIN утвержд... END
Си:
{     утвержд... }

Как видно, открывающая круглая скобка у Си избыточна и добавлена чисто «для красоты». А в остальном это то же самое.

И если, например, брать Паскаль, то меня всегда раздражало, что при описании алгоритмов это просто «Си, в котором надо печатать больше букв». А зачем печать больше букв, если при прочих равных можно печатать меньше?

В то же время языки Ada, Ruby, Lua или вот Qod используют структуру с имплицитным блоком. Блок утверждений внедрён в составное утверждение по умолчанию, и его не требуется отдельно «начинать» и «завершать». Когда завершается синтаксическая форма, завершается и вложенный блок. Это решает проблему висячего else, делает код более выразительным и «плотным», а также (опционально) позволяет надёжно проверять границы блоков.

Классическое: «Буквы другие, смысл тот же» vs «Буквы те же, смысл другой».

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

Фишка-то в том, что это как раз не алгольщина. Если брать синтаксические формы, то алгольщина - это Алгол, Паскаль и… внезапно Си и всего его деривативы.

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

Как видно, открывающая круглая скобка у Си избыточна и добавлена чисто «для красоты».

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

В то же время языки Ada, Ruby, Lua или вот Qod используют структуру с имплицитным блоком.

Круто звучит, но там всё те же блоки, которые нужно как-то размечать. Иногда без явного begin никак не обойтись.

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

Круто звучит, но там всё те же блоки, которые нужно как-то размечать. Иногда без явного begin никак не обойтись.

Разница именно по смыслу. В if или while блок и соответствующий локальный scope возникает «естественным образом», то есть при чтении текста вполне закономерно, что он должен там быть.

Если же блок нужен явно, то для него нужно и отдельное представление, своя синтаксическая форма.

Если смотреть на синтаксис как на чисто формальный инструмент записи алгоритма, то подход Си, Паскаля и Алгола 60 выглядит более уместным. Но если рассматривать синтаксис как то, что оформляет смысл в виде зримой материи, то вещам, которые предназначены для разного, лучше по-разному и выглядеть.

Практических смыслов отдельного блока я вижу два:

  • Ограничение видимости и времени жизни переменных.
  • Возможность делать exit, перепрыгивая к концу именованного блока.

Выглядеть это может как-то так:

label my_block: do
  ...
  auto x = foo();
  ...
  when x == 0: exit my_block;
  ...
end:my_block

Пока, правда, ни метки, ни именованный exit не реализованы.

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

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

Ну так: внутривидовая борьба самая жестокая.

Мало кому в голову придёт холивар «паскаль vs баш». А вот vs Си – очевидно.

Не для красоты, а для балансировки скобок.

Это незначительная деталь, можно было бы сделать так, и суть бы не поменялась:

int x = 0;
while x < 10: {
  if foo(x): printf("%d\n", x);
  x++;
}

В любом случае управляющие конструкции в Си - это тот же Паскаль, вид сбоку.

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

Прикольно, что по такой логике паскаль и си ничем не отличаются синтаксически

Отличаются, но в других частях синтаксиса, а не в этой.

Паскаль: производные типы читаются линейно слева направо.

Си: производные типы читаются справа налево и изнутри наружу.

(Темы записи типов я еще коснусь в черновиках по языку.)

Паскаль: процедуры и функции.

Си: любая подпрограмма есть функция; функция может возвращать «ничего» как допустимый тип данных.

Паскаль: Name без скобок может означать вызов функции без аргументов.

Си: Вызов функции всегда явно маркируется скобками. Name без скобок это указатель на функцию.

Паскаль: присваивание и инкремент - это операторы.

Си: присваивание и инкремент - это операции.

Это из того, что быстро вспомнилось, вероятно заметных различий сильно больше…

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

Ну так: внутривидовая борьба самая жестокая.

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

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

дык если именнованые блоки то тогда

break и continue + именнованые блоки + when(али какой Short-circuit evaluation если всё в языке выражения) тьюринг полно - но без произволтого гото на метку

интересней(пока доки не смотрел :) ) - как структуры данных определяются

ну и есть какая асинхро|сопро|конку|парале|лениво вот это вот всё в языке?

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

но без произволтого гото на метку

Разрешены continue в цикле и exit в блоке/цикле. Таким образом в графе переходов не может быть goto куда попало. Такой граф удобно анализировать на уровне AST, без раскладки в граф базовых блоков промежуточного языка.

пока доки не смотрел

А их пока и нет))

ну и есть какая асинхро|сопро|конку|парале|лениво вот это вот всё в языке?

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

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

си был «урезан» отказом от вложенных исполнимых именованных блоков(в паскале проседура может быть (в симуле стала)-класом чьи подпроцедуры это методы :)

поэтому в С(С++) класс это виртуализация структуры данных struct в отличии от Симулки где класс это обобщение кода процедуры с вложениями :)

код это данные это код очередное

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

Планирую сделать break и exit отдельными операторами:

break; // Прерывает самый внутренний цикл
break имя; // Прерывает указанный цикл. Если метка не соответствует циклу - ошибка.
exit имя; // Прерывает указанный блок, который не является циклом. Если метка соответствует циклу - ошибка.
wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

И потом у вас все будут писать:

when x > 0: begin
  A();
  B(x);
  C(y);
end;

И чем это от if отличаться? Блоки в языке должны быть полюбому, хотя бы для RAII.

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

И потом у вас все будут писать:

Писать на брейнфаке можно на любом языке.

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

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

Блоки в языке должны быть полюбому, хотя бы для RAII.

Это, кстати, далеко не «полюбому». Автоматический деструктор плохо ложится на линейные типы, например.

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

записывать операторы более надёжно

Откуда появляется надёжность от альтернативного синтаксиса if? Про надёжность от borrow checker в Rust понимаю. Про надёжность альтернативного синтаксиса if не понимаю. Грабли на пустом месте.

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

Даже для RAII по типу оператора defer нужны блоки кода.

Это автоматический деструктор на костылях и в профиль.

Смысл линейного типа, что ты не можешь деть его экземпляр «никуда», ты его должен разрушить строго один раз.

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

ты его должен разрушить строго один раз.

Как вы представляете компилятор будет это проверять? Особенно с учётом наличия указателей.

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

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

Это решается через обязательные скобки

Отлично. У меня как раз их есть:

if foo() then
   if a < b then
     x = 0;
   end
else
   printf("Как вы там, потомки, решили проблему висячего else?\n");
end

А теперь более кратко:

if foo() then
   when a < b:
     x = 0;
else
   printf("Как вы там, потомки, решили проблему висячего else?\n");
end

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

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

Как вы представляете компилятор будет это проверять? Особенно с учётом наличия указателей.

Читайте, образовывайтесь, изучайте передовую литературу.

Был вы вопрос без претензии задан, я бы ответил. А так – гугл в помощь.

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

А теперь более кратко:

ЗАЧЕМ??? Так сложно написать end? Решительно не понимаю. Такое чувство что у вас появилась глубокая травма от того, что долго разбирались почему не работает код из-за того что else относился не к тому if.

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

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

Зря я тебя когда-то из игнора вытащил. Общаться прилично ты так и не научился.

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

ЗАЧЕМ???

За тем

bool T_Equal(word T1, T2)
	when T1 >= nDict:
		StopInternal(__FILE__, __LINE__);

	when Dict[T1].Class != cTYPE:
		StopInternal(__FILE__, __LINE__);

	when T2 >= nDict:
		StopInternal(__FILE__, __LINE__);

	when Dict[T2].Class != cTYPE:
		StopInternal(__FILE__, __LINE__);

	when T1 == T2:
		return true;

	if Dict[T1].Sub == Dict[T2].Sub then
		select
		case Dict[T1].Sub == sBASE_UINT | Dict[T1].Sub == sBASE_SINT:
			when Dict[T1].TypeSize == Dict[T2].TypeSize:
				return true;
		end:select
	end:if

	return false;
end

За тем

void DictAddToNamespace(word P; word pNamespace)
	when P >= nDict:
		StopInternal(__FILE__, __LINE__);
	when Dict[P].pNamespace != nDICT:
		StopInternal(__FILE__, __LINE__);
	when Dict[P].pNext != nDICT:
		StopInternal(__FILE__, __LINE__);
	when Dict[pNamespace].pFirst != nDICT & Dict[pNamespace].pLast == nDICT:
		StopInternal(__FILE__, __LINE__);
	when Dict[pNamespace].pFirst == nDICT & Dict[pNamespace].pLast != nDICT:
		StopInternal(__FILE__, __LINE__);
	/* FIXME: когда глобальное пространство имён будет реализовано отдельным объектом namespace, убрать этот return */
	when pNamespace == nDICT:
		return;
	when pNamespace >= nDict:
		StopInternal(__FILE__, __LINE__);

	Dict[P].pNamespace = pNamespace;
	if Dict[pNamespace].pLast < nDICT then
		Dict[Dict[pNamespace].pLast].pNext = P;
		Dict[pNamespace].pLast = P;
	else
		Dict[pNamespace].pFirst = P;
		Dict[pNamespace].pLast = P;
	end:if
end

И за этим

bool T_IsFuctTypesIdentical(word T1; word T2)
	when T1 >= nDict:
		StopInternal(__FILE__, __LINE__);

	when T2 >= nDict:
		StopInternal(__FILE__, __LINE__);

	when T1 == T2:
		return true;

	when !((Dict[T1].Class == cTYPE & Dict[T1].Sub == sFUNCTYPE) | (Dict[T1].Class == cFUNC)):
		return false;

	when !((Dict[T2].Class == cTYPE & Dict[T2].Sub == sFUNCTYPE) | (Dict[T2].Class == cFUNC)):
		return false;

	when Dict[T1].pType != Dict[T2].pType:
		return false;

	word pARGS1 = FindInNamespace("args", T1);
	word pARGS2 = FindInNamespace("args", T2);
	when pARGS1 >= nDICT | pARGS2 >= nDICT:
		StopInternal(__FILE__, __LINE__);

	word P1 = Dict[pARGS1].pFirst;
	word P2 = Dict[pARGS2].pFirst;
	forever do
		when P1 == nDICT & P2 == nDICT:
			return true;

		when P1 == nDICT & P2 != nDICT:
			exit;
		when P1 != nDICT & P2 == nDICT:
			exit;
		when Dict[P1].pType != Dict[P2].pType:
			exit;

		P1 = Dict[P1].pNext;
		P2 = Dict[P2].pNext;
	end:forever

	return false;
end

wandrien ★★
() автор топика
Ответ на: комментарий от wandrien
when P1 == nDICT & P2 == nDICT:
			return true;

when P1 == nDICT & P2 != nDICT:
			exit;
when P1 != nDICT & P2 == nDICT:
			exit;

тут 6 сравнений вместо двух. со всеми вытекающими. от эффективности кода, до читаемости и потенциала к ошибкам.

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

до читаемости и потенциала к ошибкам.

Да, вот так должно выглядеть:

forever do
  when P1 == nDICT & P2 == nDICT:
    return true;

  when P1 == nDICT:
    return false;
  when P2 == nDICT:
    return false;
  when Dict[P1].pType != Dict[P2].pType:
    return false;

  P1 = Dict[P1].pNext;
  P2 = Dict[P2].pNext;
end:forever

от эффективности кода

А вот это буллшит.

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

Вот кстати, фишка. Допустим я убрал return false в самом конце, но забыл заменить один из exit на return false:

	word P1 = Dict[pARGS1].pFirst;
	word P2 = Dict[pARGS2].pFirst;
	forever do
		when P1 == nDICT & P2 == nDICT:
			return true;

		when P1 == nDICT:
			return false;
		when P2 == nDICT:
			return false;
		when !T_Equal(Dict[P1].pType, Dict[P2].pType):
			exit;

		P1 = Dict[P1].pNext;
		P2 = Dict[P2].pNext;
	end:forever
end

Получаем ошибку компиляции:

ошибка: Функция должна возвращать значение
wandrien ★★
() автор топика
Ответ на: комментарий от X512

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

Явное лучше неявного. Например, синтаксис C и C++ пестрит такой огромной кучей неявностей и неопределённостей, что многие крупные IT-компании составляют собственные километровые «coding conventions» мануалы, чтобы избежать типичных ошибок, которые были набиты полувековым опытом программирования на этих языках.

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

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

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

Я не понимаю какую проблему тут пытаются решить. Сократить чтобы не писать end?

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

Я не понимаю какую проблему тут пытаются решить.

Я выше показал примеры функций. Ты поставил фейспальм, но я не увидел, чтобы ты предложил своё решение, как этот код записать более читабельно.

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

Это, кстати, далеко не «полюбому». Автоматический деструктор плохо ложится на линейные типы, например.

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

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

Читабельно-то как…

	if P >= nDict then
		StopInternal(__FILE__, __LINE__);
	end
	if Dict[P].pNamespace != nDICT then
		StopInternal(__FILE__, __LINE__);
	end
	if Dict[P].pNext != nDICT then
		StopInternal(__FILE__, __LINE__);
	end
	if Dict[pNamespace].pFirst != nDICT & Dict[pNamespace].pLast == nDICT then
		StopInternal(__FILE__, __LINE__);
	end
	if Dict[pNamespace].pFirst == nDICT & Dict[pNamespace].pLast != nDICT then
		StopInternal(__FILE__, __LINE__);
	end
wandrien ★★
() автор топика
Ответ на: комментарий от X512

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

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

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

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

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

Я просто не поникаю в чём трудность писать end после каждого if и что там трудночитаемого. Не понимает мой разум этого и всё. Видимо это вопрос личных привычек и предпочтений.

Если его так лень писать, то есть шаблоны кода в IDE по сочетаниям клавиш.

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

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

В частности, к этому случаю относится типовая ошибка после копипаста, которая порой может оставаться незамеченной годами, а ля:

a.x = b.x;
a.y = b.y;
a.z = b.x;

Так вот в примере выше мозг видит прежде всего это:

if
end
if
end
if
end

А должен бы - это:

when
  StopInternal
when
  StopInternal
when
  StopInternal
when
  StopInternal
wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

Ну сделай уже if x : y вдобавок к обычному if без двоеточия. Видишь как лоровцы рвутся от этого when. Так и все гипотетические юзеры будут рваться. Оно и правда необычно, дуиаешь то ли это паттерн матчинг какой, то ли хз что.

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

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

when же стандартная конструкция во многих языках, зачем if перегружать. Это if без else, условное выполнение стейтмента. Странно, почему эта мысль для некоторых настолько необычна, что они от этого рвутся.

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

when же стандартная конструкция во многих языках, зачем if перегружать

Такой when не нужен. Это частный случай if. Лучше сделать однострочные варианты всех управляющих конструкций, если уж автор так любит однострочники. Это хотя бы консистентно, а не просто «дай накидаю ключевых слов для случайных юзкейсов».

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

Такой when не нужен. Это частный случай if.

Отчего такое отвращение к дополнительным ключевым словам? if подразумевает возможность else, тогда как when семантически читается как ограждающее условие и else не подразумевает.

Лучше сделать однострочные варианты всех управляющих конструкций

Путаницу это не исключает никак, только провоцирует ошибки.

консистентно

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

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

Отчего такое отвращение к дополнительным ключевым словам?

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

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

if подразумевает возможность else, тогда как when семантически читается как ограждающее условие и else не подразумевает.

А когда тебе приспичит добавить else к существующему when тебе придется менять when на if и в патче будет лишняя строчка о которую ты будешь спотыкаться глазами - «там действительно только when на if заменили или еще что-то в условии поправили?»

Я не против экстра ключевых слов кстати. Можно unless и until обсудить например. Только вот выгядят они слишком одинаково на мой глаз (надо синонимы поискать). Ключевые слова никто не читает - их окидывают взглядом и понимают где какое слово по размеру и форме. if, else, for, while, do, break, continue, return, struct, union в этом смысле подобраны очень удачно.

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

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

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

1. Автор не «любит» однострочники. У автора даже в коде компилятора when используется исключительно в виде двух строк:

when что-то:
  что-то делаем;

2. «Лучше сделать однострочные варианты всех управляющих конструкций». Лучше для чего? Есть какие-то критерии этого лучше? Выше по треду же подробно обсуждалось, почему when именно when, а не if, для чего он нужен, и почему для этих кейсов if работает плохо.

Это хотя бы консистентно

Консистентно сделали в Паскале и Си. Проблемы с консистентностью синтаксических форм обсуждались парой страниц ранее.

В данном случае задача обратная – сломать консистентность. Мозг не машина, он не парсит грамматику так же, как компилятор. А ЯП предназначены в первую очередь для чтения человеком.

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

Если необходимость освоить значение пары ключевых слов вызывает такие страдания, возможно это говорит о возрастных изменениях головного мозга. В этом случае единственное, что можно сделать – писать на ЯП, которые уже освоены, пока желание и силы что-то писать еще в принципе есть. Все там будем…

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 2)
Ответ на: комментарий от anonymous

А когда тебе приспичит добавить else к существующему when тебе придется менять when на if и в патче будет лишняя строчка о которую ты будешь спотыкаться глазами - «там действительно только when на if заменили или еще что-то в условии поправили?»

А когда предложенный гипотетический вариант if ... : менять на if .. then, то дополнительная строчка в патче не появится?

Я не против экстра ключевых слов кстати. Можно unless и until обсудить например.

А я как раз против unless и until. unless это понты разработчика ЯП.

С until ситуация сложнее. В Си синтаксис позволяет записать do statement while cond, и это будет парситься однозначно.

Но в синтаксисе с неявным блоком, while будет парситься как начало цикла с пред-условием. Поэтому для цикла с пост-условием приходится придумывать материально отличающееся выражение ключевых слов. По этой причине у меня есть:

repeat
  что-то делаем
until обратное_условие;

Но он мне активно не нравится. Он существует только потому, что я не придумал, чем заменить until.

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

Путаницу это не исключает никак, только провоцирует ошибки.

Именно так. Мало того, что предложено по сути вернуться к синтаксису Си и Паскаля и вернуть все их проблемы, которые обсуждались ранее. Так еще и оставить при этом формы операторов с неявным блоком.

Это получится уже совсем лютый треш.

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

И поэтому должен чётко и однозначно считываться в тексте.

А такое:

if условие & и еще какое-то условие & и еще:

это какое-то издевательство над читателем, игра «найди двоеточие в конце».

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

а зачем единить имён пространство - тока для текста поиска безконтекстного шоля?

патомушто лексер будет ковертировать поток буков в поток лексем. и будут у него вместо идентификаторов лексемы навроде lex_while, lex_if, lex_when. и если ты напишешь when как идентификатор, это будет лексемой lex_when, что естественно компилятор воспримет как ошибку.

auto when = 100; 

Чоо? - скажет компилятор, - у меня when это оператор такой, типа условный.

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

Но в синтаксисе с неявным блоком, while будет парситься как начало цикла с пред-условием.

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

some_result parse_block (LexTypeSet end_block_symbols);

и поскольку блок может заканчиваться разными символвами - end, }, until, else, case, default… и так далее (от грамматики зависит разумеется ) - то парсинг блока делается с конкретным набором символов, которые могут закончить данный блок.

если ты парсишь блок после «if cond then…» то будешь парсить блок с множеством стоп-символов {else_sy, elsif_sy, end_sy}, если после «case 100:» то будет множество - {case_sy, end_sy, else_sy}.

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

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

не будет

Да правда что ли. А ну-ка распарси мне грамматику в тексте без отступов:

int i = 0;
int x;
repeat
x = foo(i);
inc i;
while
x != 0 or
fooBarBaz(x)
/* дальше не видно */

если ты парсишь блок после «if cond then…» то будешь парсить блок с множеством стоп-символов {else_sy, elsif_sy, end_sy}, если после «case 100:» то будет множество - {case_sy, end_sy, else_sy}.

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

Вопрос не в том КАК это сделать, а ЗАЧЕМ так делать.

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

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

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

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

Золотце

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

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

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

дерзай короче, исследователь.

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

Про этап лексического анализа в «настоящих компиляторах» особенно задорно получилось.

Код:

template <typename T>
struct X {
    T x;
};

template <typename T>
struct Y {
    T x;
};

Y<X<int>> y;

В gcc -std=c++11 – компилируется.

В gcc -std=c++98 – получаем это:

<source>:16:8: error: '>>' should be '> >' within a nested template argument list
   16 | Y<X<int>> y;
      |        ^~
      |        > >

Сломанный к херам этап лексического анализа выглядит именно так.

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

просто сравни два способа писать компиляторы и успокойся. для разогрева, сравни свой с хохловым 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);
	}
alysnix ★★★
()
Ответ на: комментарий от alysnix

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

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

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

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

легко

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

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

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

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

легко 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;
}

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

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

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

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

return a>b;

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

when a>b: return true
return false

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

нашел дурака

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

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

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

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

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

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

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

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

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

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

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

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

Влезу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • C++
  • C
  • JS
  • Python

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

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

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

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

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

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

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

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

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

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

имхо снова utf8

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

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

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

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

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

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

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

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

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

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

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

Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

То, что её обычно реализуют через if — ничего хорошего в этом нет.

так классический if и есть операция с предикатом с необязательным else. это потом его расширили на форму if elsif elsif else… что есть просто синт. сахар к классической.

то есть в си, у которого классическая форма (см вики) if - как раз и реализует ваш when, как частный случай.

просто вандриен, будучи увлечен if elsif…end, изобрел when, как вариант классики, дабы иметь возможность краткой записи.

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

А операция умножения — частный случай операции сложения, которая, в свою очередь, частный случай операции succ. Так до мышей машины Тьюринга и дойдём.

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

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

я ж сию конструкцию уже упоминал стопицот раз примерно, и так не понял зачем она вообще, если есть if elif

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

в твоем брейнфаке «try catch» будет?

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

try catch

Синтаксический сахар же, ненужно.

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

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

удобная и естественная. но еще удобней и естественней форма в которой и на невыполнение предиката есть вариант исполнения. то есть классический if.

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

Это Хохлов придумал. Я попробовал, понравилось.

Некросивое, несимметричное:

if foo() then
  x = 0;
elif bar() then
  x = y + 1;
elif baz() then
  x = y - 1;
end

Кросивое, симметричное:

select
case foo():
  x = 0;
case bar():
  x = y + 1;
case baz():
  x = y - 1;
end
wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

просто убери then. это давно уж в пытоне сделали. и будет

if foo():  x = 0;
elif bar(): x = y + 1;
elif baz():  x = y - 1;
end

убери все эти do, of, then.. короче если блок можно открыть через : - то это и использовать

struct A :
  int _x;
end
alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 3)
Ответ на: комментарий от alysnix

но еще удобней и естественней форма в которой и на невыполнение предиката есть вариант исполнения. то есть классический if.

Нет. Удобнее как раз, когда при невыполнении предиката осуществляется переход к следующей операции.

Что же так от when корежит? Не пойму. Ну а хотя бы assert идиосинкразию не вызывает?

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

А при чем тут then, если речь про разницу if/elif. Ты совсем не схватываешь на лету.

Для локальности изменений в гит select лучше:

-if foo() then
+if foo2() then
+  stop();
+elif foo() then
   x = 0;
 elif bar() then

vs

 select
+case foo2():
+  stop();
 case foo():
   x = 0;
wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

Для локальности изменений в гит select лучше:

причем тут гит? они идут пакетом у тебя???…

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

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

Ты совсем не схватываешь на лету.

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

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

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

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

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

Ты опять не схватываешь.

Речь шла про:

  • Конфликты при слияниях.
  • Удобство чтения диффов.

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

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

для себя часто использовал

Да, тоже так иногда пишу.

А если приходится генерировать ветки препроцессором на сях, то это вообще единственный вариант.

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

это ты не схватываешь - а если у тебя гит заберут, половина языка на вынос, в мусорном мешке?

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

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

убери все эти do, of, then.. короче если блок можно открыть через : - то это и использовать

Точняк. Если можно писать в машкодах, то это и использовать.

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

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

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

Я дико веселюсь с этого обсуждения.

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

При чём отдельно еще забавно вот что.

Я мимоходом упомянул, что синтаксис select лучше подходит для локализации изменений в патчах. Собеседник на это пишет: «ты реально считаешь, что язык должен быть заточен под левую тулзу».

То есть отрыв от реального предмета разговора – очень велик. У собеседника какие-то свои мухи в голове летают, и он с ними ведёт диалог.

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

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

«зачем ты перенес строку! появились же две измененные строки! теперь невозможно сделать мердж! это невозможно уже читать! верни все на место!» - это у вас так в конторе работают? мама дорогая…

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

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

Диалог какой-то такой:

- Зачем Б, если есть А.
- Б выглядит симметричнее, а еще имеет вот такое практическое преимущество.
- *возмущательные возгласы*

Реально, я вот чо-то перечитал ветку, и мне стало интересно.

На вопрос о том, чем хорош select, я ответил. Собеседник топит за elif. А аргументы какие-то были за elif? Получается, что ведь не было.

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

Я мимоходом упомянул, что синтаксис select лучше подходит для локализации изменений в патчах.

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

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

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

Я настаиваю, что чего? Ты снова не схватываешь, похоже.

«зачем ты перенес строку! появились же две измененные строки! теперь невозможно сделать мердж! это невозможно уже читать! верни все на место!» - это у вас так в конторе работают? мама дорогая…

Может, глицина?

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

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

может на государственном или мировом уровне встал вопрос о нелокальности патчей? откуда это все взялось хоть?

в чем причина затруднений и каков масштаб ущерба в долларах от «нелокальных патчей»?

я столько грибов не ем, чтобы врубиться.

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

А аргументы какие-то были за elif? Получается, что ведь не было.

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

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

Gentlemen, your conversation makes interesting listening.

Ты так прикольно сливаешься каждый раз))

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

И это человек, у которого «этих языков как мух» (или как там было).

То when не тот, то грамматики нет, то гит, то elif.

Странно это, и очень похоже на ревность и зависть к языку, который работает, в отличие от «мух».

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

То when не тот, то грамматики нет, то гит, то elif.

я ж сказал, что без грамматики и обсуждать нечего. откуда я знаю, есть у него elif или нет? по исходникам это смотреть что-ли? мне казалось, что что-то есть… он говорит - нет. ну нет и нет. зато есть мега select, тогда пусть или трусы оденет или крестик снимет. если есть select - зачем if.

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

Про то, что EBNF надо в первую очередь формализовать — это справедливо. Хотя бы в двух словах, пусть не EBNF — как минимум лексемы и ключевые слова перечислить — даже в исходниках лексера копаться удовольствие так себе, тем более, что он на несколько модулей разбит.

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

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

Это не так работает, ребята.

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

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

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

Уважение это характеристика, возникающая по факту отношения с чем-либо/кем-либо.

Публикация на исходников на гитхабе не формирует мои отношения с читателями кода. Поэтому выкладывать исходники «с уважением» или «без уважения» я не могу. Это не релевантно.

А вот если они захотят мне что-то написать. то инициатива исходит от них. Им и решать, с уважением они это делают или нет. В меру своей воспитанности.

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

И еще одно.

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

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

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

формирует мои отношения с читателями кода

Формирует, формирует.

Точнее, с читателями кода — наверное. Но это такая особая категория — всегда найдутся те, кому нравится копаться в слабоструктурированной лапше без документации, по типу «угадай, что делает эта консрукция». Ну хорошо, пусть будут не мусорщики, а египтологии/любители головоломок, полтора инвалида.

С теми, кто мог бы заинтересоваться самим языком на более высоком уровне — таки формирует.

следует вообще никогда ничего не публиковать

Годный план.

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

на фоне намного более спорного select case case case

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

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

В выжал бейсике такое было. Так что поздравляю, ты переизобретаешь бейсик.

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

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

Нет, это про CoffeeScript.

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

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

Нет, это про CoffeeScript.

Нет, это про Forth и ему подобные.

Разве CoffeeScript конкатенативный? Обычная надстройка над JS, нафиг никому не нужная, с кучей привычных сишных скобочек.

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

Так это главная фича бейсика.

Главная фича бейсика - это что первоначально он влезал в ПЗУ восьмибитной машины.

Все остальные VB и VB.NET это попытка MS оживить помершую, но когда-то любимую лошадь. Однако эта попытка не лишена изящества.

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

Многие влезали, и влезают.

А главная фича (оригинального) Бейсика — в до дурости простой реализации интерпретатора. При этом сохраняя возможность написать не нём что-нибудь осмысленное и читабельное.

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

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

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

классический if

это арифметический IF statement с ветвлением на три результата

https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn9p/index.html

cat t.f; f77 t.f && ./a.out
        A = 1
        B = 2
        C = -3
        D = B**2 - 4*A*C
        IF (D) 10, 20, 30
30      PRINT *, ( SQRT(D) - B )/2/A
20      PRINT *, ( - SQRT(D) - B )/2/A
10      CONTINUE
        END
t.f:5:72:

    5 |  IF (D) 10, 20, 30
      |                                                                        1
Warning: Fortran 2018 deleted feature: Arithmetic IF statement at (1)
   1.00000000
  -3.00000000

Логический IF с предикатом добавили чуть позже

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

реально классический(ариф) это трипути sign

откуда взято что закорюка изображающая if в фортране - это и есть «классический if».

классический if это правило вида

"if" bool_exression "then" operator
"else" operator
alysnix ★★★
()
Ответ на: комментарий от alysnix

был Такой МакКарти(elefant его) - апосля ариф if Бекуса&Ко

ОН предложил многопутевой cond - комитет отказался и только после всё заверте в lisp'е

if then else появился чуть позже и парралельно с генезисом скобок скобкофилов

классика локальна :)

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

"if" bool_exression "then" operator "else" operator

К 1960 напридумывали и не такое:

IF X EQUALS Z THEN MOVE A TO B; 
	OTHERWISE ADD A TO C AND ALSO IF NOT POSITIVE,
	GOTO ERROR-ROUTINE; OTHERWISE ADD A TO B AND ALSO PERFORM PATH-1 THRU PATH-6.

https://bitsavers.computerhistory.org/pdf/codasyl/COBOL_Report_Apr60.pdf?page=35

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

Зачем в C switch если есть if?

if - это выбор по разным булевским выражениям.

switch - это множество вариантов одного! арифметического выражения.

код у этих операторов разный вообще.

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

что для одного константа для другого переменная

ващет набор проверок и есть число

да же если есть побочки проверок это всё отображаемо в число с побочками

чуствую без работы люди с цпш не остануться

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

код притом, что switch делается как выборка адреса ветки исполнения из таблицы переходов, а if - как последовательная проверка условий пока не найдется то, что дает true.

это у тебя с хохловым это одно и то же небось

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

Это деталь реализации. Выбираться он может хоть обращением к Всезнающему Оракулу, для описания языка это иррелевантно.

Познакомься с тем, как работает современный оптимизирующий компилятор:

enum X {
    X1, X2, X3, X4, X5
};

extern int foo1(int);
extern int foo2(int);
extern int foo3(int);
extern int foo4(int);
extern int foo5(int);

int bar(X x, int y)
{
    if (x == X1) return foo1(y);
    if (x == X2) return foo2(y);
    if (x == X3) return foo3(y);
    if (x == X4) return foo4(y);
    if (x == X5) return foo5(y);
    return 0;
}
bar(X, int):
        mov     eax, edi
        mov     edi, esi
        cmp     eax, 4
        ja      .L4
        jmp     [QWORD PTR .L6[0+rax*8]]
.L6:
        .quad   .L10
        .quad   .L9
        .quad   .L8
        .quad   .L7
        .quad   .L5
.L7:
        jmp     foo4(int)
.L5:
        jmp     foo5(int)
.L10:
        jmp     foo1(int)
.L9:
        jmp     foo2(int)
.L8:
        jmp     foo3(int)
.L4:
        xor     eax, eax
        ret

Что ты не понимаешь про семантику, это уже ясно.

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

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

а дай-ка код на асме для выражения(это псевдокод)

int lval = 10;
int lcnt = 0;

switch (lval) 
case 1: lcnt = lcnt+10
case 5: lcnt = lcnt+20
case 10:lcnt = lcnt+30
default:  lcnt = 100
}

короче интересно, как у тебя табличка генерится. у тебя похоже и нет ее.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 2)
Ответ на: комментарий от wandrien

Это деталь реализации.

неа. это какой-компилятор подменил if, в силу того, что он просто есть извращенный switch, на нечто вроде него.

что как раз и говорит, что switch - это вполне себе базовый оператор, в который иногда вон и if переделывают.

то есть switch это не «деталь реализации», это и есть реализация. и без этой «детальки» твоя телега далеко не уедет.

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

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

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

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

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

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

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

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