OSDev

для всех
Текущее время: 15 июл 2019, 20:57

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 285 ]  На страницу Пред.  1 ... 13, 14, 15, 16, 17, 18, 19 ... 29  След.
Автор Сообщение
СообщениеДобавлено: 25 дек 2014, 10:38 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
SII писал(а):
Операция однозначно устанавливается по типу участвующих данных

Теоретики... Вот пример, все операнды целые:
Код:
a = b and c   // это
(a = b) and c // или
a = (b and c) // ведь операции неразличимы

Другой пример: в SQL пришлось ввести оператор || для конкатенации строк, поскольку в SQL неявное преобразование типов, и '1' + '1' дает числовое 2.

Мои похвалы Си -- не за выбор значков, а за разделение битовых и логических операций.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 дек 2014, 13:58 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Freeman писал(а):
Вот пример, все операнды целые:

Правильный ответ a = ( b and с ), так как ( a = b ) and с быть не может в принципе (идёт смешивание логического (a=b) и целого (c) типов).

Freeman писал(а):
Другой пример: в SQL пришлось ввести оператор || для конкатенации строк, поскольку в SQL неявное преобразование типов, и '1' + '1' дает числовое 2.

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

Freeman писал(а):
Мои похвалы Си -- не за выбор значков, а за разделение битовых и логических операций.

Ну, никто не мешает создать bitand, bitor, bitnot, bitxor, однако я смысла не вижу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 дек 2014, 15:17 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 959
Откуда: Дагоба
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) типов).

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 дек 2014, 15:18 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 959
Откуда: Дагоба
pavia писал(а):
А goto я бы запретил пусть автоматы осваивают

Вот и попробуйте для начала сделать хоть один мало-мальски сложный автомат без goto.

pavia писал(а):
Изначально в Си не было условного оператора и оператора цикла - это были функции!

С чего вы взяли? Первый раз слышу.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 дек 2014, 15:19 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 959
Откуда: Дагоба
SII писал(а):
Тоже не соглашусь. Операция однозначно устанавливается по типу участвующих данных, а соответственно, вводить разные знаки -- загромождать язык ненужными вещами.

Никоим образом. Парсер языка должен иметь возможность расставить порядок операций ДО выяснения типа операндов. В противном случае сложность компилятора сильно возрастает. В приведённом выше примере a и b могут быть булевыми переменными, но именно правильно расставленные приоритеты операций помогают быстро и без неоднозначности понять код.

SII писал(а):
Что же до скобок, то не так уж они мешают читабельности в случае сложных логических выражений; более того, нередко они позволяют сгруппировать выражения и отделить их одно от другого, повышая тем самым читабельность, а не понижая её.

Сравните читаемость (в предположении правильного приоритета операций, а не кривого сишного):
Код:
if (((x-с)>2) && ((y&2)==0)) {
  ...
}

и
Код:
if x-с>2 && y&2==0 {
  ...
}

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 дек 2014, 15:21 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 959
Откуда: Дагоба
Freeman писал(а):
Писать end if да end loop могли придумать только французы, чтобы отомстить американцам, маскируя это под строгость для Пентагона. На деле подобная многословность является избыточной, а двойные ключевые слова даже мешают восприятию, -- за них глаз цепляется при чтении кода.

Рассуждения о надежности -- синдром программиста C/C++. Откажитесь от скобок вне выражений -- вот вам и надежность. Можете верить, можете нет, но ошибки из-за неверно поставленного end у меня возникали лишь несколько раз за всю карьеру, причем исключительно по причине программирования в сильно уставшем или невыспавшемся состоянии.

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

Freeman писал(а):
Разделение битовых и логических операций -- одна из немногих вещей, сделанная в Си правильней Паскаля. Для разрешения неоднозначности в Паскале приходятся скобки ставить. Сравните с SQL, например, где битовых операций нет, поэтому and и or вполне работают и без скобок. Скобки -- снижение читабельности.

Совершенно верно.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 дек 2014, 17:26 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Yoda писал(а):
В таком случае str[j] - никакая не строковая операция, а обычное получение элемента массива, то есть целого числа.

Теоретически да, только str, это не массив, а строка. Я настаиваю, что массив целых чисел и строка – разные типы данных. Хотя бы потому, что строки можно «складывать», брать их длину и т. д.
Yoda писал(а):
1. В исходном тексте символьные константы имеют тип "целое число без знака", а строковые константы имеют тип "массив целых чисел без знака".

