Кисий язык
Я ранее упоминал что, когда выдается свободное время, пилю кисий язык
Кто не читал, лучше почитать по ссылке, там общая идея и идеология. Потому что «кисий язык» это не язык программирования. Ну просто названия другого не придумал, а звучит красиво.
Собственно, есть ряд орг.вопросов, которые возможно помогут решить силы добра на ЛОРе.
Отдельно обращусь к растаманам. я хоть и ругался с вами, но я ругался потому, что мне не нравится то КАК вы решаете проблему и ноете на С++, как будто он является воодушевленным существом типа люфицера. Это тупо, поэтому я вас ругал разными словами. Но само стремление решать проблему похвально. Мне ваше мнение, как ни странно, интересно. Возможно, в итоге вы возьмете мои наработки с сделаете Rust++ который реально убьёт С++.
1) в КЯ предусмотрены переменные как в верилоге:
int a = 5;
int b = 4;
always int c = a + b; //c = 5+4 = 9
a = 2; //c = 2+4 = 6этот момент уже решенный, прошу не спрашивать как будет дело с оптимизацией. будет точно также как с unused variable в Си - вжух и нету.
Однако, вопрос есть такой: мы можем добавить режим «функционального программирования»:
var foo = {
код с returnами; в целом это как лямбда, только без аргументов
}2) 2 разных thisа. Есть this - это класс, к которому применен оператор прямо вот сейчас. а есть например that: это контекст. мы исходим из того, что описывать поведение сложных finite state machine будем в виде отдельных сценариев, которые потом машина сама соптимизирует. так вот каждый сценарий - он как класс. и в нем есть «параметры»:
int calculate(int a, int b) {
parameter int k;
return a*k+b;
}
....
case A {
int k = 2;
int x = calculcate(3,4);
}
...
case B {
int k = 2;
int lol = calculcate(6,8);
}3) Улучшители конкструкций if-elif-else-for-while.
Исходный пример:
bool predicate = ....
while(predicate) {
stmt1;
stmt2;
stmt3;
}bool predicate = ....
always while(predicate) {
stmt1;
####if (!predicate) break;
stmt2;
####if (!predicate) break;
stmt3;
####if (!predicate) break;
}Годна ли идея?
4) блоки кода можно не только «оборачивать» в {} как в С и С++, но и называть:
for(int x in (0,5)) {//не спрашивайте почему это похоже на питон
step сделать_раз {
....
}
step сделать_два {
....
}
step сделать_три {
....
}
}если вам не интересно смотреть внутрь кода этих блоков, IDE покажет вам только названия. это удобно, и те, кто лопатил сотни кода, поймут меня.
Годно ли? Добавить ли что-то?
5) Finite-state machines и короутины. В принципе это одно и то же.
Тут на самом деле вопрос как записывать. Еще вмешивается нюанс реализации. Дело в том, что в итоге код будет генериться «жуткий»: в каждом потоке будет что-то типа futexа, маски прерываний, маски разрешения прерываний, и времени максимальной обработки. не спрашивайте зачем такое - когда пишешь гуй, который должен рендерить и паралелльно что-то считать сложное и исходник для сложного могут при этом редактировать - вот так и приходится. код IDE придется с C++ еще переписать потом на кисий язык.
Так вот, при чем тут корутины? А при том, что у вас будет 1 главный поток и N вспомогательных, и туда будут сигналиться все эвенты как прерывания. код будет исполняться «блоками», в конце каждого блока будет проверяться равенство маски «отсигналенных прерываний» маске «уже виденых». корутина в этот момент может unlikely(префикс 0x2E + jxx) уступить место другой или вообще умереть с исключением.
Вопрос, как это всё записывать? Пока идея такова:
case A(expression_which_can_be_cast_to_bool) {
case A1(expression_which_can_be_cast_to_bool) {
}
case A2(expression_which_can_be_cast_to_bool) {
}
case LOLWAT(expression_which_can_be_cast_to_bool) {
}
}
case B(expression_which_can_be_cast_to_bool) {
...
}
case C(expression_which_can_be_cast_to_bool) {
...
}6) UB: UB разрешено, если оно не влияет на control flow. а именно: ряд операторов в выражениях могут быть неоптимизируемыми в определённых условиях.
int a = x < x+1; //UBint a = x < x+1; //UB
if (a) ... //warning! if (x < x+1) ... //UB нет, "<" не оптимизируется* * *
пока не знаю, что добавить. до вечера смотреть не буду, ибо некогда. пишите, какой я дибил и что это ненужно, нам очень важно ваше мнение.
