Яр - поругайте строки

Плюсы:

• Можно писать любые строки и дро^W как хочешь.

Минусы:

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

Напоминает формат числа в 1С8 — очень гибко, очень мощно, но все юзают магическое ЧДЦ=2;ЧРД=,;ЧН= (при этом дефолт там абсолютно невменяемый).

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

Чёт шибко замудрёно. А нельзя просто сделать возможность присоединять к строке атрибуты, как plist к символам в лиспе и универсальный синтаксис для этого? Интерполяция строки (чс_си), это вообще задача функции, а не синтаксиса.

Спасибо за отзыв. Отвечаю:

Надо учить язык строк чтобы писать строки.

Не смог проще придумать. Сейчас кое-что выкинул, но это не даст существенного облегчения. В Перле всё же тоже есть q. В баше вроде был «here document».

Написано слишком заумно, куча странных словосочетаний,

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

Интерполяция строки (чс_си), это вообще задача функции, а не синтаксиса.

От синтаксиса здесь конкатенация как в С.

"строка 1" "строка 2"

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

Всё можно сделать, но я стараюсь семантику лиспа не расширять без особой нужды. Для таких вещей в лиспе есть слабые хеш-таблицы. Наиболее «жирный» синтаксис позволяет добавлять атрибуты. Если партия скажет «надо», синтаксис ломать не придётся - достаточно будет лишь расширить.

Говно.

Ты в синтаксис притянул библиотеку и думаешь что это хорошо?

Не надоело еще пиарить это?

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

Поймите наконец, что код, это своего рода формализованный язык, родственный математике или математической логике. Как угодно. Никому в голову еще не взбрело «национализировать» математику. Легко задуматься и понять почему.

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

den73, кнч уже

Всё правильно сказал. Подписываюсь под каждым словом.

От себя добавлю ещё, что такой замудрённый синтаксис простейших вещей отпугнёт последних желающих приобщиться. Это как приделать панель управления от реактивного истребителя к велосипеду (и да, пока ты не разберёшься со всеми тумблерами - он не снимется с тормоза). Да, теперь ты можешь 10 способами затормозить и 20 способами изменить скорость, но нужно ли оно тебе?

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

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

Нафига при объявлении строки явное указание, где она хранится, read-only атрибут и т. д.? Разве нельзя всё это извлечь из описания переменной, которой эта строка присвоена? Одни и те же вещи должны делаться в одной и той же манере. Чем строка так принципиально отличается от других типов данных?

Нафига столько разных опций экранирования и изменения кавычек? От всего этого требуется одно - чтобы не слишком многословно и позволяло задать любую последовательность символов (то есть позволяло вставлять кавычки, а также спецсимволы). И то же сишное экранирование прекрасно с этим справляется. И используется в 99% языков, поэтому его правила все знают наизусть. Какие реальные use-case у возможности задавать кастомные символы конца строки и экранирования? Удовлетворение желания извращенцев, которые превращают программирование в ASCII Art? Это как молоток с регулируемой RGB-подсветкой. Гвозди, конечно, забивает, но немой вопрос «нафига» всё равно остаётся. Хотя не, это даже хуже - 90% будет использовать «чс_си», а в коде 10% чёрт ногу сломит.

Нафига при объявлении строки явное указание, где она хранится, read-only атрибут и т. д.?

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

Однако тип данных ты не всегда можешь вынести в переменную. Например,

printf("%s","asdf");

Какие реальные use-case у возможности задавать кастомные символы конца строки и экранирования?

Давай определимся. Ты утверждаешь, что их нет или ты у меня спрашиваешь?

Какие реальные use-case у возможности задавать кастомные символы конца строки и экранирования?

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

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

Строки есть, а переменных нет. Нифига себе новость!

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

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

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

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

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

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

А недостаточное количество способов сделать то, что надо, рождает велопарк приспособлений типа Qt-шного tr, L из винды и т.п. Такой велопарк, конечно, немеряно красив, полезен и нужен.

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

Окей. Атрибуты строки (read-only, место размещения) ты таки вынес в объявление переменной. Хорошее решение, похвально.

Насчёт настраиваемого формата оформления строки, несмотря на возможные use case, я остаюсь при своём мнении. Ну хотя бы взял бы ты питоновский факт с его тройными кавычками, которые заставляют обрабатывать строку полностью «как есть». Бесконечное количество вариантов представления строки - зло. Я уже написал про велосипед с панелью управления от самолёта. Ты делаешь именно это.

А про поддержку локализации на уровне компилятора ты так и не ответил. Чем плохи биндинги к gettext и аналогам?

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

Да и с точки зрения программиста чем отличается tr(строка) от какая_то_твоя_функция(строка)?

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

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

Да, это минус. Но хередоки нужны, особенно 1с |-отступов в перле не хватает; экранирование \Q\E нужно, регэкспы бывают нужны. Нельзя говорить «ненужно» только потому что что-то редкий случай. Редкость надо умножать на сложность альтернативы, только потом сравнивать. Вот луа-сорец я могу вкомпилять objcopy, или положить его в share, pfiles, resources в зависимости от системы. Но тут же возникает вопрос об удобстве сопровождения или кросплатформенном способе загрузки ресурсов (чтобы модуль не знал о платформе). Видишь сколько головняков просто потому, что " local x = 0\n" выглядит коряво и плохо редактируется?

К тому же отступы, экраны и хередоки это не одно и то же, не tmtowtdi. Так можно и while() выкинуть, потому что for() уже есть.

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

Это если lua-кода много. А если там однострочник, то никаких проблем нет.

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

Если речь идёт о языке программирования, то можно. Ты ведь не жалуешься, что в синтаксисе какого-нибудь питона нет, скажем, поддержки работы с serial port? Библиотека для работы с последовательном портом есть, но это именно внешняя библиотека, а не часть языка. Нет ключевого слова WriteDataToSerialPort.

Для билд-фазы есть более прямой путь — objcopy.

Но засада в том, что там двенадцатистрочник не обернутый в функцию, причем свободные значения (upvalues) в него биндятся по месту использования. Это как sql-запросы с вопросиками '?' писать во внешних файлах, кстати они более яркий пример.

Естественно, я как-то изворачиваюсь на том, что имею, и возможности есть. Но тут речь веду о комфорте, а не о «полноте по тьюрингу».

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

Для легаси - да. Для нового языка не вижу никаких проблем повертеть несколько прототипов и оценить трейдоффы, /если/ они возникнут на почве нововведений. В других несишках тоже есть примитивы вроде async, yield, <-, arc, которые можно эмулировать через sjlj, сокеты, m4, etc., но они же там есть.

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

С этим не спорю. Но ты вряд ли дочитал её до конца.

Да и с точки зрения программиста чем отличается tr(строка) от какая_то_твоя_функция(строка)?

Кардинально отличается. tr - это расширение языка, а не функция. Только пишется одинаково.

синтаксис ... должен быть более-менее минималистичен и однозначен.

А как насчёт Перла, Питона, bash, Common Lisp, Tcl, Forth? Если тебе больше всего нравится С, то это ещё не значит, что все языки должны быть похожи именно на него. Языки бывают очень разные.

Атрибуты строки (read-only, место размещения) ты таки вынес в объявление переменной. Хорошее решение, похвально.

Даже это решение неоднозначно, я привёл пример с printf. Вынос типа из синтаксиса может потребовать явного приведения типа и танцев с бубном, чтобы сразу формировался нужный литерал (а не в рантайме приведение типов). В итоге реальный литерал будет выглядеть как-то ШирокаяСтрока(«моя строка»), что гораздо более ужасно, чем какое-нибудь L"моя строка". Потому данное решение и зафиксировано в документе, что при следующем проходе этот вопрос опять всплывёт. На самом деле, я хотел запихать тип в синтаксис, но меня остановило лишь то, что типов строк слишком много, чтобы я рискнул на данном этапе лезть в то, чтобы перечислять хотя бы самые нужные. Если бы набор типов был налицо, вполне возможно, код типа добавился бы в «чс».

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

Потому и нет, что порт - это объект, а строка - это элемент синтаксиса.

Кардинально отличается. tr - это расширение языка, а не функция. Только пишется одинаково.

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

Той же самый питон даже более минималистичный чем Си (там даже банального цикла с постусловием нет). Не надо путать язык и его стандартную библиотеку. Последней вполне позволительно быть жирной.

ч_строку :р мой_ресурс :з «№» :н «Начало_текстА» :ц «Конец_текстА» :м «б» Начало_текстАстрока №№1 вторая строкаКонец_текстА кнч

Я ничЕго не понЯла, но почему такиЕ страннЫеУдАрения?

Той же самый питон даже более минималистичный чем Си

Ха. Ты Питон-то знаешь? Смотри, сколько в минималистичном Питоне способов создать новую строку, о большинстве из которых я узнал только что.

S = 'str'; S = "str"; S = '''str'''; S = """str"""
S = "s\np\ta\nbbb"
S = r"C:\temp\new"
S = b"byte"

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

Он все минималистичны и единообразны.

Твоя точка зрения меняется на ходу. То тебе достаточно С и не нужно тащить в ядро много способов, теперь я тебе показываю много способов в ядре Питона - и вдруг это стало нормальным, потому что они минималистичны и единообразны. Хотя они не единообразны. Буква перед строкой служит для разных целей - для определения экранирования и для задания типа. Могу ли я сделать строку байтов с отключённым экранированием? Если нет, то почему два ортогональных понятия стали не ортогональными? Чем это полезно? В Питоне вариантов синтаксиса достаточно много, и они покрывают не всё, что может понадобиться.

Тип не по умолчанию можно задать всего лишь один. Определение экранирования не по умолчанию можно задать только одно. Видимо, Гвидо сделал сахар для того, что ему первым попалось, а дальше бросил. А что, если мне понадобится строка не из байтов, а UCS-4? В Яре я хотя бы смогу это потом добавить в самый «жирный» синтаксис и синтаксис в целом не сломается (я это продумал, хотя, может быть, и не написал). А в Питоне что делать?

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

Во всех нормальных языках и фреймворках системная кодировка всегда одна (UTF-8 или UTF-16). А перекодирование осущещствляется только внутри функций ввода-вывода. Это гораздо удобнее, потому что в любой момент времени быть уверенным, в какой кодировке строка. А если строка имеет отличную кодировку, то это уже не строка, а массив чисел (хотя её можно преобразовать из/в строку с помощью спецфункций, явно указав кодировку). Иначе почём зря раздувается стандартная библиотека (все строковые функции надо продублировать для всех кодировок) и добавляется куча проверок. Что будет если сложить строку в кодировке Windows-1251 со строкой в кодировке CP-866? Каков бы не был ответ, он будет нифига неинтуитивен и приведёт к ошибкам. А если мне нужна кодировка, которую не умеет твой компилятор? Править компилятор? Или нарушать единообразие, работая с такой строкой как в других языках (перекодировать в юникодовскую строку, обработать по-человечески, перекодировать обратно)?

Знаешь в чём проблема твоего способа? То что невозможно отличить объявление строки от вызова функции. Это очень плохо. Синтаксис должен быть единообразным. Ты принял, что «идентификатор(параметры)» - это вызов функций, так пусть это будет вызовом функций с соответствующей семантикой (даже паскалевское приведение типов более-менее подходит под это правило - можно считать, что для каждого типа есть одноимённая функция, которая принимает void и возвращает нужный тип). А у тебя появляется исключение из правил «конечно, это вызов функции, однако если имя функции такое-то, то это не функция, а сахар, а вместо аргументов может быть произвольная последовательность символов, в том числе зависящая от части себя».

А из-за цикла с постусловием в луа отсутствует «банальный» continue :)

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

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

У меня тащемта куча своих патчей к луа, начиная от русификации и !=, заканчивая короткими лямбдами \а,б {=а+б}. Надо как-нибудь все оформить да выложить на гх.

что тебе он сделал? :D

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

Тройных кавычек этому сударю.

Могу ли я сделать строку байтов с отключённым экранированием?

br"no-escape\n"

А что, если мне понадобится строка не из байтов, а UCS-4?

'in-ucs-4'.encode('utf-32')

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

В Си почти то же самое. А в С++ с возможностями перекрыть операции равно и запятая - ещё хуже. И ничего.

А если мне нужна кодировка, которую не умеет твой компилятор? Править компилятор?

Да. На то и опен-соурс, чтобы можно было поправить.

почём зря раздувается стандартная библиотека

На чём основана твоя мера раздутости или не раздутости стандартной библиотеки?

br"no-escape\n"
'in-ucs-4'.encode('utf-32')

Это примерно и есть то, что я собираюсь делать. В последней редакции это выглядит так:

byte_string.ч(*no-escape\n*)
кодировки:ucs-4."utf-32" // пока не определено, как идентифицируется кодировка

После того, как несостоятельность данной точки зрения была доказана

Где?

Могу ли я сделать строку байтов с отключённым экранированием?

Можешь, это «ортогональные понятия».

Тип не по умолчанию можно задать всего лишь один.

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

А что, если мне понадобится строка не из байтов, а UCS-4

Строка в UCS-4 это такой-же набор байт, если конечно строки яра в нем не хранят кодпойнты. В питоне это понимают, а ты нет. Строки это то что с чем работают всякие find, substring и иже с ними. Инфа соточка что stdlib твоего яр будет поддерживать строки только в одной кодировке.

А в Питоне что делать?

Уже все сделано, есть строки, которые абстрагированы от кодировки.

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

Это способ задания енкодинга набора байт/строки в тексте программы, поэтому неотделим от литерала.

Здесь есть на самом деле два аспекта. Способ кодировки набора байт в тексте программы и тип объекта, который будет создан из этой записи.

Имеет значение и то, и другое. Тип объекта пока оставим, а вопрос про кодировку. У меня пока фиксированная кодировка текста программы - utf-8. В какой кодировке находятся исходные файлы Питона? Всегда в какой-то одной или это где-то определяется? И пруфлинк, пожалуйста.

Способ кодировки набора байт в тексте программы

Очевидно он должен быть одинаков для всех строк исходника.

https://docs.python.org/2/tutorial/interpreter.html#source-code-encoding

Для всех строковых литералов, конечно.

Т.е., если я в питоне сделаю кодировку utf-8 и напишу b"ю", то получу массив из двух байт 209 и 142?

Т.е., если я в питоне сделаю кодировку utf-8 и напишу b"ю", то получу массив из двух байт 209 и 142?

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

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