Так как же тогда сложить строки, например, Write ( «Number x = » + itoa(x) + endLine )? Если трактовать строку как массив целых чисел без знака, то операция сложения таких массивов должна быть определена как конкатенация массивов. Причём не важно, строки это или нет. То есть можно будет делать так:
Код:
u64 x [ ] = { 1, 2, 3 };
u64 y [ ] = { 4, 5, 6 };
u64 z [ ] = x + y;   // z = { 1, 2, 3, 4, 5, 6 };

Верно?
А ещё у строки хотелось бы брать длину. Причём за постоянное время. Значит операцию взятия длины мы должны прописать для любых массивов (целых чисел без знака), а значит длину придётся хранить где-то рядом с каждым массивом, что неудачно.
Yoda писал(а):
Не надо плодить сущности без необходимости! Блоки кода прекрасно отслеживаются при помощи структурного программирования. Соблюдайте отступы. Да и против end for/end if и других составных эндов я категорически возражаю. Сам по себе end синтаксически абсолютно достаточен.

Возможно, сущности плодить и не надо. Лично мне вообще не нужны ограничения в виде начала или конца блоков, будучи приученным когда-то писать в обычном windows-блокноке и при этом компилировать код без единой ошибки, я тогда думал, нафига вообще эти скобки, всё видно по отступам. Но вот когда я узнал, как пишут программы люди менее опытные, скорее даже малоопытные, то понял, что им чем больше слов, тем лучше. В мышлении математика чем больше нужно написать слов, тем сложнее написать что-то неправильно. Каждое слово как будто утверждение, подкрепляющее уверенность в правильности поступка.
Yoda писал(а):
Вот и делайте с помощью комментариев.

Можно, но лучше, когда компилятор лишний раз всё проверит. Не для меня и не для Вас, а для математиков, которые пытаются быть программистами.
Yoda писал(а):
Я не пойму, какую именно ошибку вы пытаетесь поймать таким способом? На мой взгляд, это всё - избыточные, ничем не оправданные палки в колёса программиста.

Как я уже сказал, эта избыточность должна быть вариативной (хочешь пиши, не хочешь – не пиши). Ошибка такая: когда случайно вместо if закрыл for или наоборот, когда не хватает закрывающей скобки, проще понять, о которой именно из ста пятидесяти открывающих мы не позаботились.

--- Лирическое отступление ---
Я догадываюсь, что опытные люди подобных ошибок не делают, а вообще я не мыслю открыть скобку так, чтобы не закрыть её тут же на месте. Но тут нужно подумать, для кого мы делаем язык. В моей изначальной концепции это язык для математиков. Когда я учился в 7 классе и изучил Си, то, посмотрев на Паскаль с его if then begin end, мне реально стало плохо и я думал: «как здорово в Си, можно смешивать типы как угодно и где угодно, не нужны скобки в сложных условиях, не нужны всякие then-begin, можно в одном for написать сразу весь алгоритм на 100 строк через запятую в одной строке, можно одновременно с проверкой условия делать присваивание и создавать настолько красивые однострочные выражения, которых никогда не сделать в Паскале», - так я думал, когда мозг работал живо и мгновенно читал любые исходники, по которым я и учился (книг тогда не было, либо не было денег). Проблемы с тем, что что-то нечитаемо или у кого-то кривой стиль меня не волновали вовсе. А сейчас всё иначе. Я лучше на 3-5 секунд дольше буду набирать строку кода, чем всматриваться в действия и мысленно определять их порядок.
--- Конец лирического отступления ---

Yoda писал(а):

Боже мой, до какой степени нечитаемым, оказывается, можно сделать простой кусок кода:
Код:
for ... {
  for ... {
    for ... {
      break [3] condition;
    }
  }
}

Я «за» такой подход, если ещё и убрать скобки и слово for, заменив его на что-нибудь другое, на символ «:::», например, а break на «><». Однако при этом я «за» и другой подход, когда как можно больше слов и скобок нужно написать. Проблема читаемости, связанная с объёмом скобок, меня лично не касается. Тут нужно смотреть, как математики думают по этому поводу.
Yoda писал(а):
как неожиданное следствие, уменьшает алгоритмическую надёжность. Т.е., увеличивая синтаксическую надёжность, мы затрудняем восприятие и понимание алгоритма, лежащего за синтаксисом, и, как следствие, допускаем больше алгоритмических ошибок.

