OSDev

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

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




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

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
Zealint писал(а):
Не, это я так просто : ) Штрудель? Я только штрудель с яблоками знаю : ) Видимо, оттуда и название пошло (штрудель же завёрнут).

Так его немцы и евреи называют. На Западе же не только по-английски говорят.


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

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 959
Откуда: Дагоба
Zealint писал(а):
Yoda писал(а):
Потеря переносимости и универсальности в том, что вы не можете взять произвольный plain-text редактор и писать/править исходники.

Почему же не могу? Могу. Просто символ tab будет ошибкой компиляции. На клавиатуре есть символ @, однако факт возможности нажать на него в любом plain-text редакторе вне комментариев не порождает проблему переносимости и универсальности. Нажав на него, программист получит неправильную программу. Так же и с tab.

У табуляции есть особенность. Многие редакторы настроены (или могут быть настроены) на использование табуляции вместо начальных пробелов (или даже в середине текста, если они замещают группу пробелов, заканчивающихся в позиции табуляции). В общем, такова семантика символа, заложенная в стандарте ASCII и его наследниках. Я с бОльшим спокойствием запрещу использование символов вертикальной табуляции (VT) и прокрутки страницы (FF).

Zealint писал(а):
1 Исходные числа, передаваемые в программу, сначала нужно привести к диапазону 0..P-1, а для этого нужно брать их по модулю, и среди них будут отрицательные.

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

Zealint писал(а):
2 Вычитание двух чисел по модулю происходит в два этапа: вычитание и взятие по модулю. Между этими двумя операциями числа могут покидать данный диапазон влево от нуля. Именно поэтому приходится делать, например, так:
Цитата:
с = a - b;
if ( c < 0 )
c += P;

Всё абсолютно верно. Но здесь нет операции остатка от деления!

Zealint писал(а):
Yoda писал(а):
Вообще говоря, невозможно сделать абсолютно защищённый язык. В данном случае я вижу как минимум две проблемы.
1. Как вы планируете наложить соответствующие ограничения? Я не вижу адекватного механизма.

Почти так же как это делается в ООП. Есть класс, от которого можно унаследовать интерфейс (чисто виртуальные функции). Программист может переопределить эти функции как ему вздумается. Другие мы ему запрещаем делать в таких классах. Таким образом, чисто формально программы будут продолжать компилироваться правильно, если мы заменим, например, тип int256 на встроенный.

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

Zealint писал(а):
Поэтому программисту невыгодным станет определять свой тип int256 неправильно. То есть, определить умножение как сложение и наоборот.

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

Zealint писал(а):
Yoda писал(а):
2. Интерфейс в данном случае почти не важен, важна как раз реализация, а её никак ни ограничить, ни проверить.

Реализация может быть любой. Если программист накосячил в реализации или решил использовать операции не по назначению, то он САМ создал себе проблемы.

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

Zealint писал(а):
Имеется в виду, что нет типа данных вроде char. Но символьные константы можно использовать при работе со строками. Например, str[j]='A' - так можно. В зависимости от типа str, компилятор преобразует 'A' в число подходящего типа, поэтому в объектном файле вместо 'A' будет, например, 65. Однако написать int8 x ='A' нельзя, так как компилятор здесь совершенно не знает, что за 'A' имеется в виду, то ли это cp1251, то ли UTF-32.

Так вот же оно, противоречие! str[j]='A' (в зависимости от типа str, компилятор преобразует 'A' в число подходящего типа). То есть, str - массив целых чисел и вы одному из них присваиваете символ. В какой кодировке символ? Далее, int8 x='A' – нельзя, т.к. компилятор не знает кодировку. А как же он определяет её в первом случае?
В моей схеме решается так. Кодировка фиксированная – UTF-8. Вторая операция int8 x='A' разрешена, если число, полученное после конвертирования символа, не выходит за диапазон 0...255.

Zealint писал(а):
Как же не часть синтаксиса? str[j]='A', это как раз синтаксис. Квадратные скобки здесь являются синтаксической конструкцией. Как обращаться за постоянное время я предложил: хранить смещение каждого символа строки по отношению к её началу.

