Zealint писал(а):
Yoda писал(а):
Тип КАКИХ данных? Если не целых чисел, значит какой-то специализированный тип. Если специализированный, назовём его char.
Тип целых неотрицательных чисел. Размер зависит от вида строки, если это utf (любой), то, видимо, 4 байта.
В таком случае str[j] - никакая не строковая операция, а обычное получение элемента массива, то есть целого числа.
Zealint писал(а):
Yoda писал(а):
Я предложил строки разного типа только в качестве приведения константного значения к нужному размеру целочисленного rvalue. Здесь нет противоречия. UTF8, UTF16 и UTF32 при этом совершенно прозрачно поддерживаются. CP1251 - в топку. На уровне языка никаких кодировок кроме юникода нет. При необходимости левых кодировок они поддерживаются библиотеками (которые всё равно скоро отомрут).
Чем Вы предлагаете заменить операцию str[j]='A' или find(str, 'A')?
Их не надо ничем заменять, они нормально работают в целочисленном представлении. Чувствуя недопонимание, попытаюсь формально изложить правила работы с константными строками.
1. В исходном тексте символьные константы имеют тип "целое число без знака", а строковые константы имеют тип "массив целых чисел без знака".
2. Исходный текст программы допустим только в 8-битной кодировке. Любые 16- и 32-битные кодировки запрещены.
3. Если ожидаемый базовый тип uint8, то никакого конвертирования строк не производится. Это позволяет в исходных текстах прозрачно работать с любыми 8-битными кодировками.
4. Если ожидаемый базовый тип uint16, то строка трактуется как строка UTF-8 и конвертируется компилятором в строку UTF-16 по правилам юникода.
5. Если ожидаемый базовый тип uin32 или больше, то строка трактуется как строка UTF-8 и конвертируется компилятором в строку UTF-32 по правилам юникода.
6. Те же самые правила применяется к отдельным символам за исключением проверки на переполнение. Если после конвертирования символа он оказывается за пределами диапазона целевого типа, компилятор сообщает об ошибке. Например, uint8 c='F'; и uint16 c='Ю'; являются корректными операторами, а uint8 c='Ю'; является ошибочным.
7. Компилятор не проверяет валидность кодовых последовательностей UTF-8 внутри строк, если не производится конвертирование в UTF-16 или UTF-32. Это делается для прозрачной поддержки любых 8-битных кодировок, отличных от UTF-8. Если конвертирование осуществляется, компилятор обязан сообщить об ошибках кодовых последовательностей в исходных строках.
Zealint писал(а):
Yoda писал(а):
Невозможно. Память с общим доступом (т.е. глобальная) нужна не только для поддержки блокировок (атомарных операций), но и для передачи ЛЮБЫХ данных между процессами.
Возможно, так как мы делаем специальный класс для обмена данными.
Во-первых, класс не является синтаксическим ограничением. При помощи класса нельзя наложить запрет на глобальные объекты.
Во-вторых, сам по себе глобальный объект класса не ликвидирует глобальное хранение произвольных типов данных.
В-третьих, на произвольные типы не напасёшься классов.
В общем, это не тот подход.
Zealint писал(а):
Первый вариант. Ключевых слов нет, есть символы, которые из заменяют. Как именно? В кодировке utf8 есть много вариантов. Например, цикл (for) заменяется на кружок со стрелкой
Ещё такой подход делает невозможным использование языка в системах, не ориентированных на юникод. С учётом остальных недостатков, уже отмеченных вами, от этого подхода придётся отказаться.
Zealint писал(а):
Второй вариант. Сделать ключевые слова более богатыми, чем в C++. Если есть for, то должен быть end for, если есть if, то должен быть end if. Это позволит более удобно отслеживать то, который из блоков кода закрывается, если, конечно, мы не напишем 10 if подряд. Однако и здесь есть выход. Снабдить ключевые слова, открывающие блок кода, номерами.
Не надо плодить сущности без необходимости! Блоки кода прекрасно отслеживаются при помощи структурного программирования. Соблюдайте отступы. Да и против end for/end if и других составных эндов я категорически возражаю. Сам по себе end синтаксически абсолютно достаточен.
Zealint писал(а):
Параметры в квадратных скобках не обязательны. А вместо цифр могут быть вообще какие-либо слова. По сути, особого смысла в подобном именовании для условий нет, кроме, быть может, одного – пояснения. Можно сделать такие пояснения и с помощью комментариев
Вот и делайте с помощью комментариев.
Zealint писал(а):
однако здесь компилятору будет легче уловить ошибку, если программист неверно закрыл один из внутренних блоков. Если программист открывает блок и нумерует его, то закрывающий блок end обязан иметь номер.
Я не пойму, какую
именно ошибку вы пытаетесь поймать таким способом? На мой взгляд, это всё - избыточные, ничем не оправданные палки в колёса программиста.
Zealint писал(а):
Более важный смысл подобная нумерация приобретает в связи с использованием циклов (с учётом идеи Сергея об использовании break)
Код:
for [ main ] ( ... )
for [ row ] ( ... )
for [ column ] ( ... )
break [ main ] ( <some-condition> );
end for [ column ]
end for [ row ]
end for [ main ]
Боже мой, до какой степени нечитаемым, оказывается, можно сделать простой кусок кода:
Код:
for ... {
for ... {
for ... {
break [3] condition;
}
}
}
Мой подход (это просто постулат, холивар лишён смысла): язык должен быть лаконичным. Перегрузка языка громоздкими конструкциями существенно ухудшает читаемость (визуальное восприятие) и, как неожиданное следствие, уменьшает
алгоритмическую надёжность. Т.е., увеличивая синтаксическую надёжность, мы затрудняем восприятие и понимание алгоритма, лежащего за синтаксисом, и, как следствие, допускаем больше алгоритмических ошибок.
Zealint писал(а):
Ключевые слова, обозначающие числовой тип данных, могут использоваться без указания числа бит только в одном случае, когда тип имеет «бесконечную» точность. Например, int32 (или Integer32) означает целое со знаком 32 бита. Если написать просто int (или Integer), то это будет целое «бесконечного» размера.
Согласен. Типы с неопределённым (нестандартизированным) размером должны быть под запретом.
Zealint писал(а):
Мне нравится концепция именования, в которой типы данных пишутся с большой буквы и, по возможности, без сокращений. Поэтому-то я и предлагаю Integer32 вместо int32.
Я бы повесился так писать. В соответствии со своей концепцией лаконичности я, наоборот, сделал для себя в С/С++ стандартные определения типов i8, i16, 132, i64, u8, u16, u32 и u64. Не буду утверждать, что это лучше чем int* и uint*, но мне удобно.
Zealint писал(а):
Слово goto должно быть : ) (hollywar expected)
Однозначно. Никакого холивара.
Zealint писал(а):
Я против разного рода обозначений логических и битовых операций вроде ~, !, &, &&, |, ||, ^ и прочих диграфов.
А я - за. Они упрощают запись и визуальное восприятие.
Zealint писал(а):
Либо мы используем юникодовские символы отрицания, конъюнкции и дизъюнкции, а также «плюс в круге», либо not, and и or, а также xor.
...что делает невозможным использование языка в неюникодовых системах и в редакторах, не поддерживающих UTF-8.
Zealint писал(а):
Причём не нужно делать отдельные операции для битовых и логических выражений, так как смешивание этих типов у нас запрещено.
Я тоже сначала так думал. Затем понял, что разделение операторов нужно для устранения неоднозначности по приоритетам. Например, следующее выражение неоднозначно парсится (и самое главное - неоднозначно визуально воспринимается!):
if (a & b == с) ...
Я специально не конкретизирую, какие типы имеют переменные a, b и c. Если же мы делаем побитовые операции с высоким приоритетом а логические с низким, то неоднозначности не возникнет. Поэтому я остановился на разделении побитовых и логических операторов.
Zealint писал(а):
Правильный ответ a = ( b and с ), так как ( a = b ) and с быть не может в принципе (идёт смешивание логического (a=b) и целого (c) типов).
А если с - булевого типа? Компилятор сначала строит дерево операций, затем
проверяет соответствие типов. В противном случае сложность компилятора невероятно возрастает и появляются новые неоднозначности следующего порядка.
Вход
Регистрация
FAQ
Поиск
.