Возможно.

Yoda писал(а):
Я бы повесился так писать. В соответствии со своей концепцией лаконичности я, наоборот, сделал для себя в С/С++ стандартные определения типов i8, i16, 132, i64, u8, u16, u32 и u64. Не буду утверждать, что это лучше чем int* и uint*, но мне удобно.

Не, это как-то слишком просто. i8 Вполне может оказаться переменной. И зачем Вы написали 132 вместо i32, я тоже не понял : ) В крайнем случае, можно I8 (i с большой буквы), но можно перепутать с l8 («эль» вместо «ай»). Одна из хороших традиций нормального программирования (которой я редко раньше придерживался) - не сокращать слова кроме очень ограниченного набора случаев (http, например). Раньше, когда время жизни моих программ не составляло больше 1-2 месяцев, можно было создавать переменные из 1-2 букв максимум. Потом я понял, что это нехорошо. Типы данных тоже лучше называть полностью, но с целью избежать конфликтов, с большой буквы.
Yoda писал(а):
А я - за. Они упрощают запись и визуальное восприятие.

А Вы знаете, почему xor это ^? Почему нет логического xor ^^? Почему логические операции – удвоенные знаки (&&, ||), а битовые – одинарные (&, |)? Я считаю, что всему должно быть объяснение, прежде чем соглашаться с чем-либо. Если у чего-то нет объяснения, то оно мне автоматически не нравится : )

Yoda писал(а):
Например, следующее выражение неоднозначно парсится (и самое главное - неоднозначно визуально воспринимается!):
if (a & b == с) ...
Я специально не конкретизирую, какие типы имеют переменные a, b и c. Если же мы делаем побитовые операции с высоким приоритетом а логические с низким, то неоднозначности не возникнет.

Ну вот, Вы же сами говорите, что приоритет решает проблему. По моей логике, логические операции имеют приоритет ниже, чем арифметические, а они, в свою очередь ниже, чем битовые. В указанной программе, если «c» имеет логический тип, то & здесь должен быть логическим. Да, придётся усложнить компилятор, но не так «невероятно». Строить дерево нужно после определения сущности операций, которую, в свою очередь, можно определить заранее. При этом проверка типов будет после построения дерева, так что всё в порядке. Кроме того, если возвращаться к вопросам читаемости, то логическая переменная не должна называться «c», она должна называться, например, «isDone» или чем-то подобным.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 дек 2014, 17:32 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Yoda писал(а):
Более того, все редкие ошибки несинхронизации скобок за мою карьеру мгновенно устранялись и ни одна не привела к неработающему или работающему с ошибкой алгоритму. Все они были не страшней пропущенной точки с запятой. Эти синтаксические перестраховки - костыли для лежащего на асфальте человека, чтобы тот не упал ещё дальше.

Мы с Вами, видимо, той закалки, когда почти никакие спасательные жилеты не нужны. Я по опыту общения с разными учёными-программистами могу сказать, что таких бесстрашных людей очень мало. Для остальных нужно либо делать удобный язык, либо жёстко учить всех программировать: стоять над душой и бить линейкой по пальцам за любую оплошность вроде copy-paste, а также запрещать завтрак обед или ужин за каждую ошибку компиляции.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 дек 2014, 19:44 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
[ 17 ] :: Оператор условия

Оператор условия, который традиционно называется if, предлагается сделать самым обычным образом с небольшими дополнениями. При этом вне зависимости от того, будет ли после if ключевое слово, открывающее блок кода, слово then или открывающая фигурная скобка, круглые скобки не являются необходимым элементом (но не являются и запрещённым). Например
Код:
if условие {
  ...
}
// или
if условие
  ...
end
// или то же самое
if ( условие )
  ...
end


Дополнительным спасательным жилетом для подобных условий может быть синтаксис с именованием
Код:
if [line cross] условие
  ...
end if [line cross]

Я пока не отказался, не смотря на возражения, от синтаксиса именования условий и циклов.

