Так ведь можно так: [list]

В тексте это так:

Так ведь можно так: [[list]]

Зацени foo[bar[x]] против dict get $foo [dict get $bar $x].

А, да. Но это отдельный вопрос.

Не только. Смотри, вот идиоматичный руби: str.foo.bar.baz, теперь то же в тикле: string baz [string bar [string foo $str]]. Такой адок, а потом удивляются чойта тикль непопулярен.

заалиасить стринг базы никак нельзя чтоли?

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

А что у Вас, сударь, с вебом

tcl vs rebol/red (комментарий)

вот идиоматичный руби: str.foo.bar.baz, теперь то же в тикле: string baz [string bar [string foo $str]]. Такой адок, а потом удивляются чойта тикль непопулярен.

Я после лиспа как-то не заметил. Хотя да. Только всё же я думаю что dict get.

можно расшифровать ваши мысли?

заалиасить стринг базы никак нельзя чтоли?

Костыли-костылики. Очевидно, что без грамматики и полиморфизма получается длинно и муторно, и руки сами тянутся за костылями, что есть признак негодноты. Ладно бы это давало какие-то плюшки, но нет же. Если не считать возможность накостылить на строках какой-то свой уличный for например. Хотя опять в том же руби это гораздо проще, ведь там есть замыкания и удобный синтаксис для них.

тарабарщинакакая то

Судя по https://forum.oberoncore.ru/viewtopic.php?f=1&t=6236 , это что, самая что ни на есть Московская Патриархия, и папа Римский?

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

Пруф: https://zx.oberon2.ru/forum/viewtopic.php?f=37&t=370#p2384

Но сектанты взвились, так что я удивлён, что оно дошло до транка, а не было сожжено на костре:

https://forum.oberoncore.ru/viewtopic.php?f=1&t=6236

В лиспе доступ к полям структуры такой:

(имя-типа-структуры-имя-поля экземпляр)

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

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

чтобы в данном случае получать сообщение об ошибке, язык не должен быть type-less. То есть та сущность которую ты передал аргументом должна быть разобрана на структурные примитивы, одним из которых будет «строка с пробелами». И для работы с разными примитивами понадобятся разные инструкции языка.

ps. короче, см. тему с начала :-)

Конечно, не должен. Тикль мне не нравится тем, что он typeless. Я хочу typeful, но с сохранением элегантной записи (там, где она элегантна).

Хотя на самом деле тикль - не typeless. Просто типы там выражены по-другому. Например, не всякая строка является словарём. Если она не является словарём, будет (или должна быть) ошибка при попытке обращаться к ней с помощью dict. Это - некий аналог типа. Если берём либу для JSON, то не всякая строка является корректным JSON-ом. Т.е. вроде всё строка, и в то же время оно может быть словарём, json-ом, именем переменной и проч. Или не быть.

Например, не всякая строка является словарём. Если она не является словарём, будет (или должна быть) ошибка при попытке обращаться к ней с помощью dict. Это - некий аналог типа. Если берём либу для JSON, то не всякая строка является корректным JSON-ом. Т.е. вроде всё строка, и в то же время оно может быть словарём, json-ом, именем переменной и проч. Или не быть.

Т.е. вроде всё строка, и в то же время оно может быть словарём, json-ом, именем переменной и проч. Или не быть.

всё есть моноид. моноид моноидов тоже моноид. частные случаи моноидов : строка, объект, класс, метакласс, объектный протокол, алгебра, алгебраическая структура, монада Maybe (быть или не быть), монада State.

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

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

либо моноиды «некомпозабельны». то есть, состояния в одном не объединяются с состояниями в другом в третий, общий. у одного один тип, контекст, действия этапов жизненного цикла, у другого — другой. и или можно их связать, погрузив в монады State или Maybe — или нельзя.

например, возникнет ошибка типов в рантайме. потому что не заданы ограничения.

если код это модель, то что происходит с View и Controller? если есть общая модель, то к ней можно подсоединиться с разными View и Controller. и либо у нас есть виджеты с контейнерами и «композабельным» View и соответствующее API состоянний, контекстов и коэффектов Controller'а. либо неявные требования контекстов (которые можно формализовать явно через коэффекты) не удовлетворяются, и в целом паттерн паттернов не работает.

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