str – это что? Массив целых чисел? Если да, то как вы планируете в массиве целых чисел дополнительно хранить смещения? Для такого хранения нужен отдельный, уникальный тип, например, символьный (что противоречит предыдущему утверждению об отсутствии символьного типа). Однако, если вы храните смещения, то для 64-битной системы это будет дополнительно 8 байт на каждый символ, итого получается или структура из 9 байт, или два массива чуть-чуть меньшего размера. Не кажется ли, что представление в UTF-32 гораздо более эффективно, чем такие смещения с извращениями?

Zealint писал(а):
Yoda писал(а):
1. Она не использует глобальных переменных.

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

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

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

Вы смешиваете свойство функции с её использованием. Безопасность - её внутреннее свойство. Конечно в опасном контексте она может стать опасной, но на самом деле это совсем не важно. Для компилятора важно свойство, а не использование.

Zealint писал(а):
Ещё она может передать сообщение другому процессу ... Если только передача сообщения другому процессу считается безопасной функцией.

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

Zealint писал(а):
Я не помню, мы всё-таки разрешили inline-assembler? Если да, то функция явно небезопасна.

Нет, у меня inline-assembler запрещён.

Zealint писал(а):
Но даже если нет, всё равно следует небезопасными считать функции, написанные целиком на asm отдельным модулем.

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

Zealint писал(а):
Ещё момент: если безопасная функция получила в качестве параметра ссылку не небезопасную функцию?

Если получила ссылку, значит вызвана в опасном контексте. Здесь нет никакого противоречия. В данном случае важно, что компилятор имеет возможность чётко разграничить, где заканчивается безопасность. Смотрите, у нас есть две функции – А и Б. Функция А безопасная. Вы спрашиваете: "А что, если функция Б вызывает А опасным образом?" Отвечаю: из этого следует только то, что функция Б и любые другие, которые вызывают Б, – опасные, но сама функция А от этого не стала опасной. То есть, мы чётко разграничили опасную и безопасную зоны.

Zealint писал(а):
Или безопасные функции должны отличаться каким-то идентификатором при своём определении?

Да, должны. В противном случае компилятору для определения опасности потребуется проверять исходники всех вызываемых функций, что, в общем случае, нереально. Правда я пока не определился, следует ли маркировать безопасные функции или наоборот опасные. Если маркировать безопасные, то мы рискуем постоянно наступать на грабли "забывчивости" программиста, аналогичные спецификации "const" в С/С++. Программисты часто пишут функции типа strlen (char *str); которые не меняет своего аргумента, и вызывает strlen("Hello, World!");, что является ошибкой. Мне кажется, было бы разумней наоборот, явно специфицировать те указатели, по которым можно менять содержимое, а все остальные считать константными.

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

Как верно отметил pavia, для реализации этого требуется минимум два прохода. Малое время компиляции - не совсем удачный аргумент, представьте себе, лексический анализ требуется не только компилятору, но и простому текстовому редактору для подсветки синтаксиса. А теперь представьте, что по каждому чиху в начале файла текстовый редактор должен просматривать весь файл до последнего символа, даже несмотря на то, что закрывающую пару символов он уже нашёл. Далее запоминать последнюю встреченную пару и начинать подсвечивать символы после неё.
Как быть, если я хочу закомментировать следующий кусок кода целиком?:
Код:
aaa
/* bbb */ */
ccc
/* ddd */ */
eee

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

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

<<< OS Boot Tools. >>>


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

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 959
Откуда: Дагоба
pavia писал(а):
Советую обратить внимание на LLVM и не достаки IR. У вас именно такие же.

На LLVM я уже давно обратил внимание. И что с того?

pavia писал(а):
Если запись произвольная то компилятору придётся перебирать все варианты.

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

pavia писал(а):
И ещё там были какие-то замечания сейчас не помню.

Скажете, когда вспомните :).

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

<<< OS Boot Tools. >>>


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

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

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

