Добрый вечер, Сергей Юрьевич! «…скажу про Python и Go: это настолько развесистые языки по сравнению с рефалом…»
Если делать Рефал промышленным языком, то он тоже неизбежно станет развесистым. И тогда в него можно будет добавить и синтаксис для ассоциативных массивов тоже. Рефал-2 был промышленным языком и в нём был, к примеру, выразительный синтаксис спецификаторов переменных. В задачах обработки текста вроде лексического анализа образцы со спецификаторами вполне заменяли регулярные выражения (кстати, регулярные выражения я бы в Рефал добавил). Также в нём были статические и динамические ящики, которых нет в Рефале-5. Рефал-6 и Рефал Плюс тоже тяготеют к промышленным языкам и тоже в разы развесистее, чем Рефал-5. Перечислять их возможности я тут не буду. Сравнение из мира Лиспа. Есть язык Scheme R⁵RS, который академический и очень компактный, и он очень неплох для обучения студентов разным интересным концепциям (рекурсия, высший порядок, код как данные, макросы, континуации и т.д.). И есть промышленный язык Racket, основанный на Scheme, и он крайне развесист (есть даже богатое сопоставление с <https://docs.racket-lang.org/reference/match.html> образцом). Графическая IDE для Racket’а — DrRacket написана на Racket’е. Надо просто понять, что мы хотим от Рефала. Если мы хотим академический язык, то у нас уже есть Рефал-5, на котором можно писать модельные и экспериментальные суперкомпиляторы, лабораторные работы по генерации модельного ассемблера для модельного императивного языка и т.д. Но что-то серьёзное на нём не напишешь. Если хотим промышленный — есть Рефал-2, Рефал-6 и Рефал Плюс. «…а ограничиться одной конструкцией „generator comprehension“…» Конечно, конструкции {a for b in c}, {a : b for c in d}, [a for b in c] вполне заменяются на set(a for b in c), dict((a, b) for c in d) и list(a for b in c), так что являются синтаксическим сахаром. Но списковые, словарные и множественные включения отличаются от генераторных включений только другими скобками вокруг (и двоеточием для словарей) и дополняют литералы соответствующих типов. Добавить их реализацию несложно, программистами понимаются легко, на практике позволяют писать код лаконичнее, т.к. списковые включения используются чаще генераторных. «ну а что касается отдельной конструкции `del M[key]` для удаления словарной пары, то это за гранью добра и зла» Более того, эта конструкция применима и к спискам — удаляет элемент в i-й позиции, разумеется, с линейной сложностью. Также применима к переменным — удаляет переменную из области видимости. Такая вот дичь. «А вот это классная идея (если я её правильно понял)!» Да, Вы всё правильно поняли. С уважением, Александр Коновалов From: Sergei Skorobogatov s.yu.skorobogatov_AT_gmail.com <[email protected]> Sent: Monday, November 11, 2024 1:23 PM To: [email protected] Subject: Re: Синтаксис словарей в Рефале! Здравствуйте, Александр! On Mon, Nov 11, 2024 at 10:15 AM Александр Коновалов a.v.konovalov87_AT_mail.ru <http://a.v.konovalov87_AT_mail.ru> <[email protected] <mailto:[email protected]> > wrote: Ряд промышленных языков (Perl, Python, Go) поддерживают ассоциативные массивы на уровне синтаксиса, в ряде языков (JavaScript, PHP, Lua) встроенные массивы уже ассоциативные (целочисленные ключи — частный случай применения), стандартные библиотеки многих ЯВУ предоставляют типы ассоциативных массивов. Так что задача не такая уж и частная. Но то, что усложнение семантики существенное — согласен. Я не знаю Perl, поэтому скажу про Python и Go: это настолько развесистые языки по сравнению с рефалом, что поддержка ассоциативных массивов на уровне синтаксиса, будучи, на мой взгляд, дурацкой идеей, их не сильно портит. В Go надо было изначально делать обобщённые типы, и тогда отдельный синтаксис для хеш-таблиц им бы не понадобился. В Python надо было бы не городить "list comprehension", "dictionary comprehension" и "set comprehension", а ограничиться одной конструкцией "generator comprehension" (ну а что касается отдельной конструкции `del M[key]` для удаления словарной пары, то это за гранью добра и зла). On Mon, Nov 11, 2024 at 10:15 AM Александр Коновалов a.v.konovalov87_AT_mail.ru <http://a.v.konovalov87_AT_mail.ru> <[email protected] <mailto:[email protected]> > wrote: Можно в скобочные термы добавлять пометку $D (или $I от слова «index», или $M от «map» и т.д.), говорящую о том, что это индексированный терм, при сопоставлении с образцом индекс надо учитывать, при построении результата — создавать. Ну и в руководстве описать формальные правила, которым содержимое терма должно удовлетворять. Нарушение этих правил — не ошибка, просто индекс работать не будет (т.е. роль у $D примерно такая, как у ключевых слов register и inline в C++ — компилятор их учитывать не обязан). Компилятор в подобных случаях может выдавать предупреждения. А вот это классная идея (если я её правильно понял)! Т.е. для эффективного поиска алгоритм сопоставления с образцом использует индекс, прикреплённый к выражению, если этот индекс существует. Но порождение индекса делается не автоматически, а по желанию пользователя, который может пометить выражение, для которого нужно построить индекс, с помощью ключевого слова. Это минимально расширяет синтаксис, вообще не меняет семантику, и не ухудшает производительность тех программ, которым не нужен поиск в ассоциативных списках. Единственный недостаток такого консервативного подхода состоит в том, что мы не можем надеяться на внезапное ускорение старых программ, но это не такая уж и беда, учитывая их количество :-)