но без более-менее явной формализации требований, контекстов, коэффектов; без совместного изменения для одной M и V, и C — составимость таких моделей не работает.

модельки получаются некомпозабельны.

runtime error.

короче: определи типы или контексты использования.

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

они де-факто в тикле определены, хотя их якобы нет

их и де-факто нет. Текст есть а их нет.

Имплементируются так как тебе видится только в контексте «dict». Обрати внимание на expr а ещё лучше на if. В последнем вообще совсем всё подругому чем в прочем tcl. Просто аргумент разбирается и имплементриуется принимающей стороной от её «тараканов», просто она так видит :-)

ps/ есть замечательный rl_json который оперирует жсонами - он и современный и компактный, посмотри как на C это устроено

Текст есть а их нет

Это - вопрос во многом философский. В моей философии они есть :) Если пишешь любой DSL (хоть тот же json), то можно определить множество строк, являющихся валидными для этого json. Это будет подмножество всевозможных строк. Можно назвать типом.

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

И не знаю, что там про это говорят в теоркате :)

Люди, привычные к другим языкам, могут возмутиться и сказать, что раз нельзя определить типизированную переменную, то и типа «словарь» нет. Но есть языки, у которых типы есть, а типизированных переменных нет. Другие скажут, что типы без type_of - это не типы. Но в Си тоже нет type of. Т.е. то, что я называю в тикле типами - ничуть не хуже, чем типы в других языках.

Как оно устроено в Си - неважно. Сейчас смотрим только на обложку.

Это - вопрос во многом философский. В моей философии они есть :)

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

тут понимаешь какая штука..тикль, ребол, оберон они все не в курсе твоей философии :-) в тикле нет типов, а идеологи оберона вполне внятно объяснили про отладчик.

Ну, на нет и суда нет, а отладчик оберона теперь в транке.

Слушай, анон, давно наблюдаю за такими твоими постами и нахожу, что мысли у тебя в голове интересные. Но я редко когда понимаю до конца, о чём идёт речь. Так как в качестве хобби я иногда подумываю о схожих вещах, не мог бы ты изложить сюда, что нужно знать в этой труднообозначаемой области? Эдакий roadmap или хотя бы просто список слов к гуглению. Haskell на уровне монадных трансформеров знаю (т.е. фактически новичок), теорию категорий - совсем чуть-чуть, пока не схватил суть натуральных трансформаций. Есть опыт с джавой, но не очень большой, с CL, питоном и Mathematica. Думаю, что понимаю их семантику. Есть ощущение, что надо курить теорию моделей, но она страшна и ещё более непонятная, чем теория категорий.

Короче, мог бы ты поделиться мудростью? :)

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

например, мне очень понравилась докторская Ковалёва Сергея Протасовича на тему «Теоретико-категорные модели и методы проектирования больших ИУС». там про синтез ИС в аспектно-ориентированном программировании на основании доказательства ряда теорем по теории категорий, причём оказывается что аспекты вполне неплохо формализуются в теории категорий. в итоге всё это имеет вполне конкретное практическое значение. кандидатская у него, кстати, тоже интересная.

ещё про амальгаму в категории занятно.

а попал я туда по ссылке от AI :) Левенчука раз два

А.И. Левенчук занимается системной инженерией.

у него есть хороший учебник по этому делу.

Пора тебе на Racket посмотреть.

+100500 писал бы уже свой яр на специально созданной для сей бесполезной задачи ракетке и не парил моцк людям.

ещё интересно: про метапрограммирование ТЕОРЕТИКО-КАТЕГОРНЫЙ ПОДХОД К МЕТАПРОГРАММИРОВАНИЮ

куча любопытного кода на red

от автора

до кучи. обучалки про REBOL

Learn REBOL

The Easiest Programming Language:REBOL

Creating Business Applications With REBOL

Programming with REBOL

про диалекты

makedoc2, простой генератор документации. описание и ссылки на продолжение идеи

как пользоваться makedoc

фича что можно писать исполняемые скрипты на REBOL в конце, например.

из ссылок в описании интересны: nimdoc и RebXML, LaTeX бекенд; make-doc-pro;

MakeDoc3 с LitProg примерами

например