Давайте.
1 вычитание
2 входные данные. Когда программа получает на вход числа, они могут быть отрицательными. Например, задача: решить систему линейных уравнений по модулю P. Дана система, исходные коэффициенты которой находятся в диапазоне от минус 10^100000, до плюс сколько же (это ещё даже не слишком большие числа). Вот, мы берём сначала всё по модулю, причём отрицательные числа могут попадаться столь же часто, сколь и положительные.
3 «Особая» модулярная арифметика. В ряде случаев для упрощения расчётов программисты не спешат приводить числа к диапазону 0..P-1, а оставляют их в диапазоне от –P+1 до P-1. А потом в конце делают if (c<0) c += P для всех чисел в ответе, но только один раз, а не много.

Yoda писал(а):
Zealint писал(а):
2 Вычитание двух чисел по модулю происходит в два этапа: вычитание и взятие по модулю. Между этими двумя операциями числа могут покидать данный диапазон влево от нуля. Именно поэтому приходится делать, например, так:
Цитата:
с = a - b;
if ( c < 0 )
c += P;

Всё абсолютно верно. Но здесь нет операции остатка от деления!

Конечно нет, ведь я заменил взятие по модулю условием. Но это не очень-то правильно для архитектуры, в которой ветвление порождает проблемы. А ещё иногда для сокращения числа делений делают сразу пару операций, и только потом берут по модулю:
Код:
с = a - b;
e = ( c * d ) % P // с*d может быть < 0
if ( e < 0 ) // приводим к 0..P-1
  e += P;


Yoda писал(а):
Так вот же оно, противоречие! str[j]='A' (в зависимости от типа str, компилятор преобразует 'A' в число подходящего типа). То есть, str - массив целых чисел и вы одному из них присваиваете символ. В какой кодировке символ? Далее, int8 x='A' – нельзя, т.к. компилятор не знает кодировку. А как же он определяет её в первом случае?

Нет, str – не массив. Я вообще предлагаю забыть про то, что строка эквивалентна массиву целых чисел. Строка – это тип данных. А будет ли этот тип реализован через массив чисел или через двусвязный список, да хоть даже через сбалансированное дерево, совершенно не важно для сути дела. Оператор [], определённый для этого класса каким-то образом, возвращает ссылку ячейку, в которой находится символ. Этот символ воспринимается как целое число. Вы же сами предложили создать строки разного типа. Пусть мы пишем
Код:
utf8 str = «blah blah»; // Нет противоречия, строка будет в utf8
str [ 4 ] = ‘-‘; // Нет противоречия, дефис превращается в символ кодировки utf8, потому что компилятор знает тип str.
int32 x = str [ 4 ]; // допустимо, но лучше подобное запретить.

Вместо utf8 может быть utf32, cp1251 и любая другая вещь, которая может пригодиться.
Yoda писал(а):
str – это что? Массив целых чисел?

Нет, это тип данных с оператором [].
Yoda писал(а):
Однако, если вы храните смещения, то для 64-битной системы это будет дополнительно 8 байт на каждый символ, итого получается или структура из 9 байт, или два массива чуть-чуть меньшего размера. Не кажется ли, что представление в UTF-32 гораздо более эффективно, чем такие смещения с извращениями?

Да, это очень грустно. Что-то мне подсказывает, что здесь можно применить какие-то алгоритмы работы со строками, нужно подумать. Как вариант, я не отказался от типа данных «строка без произвольного доступа», она может быть вполне востребованной.
Yoda писал(а):
Zealint писал(а):
А Вам не кажется, что глобальные переменные нужно вообще запретить как недоразумение?

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

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

Я понял, значит безопасные функции – это лишь свойство. А я подумал, что Вы хотите сделать по аналоги с константными функциями constexpr, которые не могут ни в каком контексте стать неконстатными.
Yoda писал(а):
Да, должны. В противном случае компилятору для определения опасности потребуется проверять исходники всех вызываемых функций, что, в общем случае, нереально. Правда я пока не определился, следует ли маркировать безопасные функции или наоборот опасные. Если маркировать безопасные, то мы рискуем постоянно наступать на грабли "забывчивости" программиста, аналогичные спецификации "const" в С/С++. Программисты часто пишут функции типа strlen (char *str); которые не меняет своего аргумента, и вызывает strlen("Hello, World!");, что является ошибкой. Мне кажется, было бы разумней наоборот, явно специфицировать те указатели, по которым можно менять содержимое, а все остальные считать константными.