Альтернативная ветка называется else:
Код:
if условие {
  ...
}
else {
  ...
}
// или
if условие
  ...
else
  ...
end


Теперь самое холиварное: «лесенка» if - else if – else. В некоторых случаях почему-то создаются новые ключевые слова типа elseif или elif, хотя на самом деле в них совершенно нет необходимости, ведь условие
Код:
if условие { }
else if условие { }
else { }

по сути ничем не отличается от
Код:
if условие { }
else {
  if условие { }
  else { }
}

и именно так и должно восприниматься компилятором. Создавать лишнее ключевое слово типа elif нет никакого смысла. Более того, это неудобно, когда хочется по какой-то причине закомментировать кусок:
Код:
if условие { }
else /*if условие { }
else */ { }

В общем, в плане восприятия и удобства использования нужны только два слова: if и else.

--- Лирическое отступление ---
Кроме того, elif чем-то напоминает изуродованных некоторыми элементами советской идеологии имена (да простят меня их носители) типа Владлен (Владимир Ленин), Гертруд (герой труда) и прочие. Даже если сами имена могут быть интересными (например, подобным образом строились славянские имена типа Владислав или Милослава), сама основа их построения (именно советских имён) выглядит безобразно-поверхностной и неестественно-материалистичной. Хотя женское Гертруда или Владилена ничего так звучат, если придать им иную основу.
--- Конец лирического отступления ---

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

Теперь о классической неоднозначности:
Код:
if ...
  if ...
  else ...

Как решить, к чему относится else, если условия простые и не требуют скобок для выделения блоков кода? В случае, когда вложенность определяется числом пробелов в начале строки, всё ясно, а если нет, то неясно. Либо if { if - else }, либо if { if } else. Здесь следует либо раз и навсегда договориться, что else относится к ближайшему (или наиболее удалённому) if, либо заставить явно указывать:
Код:
if ...
  if ...
  else [1] ... // К ближайшему

Почему мне хочется считать, что по умолчанию else должен срабатывать на ближайший if? Потому что это соответствует концепции «совершенного кода». Чем ближе находятся строки, связанные по смыслу (например, объявление, инициализация и использование переменной), тем проще код, чем дальше нужно заглянуть, чтобы вспомнить, о чём шла речь, чем хуже код. Это, конечно, общая рекомендация и допускает ряд исключений, но она вполне разумна.

Однако я всё-таки «за» то, чтобы можно было указать явно, к которому if мы хотим приписать else, если отказываемся от выделения блоков кода через выравнивание.

Ещё вариант: запретить нафиг блоки кода с одним оператором без указания скобок. То есть даже если один оператор, ставим скобки всё равно. Ни у кого не вскипает злость по этому поводу? : )

Кстати, в C++ же нельзя определить функцию, не поставив { }, даже если там всего один оператор.