Да, это логично.
Yoda писал(а):
Как быть, если я хочу закомментировать следующий кусок кода целиком?:
Код:
aaa
/* bbb */ */
ccc
/* ddd */ */
eee


Не получится. Тут Вы сами виноваты в том, что сделали код некомментируемым целиком. А, возможно, вы так специально захотели, чтобы этот участок нельзя было закомментировать целиком.
Yoda писал(а):
И вообще как его парсить? Нужно ли оставлять ccc или начиная с первого комментария сразу пропускать всё вплоть до последнего закрытия? Как бы вся эта каша не превратилась в comment-hell.

Очень просто. Идём по лексемам. Видим /*, запихали в стек. Видим bbb, считаем комментарием, видим */ , вытолкали из стека /*. Видим */, но стек пуст, поэтому ничего не делаем. Видим ccc, но стек пуст, поэтому считаем эту часть неопределённой. Видим /*, но стек пуст - начинается новый комментарий, а ccc становится кодом. и т. д. Вообще, подобные штуки с избытком правых скобок можно анализировать в один проход, если использовать дополнительную память. Дело в том, что код между */ и */ (двумя правыми скобками) нужно временно считать «неопределённым», пока не возникнет либо конец файла, либо левая скобка комментария. Сложнее, конечно, и путаницу порождает.
Yoda писал(а):
Нет, извините, такие комментарии полностью противоречат здравому смыслу, особенно в контексте вложенности.

Здравому смыслу не противоречат (тут смотря с какой стороны смотреть), а вот концепции вложенности, пожалуй, да, противоречат.


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

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

Давайте.
...
2 входные данные. Когда программа получает на вход числа, они могут быть отрицательными. Например, задача: решить систему линейных уравнений по модулю P. Дана система, исходные коэффициенты которой находятся в диапазоне от минус 10^100000, до плюс сколько же (это ещё даже не слишком большие числа). Вот, мы берём сначала всё по модулю, причём отрицательные числа могут попадаться столь же часто, сколь и положительные.

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

Zealint писал(а):
3 «Особая» модулярная арифметика. В ряде случаев для упрощения расчётов программисты не спешат приводить числа к диапазону 0..P-1, а оставляют их в диапазоне от –P+1 до P-1. А потом в конце делают if (c<0) c += P для всех чисел в ответе, но только один раз, а не много.

Ну вот вы же сами пишете, что в конце делают if.

Zealint писал(а):
Yoda писал(а):
Всё абсолютно верно. Но здесь нет операции остатка от деления!

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

Да нет проблем с ветвлением. По крайней мере, если сравнивать с делением.

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

Zealint писал(а):
Нет, str – не массив. Я вообще предлагаю забыть про то, что строка эквивалентна массиву целых чисел. Строка – это тип данных.

Тип КАКИХ данных? Если не целых чисел, значит какой-то специализированный тип. Если специализированный, назовём его char.

Zealint писал(а):
Вы же сами предложили создать строки разного типа. Пусть мы пишем
Код:
utf8 str = «blah blah»; // Нет противоречия, строка будет в utf8
str [ 4 ] = ‘-‘; // Нет противоречия, дефис превращается в символ кодировки utf8, потому что компилятор знает тип str.
int32 x = str [ 4 ]; // допустимо, но лучше подобное запретить.

Вместо utf8 может быть utf32, cp1251 и любая другая вещь, которая может пригодиться.

Я предложил строки разного типа только в качестве приведения константного значения к нужному размеру целочисленного rvalue. Здесь нет противоречия. UTF8, UTF16 и UTF32 при этом совершенно прозрачно поддерживаются. CP1251 - в топку. На уровне языка никаких кодировок кроме юникода нет. При необходимости левых кодировок они поддерживаются библиотеками (которые всё равно скоро отомрут).

Zealint писал(а):
Yoda писал(а):
Однако, если вы храните смещения, то для 64-битной системы это будет дополнительно 8 байт на каждый символ, итого получается или структура из 9 байт, или два массива чуть-чуть меньшего размера. Не кажется ли, что представление в UTF-32 гораздо более эффективно, чем такие смещения с извращениями?

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

Что-то мне подсказывает, что все эти извращения не нужны, если действительно отказаться от символьного типа и от других "непонятных" типов str[j], и оставить только целочисленные массивы.

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

Невозможно. Память с общим доступом (т.е. глобальная) нужна не только для поддержки блокировок (атомарных операций), но и для передачи ЛЮБЫХ данных между процессами.

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

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

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

<<< OS Boot Tools. >>>


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

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Yoda писал(а):
Ну вот вы же сами пишете, что в конце делают if.

Только потому, что других вариантов нет. Но зато if делают лишь один раз, это не критично. Проблемы могут начаться тогда, когда промежуточные данные нужны именно в формате 0..P-1. Тогда if придётся выполнять каждый раз, когда может получиться отрицательное число.

Yoda писал(а):
Да нет проблем с ветвлением. По крайней мере, если сравнивать с делением.

На видеокартах есть.

Yoda писал(а):
Тип КАКИХ данных? Если не целых чисел, значит какой-то специализированный тип. Если специализированный, назовём его char.

Тип целых неотрицательных чисел. Размер зависит от вида строки, если это utf (любой), то, видимо, 4 байта.

Yoda писал(а):
Я предложил строки разного типа только в качестве приведения константного значения к нужному размеру целочисленного rvalue. Здесь нет противоречия. UTF8, UTF16 и UTF32 при этом совершенно прозрачно поддерживаются. CP1251 - в топку. На уровне языка никаких кодировок кроме юникода нет. При необходимости левых кодировок они поддерживаются библиотеками (которые всё равно скоро отомрут).

Чем Вы предлагаете заменить операцию str[i]='A' или find(str, 'A')?

Yoda писал(а):
Невозможно. Память с общим доступом (т.е. глобальная) нужна не только для поддержки блокировок (атомарных операций), но и для передачи ЛЮБЫХ данных между процессами.

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


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

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
[ 16 ] :: Ключевые слова (общие рассуждения)

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

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

Первый вариант. Ключевых слов нет, есть символы, которые из заменяют. Как именно? В кодировке utf8 есть много вариантов. Например, цикл (for) заменяется на кружок со стрелкой, if на знак вопроса. В целом, изучать эту таблицу можно долго и найти там массу вариантов для многих ключевых слов. Определения переменных заменить символами уже сложнее, это вряд ли будет удобно. Поэтому от идеи, видимо, придётся отказаться, но не только из-за типов данных, а потому ещё, что набирать такие символы в произвольном редакторе неудобно будет.

Второй вариант. Сделать ключевые слова более богатыми, чем в C++. Если есть for, то должен быть end for, если есть if, то должен быть end if. Это позволит более удобно отслеживать то, который из блоков кода закрывается, если, конечно, мы не напишем 10 if подряд. Однако и здесь есть выход. Снабдить ключевые слова, открывающие блок кода, номерами. Как я это вижу? Вариант №1
Код:
if [ 1 ]  ( ... )
  if [ 2 ] ( ... )
    if [ 3 ] ( ... )
      ...
    end if [ 3 ]
  end if [ 2 ]
end if [ 1 ]

Такой вариант позволит нумеровать условия произвольным образом. Вариант №2, он позволяет не нумеровать условия, нумерация по умолчанию идёт в обратном порядке.
Код:
if ( ... )
  if ( ... )
    if ( ... )
      ...
    end if [ 1 ]
  end if [ 2 ]
end if [ 3 ]

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

Более важный смысл подобная нумерация приобретает в связи с использованием циклов (с учётом идеи Сергея об использовании 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 ] ( <some-condition> );
    end for
  end for
end for

Итак, общий смысл: любое ключевое слово xxx, открывающее блок, может получить имя или номер, закрывающий end xxx тогда должен получить этот же номер или имя. Зачем? Для пояснений самому программисту и для большей надёжности при программировании, ведь порой одной проверки соответствия открывающих и закрывающих скобок может быть недостаточно. Разумеется, данная опция не является обязательной.

Другой вопрос, нужны ли ключевые слова типа then (после if) или do (после for / while). Я вот думаю, что нет. Сам по себе цикл do / while (repeat / until) тоже под вопросом. Но об условиях и циклах вообще нужен другой разговор. Здесь речь идёт о ключевых словах.

Просто end закрывает блок кода, открывающий тело функции.

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

Ключевые слова, обозначающие числовой тип данных, могут использоваться без указания числа бит только в одном случае, когда тип имеет «бесконечную» точность. Например, int32 (или Integer32) означает целое со знаком 32 бита. Если написать просто int (или Integer), то это будет целое «бесконечного» размера.

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

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

Должно быть ключевое слово, с помощью которого можно определить функцию. То есть аналог function в C++11, но там она не является частью языка.

Должны быть ключевые слова, позволяющие выравнивать данные в памяти, и слово определяющее тип объекта. Также должен быть аналог auto из C++11.

НЕ должно быть ключевого слова типа unsigned. Если нужен числовой тип данных без знака, то проще отразить это суффиксом: Integer32u или префиксом Uinteger32. Первый вариант мне нравится больше.

Слово goto должно быть : ) (hollywar expected)

Я против разного рода обозначений логических и битовых операций вроде ~, !, &, &&, |, ||, ^ и прочих диграфов. Либо мы используем юникодовские символы отрицания, конъюнкции и дизъюнкции, а также «плюс в круге», либо not, and и or, а также xor. Причём не нужно делать отдельные операции для битовых и логических выражений, так как смешивание этих типов у нас запрещено. Вопрос, конечно, в том, как быть с операциями типа &=, |= . Кстати, никого не смущает, что != вовсе не означает «присвоить с отрицанием», а «<=» вовсе не означает присвоить со сравнением ‘если меньше’» (что бы это не значило)? И как можно удобно набирать символы, которых нет на клавиатуре, тоже вопрос. Идея использования подобных диграфов, конечно, интересная, но они лично мне все-таки не нравятся. Ощущение, что это пережитки 80-х годов.

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


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

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1104
У японцев есть азбука из букв(слоговая азбука) и из иероглифов. Так вот буквами писать проще. Они ими и пишут, а для приличия конвертируется в иероглифы.
А goto я бы запретил пусть автоматы осваивают или структурированное программирование.
И код будет понятнее и проще.

Цитата:
Другой вопрос, нужны ли ключевые слова типа then (после if)
1 такое ключевое слово позволяет упростить парсер более чем на 100 строк кода. И обучать такому языку проще.

Цитата:
Другой вопрос, нужны ли ключевые слова типа then (после if) или do (после for / while). Я вот думаю, что нет. Сам по себе цикл do / while (repeat / until) тоже под вопросом. Но об условиях и циклах вообще нужен другой разговор. Здесь речь идёт о ключевых словах.

Изначально в Си не было условного оператора и оператора цикла - это были функции! Что неудобно и пережиток старого.

Цитата:
Должно быть ключевое слово, с помощью которого можно определить функцию. То есть аналог function в C++11, но там она не является частью языка.
Является.

Хочу константные указатели как в Си++11.


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

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
Zealint писал(а):
Итак, общий смысл: любое ключевое слово xxx, открывающее блок, может получить имя или номер, закрывающий end xxx тогда должен получить этот же номер или имя. Зачем? Для пояснений самому программисту и для большей надёжности при программировании, ведь порой одной проверки соответствия открывающих и закрывающих скобок может быть недостаточно.

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 дек 2014, 02:40 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1380
Freeman писал(а):
Писать end if да end loop могли придумать только французы, чтобы отомстить американцам, маскируя это под строгость для Пентагона. На деле подобная многословность является избыточной, а двойные ключевые слова даже мешают восприятию, -- за них глаз цепляется при чтении кода.


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

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

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


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


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

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


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

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


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

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