[ Продолжение следует ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 дек 2014, 20:53 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 959
Откуда: Дагоба
Zealint писал(а):
Теоретически да, только str, это не массив, а строка. Я настаиваю, что массив целых чисел и строка – разные типы данных. Хотя бы потому, что строки можно «складывать», брать их длину и т. д.

Ну в таком случае строка - это просто производный класс.

Zealint писал(а):
Так как же тогда сложить строки, например, Write ( «Number x = » + itoa(x) + endLine )? Если трактовать строку как массив целых чисел без знака, то операция сложения таких массивов должна быть определена как конкатенация массивов. Причём не важно, строки это или нет. То есть можно будет делать так:
Код:
u64 x [ ] = { 1, 2, 3 };
u64 y [ ] = { 4, 5, 6 };
u64 z [ ] = x + y;   // z = { 1, 2, 3, 4, 5, 6 };

Верно?

Конкатенация легко определяется для класса String. Этот класс не эквивалентен массиву целых чисел. На уровне компилятора конкатенация определена для строковых констант, в моём варианте без всяких плюсов, – две идущие подряд строки сливаются в одну.

Zealint писал(а):
А ещё у строки хотелось бы брать длину. Причём за постоянное время. Значит операцию взятия длины мы должны прописать для любых массивов (целых чисел без знака), а значит длину придётся хранить где-то рядом с каждым массивом, что неудачно.

Да нет же, не надо всё валить в одну кучу. Давайте чётко разделим - есть классы (т.е. производные типы), определённые для них операции и библиотеки. А есть встроенные языковые средства и базовые типы. Строки - это класс. Определяете для него любые операции и пользуетесь. Храните внутри объектов длины - не проблема, всё будет работать за постоянное время.

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

Знаете, я делаю ЯВУ не для них, а для себя. Любым инструментом можно воспользоваться так, что потребуется тазик. Но мне важней моё удобство.

Zealint писал(а):
Можно, но лучше, когда компилятор лишний раз всё проверит. Не для меня и не для Вас, а для математиков, которые пытаются быть программистами.

Эти математики пусть пользуются Адой.

Zealint писал(а):
Ошибка такая: когда случайно вместо if закрыл for или наоборот, когда не хватает закрывающей скобки, проще понять, о которой именно из ста пятидесяти открывающих мы не позаботились.

И что принципиально изменится, если вы закроете for вместо if? Будет ли являться трудноуловимой алгоритмической ошибкой, если вы закроете 149 открывающих вместо 150?

Zealint писал(а):
«как здорово в Си, можно смешивать типы как угодно и где угодно, не нужны скобки в сложных условиях, не нужны всякие then-begin, можно в одном for написать сразу весь алгоритм на 100 строк через запятую в одной строке, можно одновременно с проверкой условия делать присваивание и создавать настолько красивые однострочные выражения, которых никогда не сделать в Паскале»

Так ведь всего лишь достаточно не вдаваться в крайности. Достаточно запретить if без скобок, оператор "запятая", смешивание типов, проверку с присваиванием и всё встанет на свои места!

Zealint писал(а):
Я «за» такой подход, если ещё и убрать скобки и слово for, заменив его на что-нибудь другое, на символ «:::», например, а break на «><».

Опять вы впадаете в крайность.

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

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

Zealint писал(а):
Не, это как-то слишком просто. i8 Вполне может оказаться переменной. И зачем Вы написали 132 вместо i32, я тоже не понял : )

132 - это просто опечатка (легко отлавливаемая компилятором и подсветкой синтаксиса).
С переменными i8 за всю жизнь мне ни разу не удалось столкнуться.
Я говорю - не настаиваю на такой степени лаконичности, но идентификатор встроенного типа длинней чем uint128 я писать (и главное - читать!) не готов :).

Zealint писал(а):
А Вы знаете, почему xor это ^? Почему нет логического xor ^^?

Почему xor ^ не знаю, но смотрится хорошо. Логического ^^ нет за ненадобностью.

Zealint писал(а):
Почему логические операции – удвоенные знаки (&&, ||), а битовые – одинарные (&, |)? Я считаю, что всему должно быть объяснение, прежде чем соглашаться с чем-либо. Если у чего-то нет объяснения, то оно мне автоматически не нравится : )

Так ведь есть объяснение. Для разделения приоритетов операции ДО проверки типов.

Zealint писал(а):
Ну вот, Вы же сами говорите, что приоритет решает проблему. По моей логике, логические операции имеют приоритет ниже, чем арифметические, а они, в свою очередь ниже, чем битовые. В указанной программе, если «c» имеет логический тип, то & здесь должен быть логическим.

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

Zealint писал(а):
Да, придётся усложнить компилятор, но не так «невероятно». Строить дерево нужно после определения сущности операций, которую, в свою очередь, можно определить заранее.

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

Zealint писал(а):
При этом проверка типов будет после построения дерева, так что всё в порядке.

Ничего не в порядке. С учётом производных классов и перегрузки операторов задача построения дерева переходит в класс NP.

Zealint писал(а):
Кроме того, если возвращаться к вопросам читаемости, то логическая переменная не должна называться «c», она должна называться, например, «isDone» или чем-то подобным.

Этот фактор вообще к делу не относится. Я часто называю переменную одной буквой, например, счётчик "i", символ "c"... да и сами взгляните на свой код (short-cycles), - много вы там увидите многобуквенных переменных? :)

Zealint писал(а):
Для остальных нужно либо делать удобный язык, либо жёстко учить всех программировать: стоять над душой и бить линейкой по пальцам за любую оплошность вроде copy-paste, а также запрещать завтрак обед или ужин за каждую ошибку компиляции.

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 285 ]  На страницу Пред.  1 ... 13, 14, 15, 16, 17, 18, 19 ... 29  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB