LINUX.ORG.RU

а вам кажется странным поведение двойных кавычек в tcl?

 , ,


2

6

Принимая во внимание следующее:

  • списки в tcl не построены из консов
  • списки в tcl на печати изображаются с помощью фигурных скобок
  • при этом внешняя пара фигурных скобок при печати опускается
  • слова можно считать символами
  • {*} по смыслу есть ,@ (см. Википедию)

Получаем следующее:

# присвоим переменной v список из двух символов b и с
> set v {b c} 
b c 
; то же в лиспе
> (setq v '(b c))
(b c)

# построим двухэтажный список
> list a $v
a {b c}
; то же в лиспе 
> (list 'a v)
; то же в лиспе с помощью квазицитирования
> `(a ,v)

# вклеим содержимое v в список
> list a {*}$v
a b c
; то же в лиспе с помощью квазицитирования
> `(a ,@v)

# А вот это что и зачем? 
> puts "a $v"
a b c

# А так не работает:
> puts "a {*}$v"
a {*}b c

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

> "a $v"
a {b c}
> "a {*}$v"
a b c

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

★★★★★

Последнее исправление: den73 (всего исправлений: 2)

Ответ на: комментарий от monk

Потому что ls -l *.sh - это список из трёх элементов, но с отсутствующими скобками. Запятых тут нет. Так и в тикле, и в баше. Вообще, чтобы быть ближе к тиклю, скобки тут должны быть фигурными, но на данном этапе обсуждения это неважно .

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Спасибо за пример, пришлось над ним подумать. Попробую так ответить: если попытаться так представить дерево (например, html-страницу), то будет проблема, поскольку нельзя отличить лист от ветки.

не понял проблему, процедура build-menu рекурсивная и прекрасно с этим справляется
можешь посмотреть как этот же код build-menu обработает конфигурацию меню, например, такой вложенности:

set menu {
    "File" {
        "Open"      { -command file_open }
        "Save"      { -command file_save }
        "Save as.." { -command file_save_as }
        "Close"     { -command file_close }
        "Exit"      { -command exit }
    }
    "Edit" {
        "Cut"   { -command edit_cut }
        "Copy"  { -command edit_copy }
        "Paste" { -command edit_paste }
    }
    "Config" {
        "Preferances" {
                 "Color" {
                     "Foreground" { -command fgcolor }
                     "Background" { -command bgcolor }
                 }
                 "Font"  { -command font }
        }
        "Connection" {
                 "Log in"  { -command login }
                 "Log out" { -command logout }
        }
    }
    "Help" {
        "Topic" { -command help }
        "About" { -command about }
    }
    -name menu
}

anonymous
()
Ответ на: комментарий от den73

Потому что ls -l *.sh - это список из трёх элементов

Считать имя команды и аргументы списком не совсем верно. Можно, но тогда получаем getopt и прочие прелести. С точки вызова это структура: имя команды, позиционные аргументы (список, отдельные элементы могут быть из нескольких слов), флаги (множество).

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

Там и скобок нет. В тикле и баше список — это «a b c».

monk ★★★★★
()
Ответ на: комментарий от anonymous

Могу ли я сделать пункт меню с именем "-command"?

den73 ★★★★★
() автор топика
Ответ на: комментарий от monk

Считать имя команды и аргументы списком не совсем верно.

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

Там и скобок нет.

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

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

В списке нет, а если мы хотим подсписок, то могут и быть.

Список с подсписком в баше:

a b "c d" e

В Tcl фигурные скобки

В ps и подобных командах списочные аргументы вида a,b,c

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

a b c
a b,c d,e
a b,(c,d) e
a,(b,(c,d),e) f

Лаконично, читабельно, совместимо с sh и coreutils.

monk ★★★★★
()
Ответ на: комментарий от monk

С тиклем не особо совместимо:

if (1) {puts ok}
Здесь {puts ok} - это список. С тем же успехом работает и
if (1) "puts ok"
А в лиспе это было бы
(if 1 (puts "ok"))
Т.е. идея делать вложенные списки иного формата сразу конфликтует с представлением кода, которое в тикле вполне осмысленное. Т.е. я вижу такое представление разумным:
{if (1) {puts ok}}
Но открывающая фигурная скобка подразумевается в начале строки, а закрывающая - в конце. Теперь мы прошли ещё на один шаг вперёд и утыкаемся в то, что так тоже работать не будет - с закрывающей скобкой будет проблема
if (1) { // в начале ок. А в конце? 
  puts ok // здесь всё норм - подразумевается в начале и конце
} // в конце ок - скобка закроет if. А в начале? 

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 4)
Ответ на: комментарий от den73

Здесь {puts ok} - это список. С тем же успехом работает и

Здесь это команда. Точнее текст программы. Вообще идею делать запускаемыми конструкции типа (when (test) (cons 'write '(ok))) только в пиколиспе видел. Даже в common lisp'е выражения являются списками только в макросах.

{if (1) {puts ok}}

С чего это языковая конструкция должна быть списком?

С тиклем не особо совместимо:

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

monk ★★★★★
()
Ответ на: комментарий от monk

Речь не идёт об идентичном, а идёт о таком синтаксисе, который, сохраняя баланс тикля между лаконичным, простым и удобным, позволит ещё и иметь вложенные списки, да ещё и гомоиконно. Это была основная цель при создании синтаксиса Яра, которой так и не удалось добиться. Тикль, наверное, подошёл ближе, т.к. его синтаксис очень простой. Только вот вложенных списков не хватает и quoting hell получился.

Даже в common lisp'е выражения являются списками только в макросах.

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

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

позволит ещё и иметь вложенные списки, да ещё и гомоиконно

Если в требованиях «гомоиконно», то тогда с твоим вариантом согласен.

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

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

monk ★★★★★
()
Ответ на: комментарий от den73

Здесь {puts ok} - это список.

А если бы было if (1) {expr {2+4*2}}, то 2+4*2 — это тоже список?

Или как будешь парсить expr {5 / ( [string length «abcd»] + 0.0 )} ?

monk ★★★★★
()
Ответ на: комментарий от monk

2+4*2 - это строка, которую парсят отдельным парсером выражений. Арифметика - это большая бяка. Хоть требование писать expr и выглядит на первый взгляд дикостью, на практике это почему-то совсем не ранит.

Или как будешь парсить expr {5 / ( [string length «abcd»] + 0.0 )}

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Но совершенно точно, что для арифметики нужен отдельный парсер и тут не будет AST

Тогда гомоиконость идёт лесом. И появляется смысл в отдельном парсере и для других конструкций языка.

ведь они как-то решили эти вопросы с виртуальными скобками

Так они не виртуальные. Это просто символы «{» и «}» внутри строки. И трактовка парсера списков, что подстроку «{.*}» надо трактовать как элемент, значение которого — содержимое между скобками. Тикль вообще весь в терминах строк и регулярных выражений определяется, а не списков.

monk ★★★★★
()
Ответ на: комментарий от monk

Тикль вообще весь в терминах строк

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

Почитал man Tcl, там написано, что команда сначала разбивается по разделителям «\n» и ";", а уже потом бьётся на слова по пробелам с учётом {}"". Вот он, неявно заданный и негомоиконный двухуровневый список с разными разделителями на разных уровнях. Тело if, заключённое в фигурные скобки, тоже будет так разбито, но уже во время выполнения if. В процессе чтения if - это просто строка, ограниченная фигурными скобками. Т.е. токенизатор при чтении if снимает фигурные скобки и сохраняет получившуюся строку как тело одной из ветвей. А если эта ветвь выбрана, то токенизатор снова бьёт её на токены по \n; , потом на слова и получает новое тело составного оператора. Вроде нам это и нужно, но нужно сделать это гомоиконным и вынести токенизатор с этапа выполнения на этап чтения файла. Тогда и получится современный лисп (не f-expr, а больше похожий на CL и Scheme), и с более хорошим синтаксисом.

Попробуем так (граница списков условно обозначается знаками <>).

# lisp
(if 0 (puts 1) (puts '((a) b)))
# tcl (оказывается, слово else можно опустить!)
if 0 {puts 1} {puts ???}
# tclisp как бы мы хотели в идеале
<if 0 <puts 1> <puts <quote <<a> b>>>>
# tclisp синтаксис с воображаемыми скобками
if 0 <
  puts 1 
> else <
  puts <quote 
        <a> b
        >>
В последнем варианте, как и в тикле, происходит разбивка по символу конца строки, пустые элементы выкидываются. Далее каждый из элементов полученной последовательности окружается скобками (получается список), и вся вместе полученная последовательность тоже образует список. Получается в итоге такой лисповый список:
<if 0 <<puts 1>> <<puts <quote <<a> b>>>>>
Выглядит годно, хотя тело if оказывается списком списков, т.е. начинает путаться под ногами неявный progn. Это может быть неудобно. Чтобы в явном виде записать однострочный if, придётся поставить ещё одну пару скобок, это неинтуитивно после любого языка.
'(1
  2
  3
  4)
В тиклиспе же из
(1 
 2
 3 
 4)
Получится
<<<1> <2> <3> <4>>>

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Т.е., если сказать то же более коротко, то в тикле конец строки заменяет пару скобок в лиспе, но не всегда, а иногда. Это круто, но тоже не всегда, а иногда. А плохо то, что read вызывается из eval - такой язык обречён быть ненадёжной «скриптотой».

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

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

if 1 {
  puts x
}
и
if 1 { puts x }
невзирая на то, что количество разделителей - разное! Или тут дело не в этом? Что-то я запутался опять.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Похоже на то, что для кода идея использовать \n для группировки в списки является органичной (конец строки тем или иным образом является значимым в bash, tcl, basic, python, golang, javascript), а для данных - нет. В этом месте и возникает напряжение, когда мы пытаемся добавить гомоиконости.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

а для данных - нет

Почему? В bash, tcl, python, javascript при вводе буквальных данных используется разбивка \n. Или JSON и последовательность строк а for i in `cat /etc/passwd` — это не данные?

monk ★★★★★
()
Ответ на: комментарий от den73

невзирая на то, что количество разделителей - разное! Или тут дело не в этом? Что-то я запутался опять.

Именно в этом. И в том, что echo test | grep t должно работать, хотя grep хочет получить список строк.

monk ★★★★★
()
Ответ на: комментарий от monk

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

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Возможные решения для данных:

  • продлевать строки
  • сделать более одного формата списка

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

Второй вариант - тоже плохо, т.к. упирается в дефицит значков. Список требует двух значков - границы списка и разделитель. А если учесть, что в тикле есть {} и [], то как бы не пришлось умножать на два.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

единица данных с размером, равным ширине экрана (несколько десятков букв).

Не обязательно. Логи UNIX не имеют единицы в ширину экрана, но имеют строчную природу (и прекрасно обрабатываются grep'ом). Даже в passwd есть поле комментария произвольной длины

Для «данных вообще» может не быть такой единицы данных.

В UNIX считалось, что данные вообще надо по возможность хранить в текстовом формате с разбивкой на строки. Соответственно, всё, что несёт в себе отпечаток этой идеологии, имеет текстово-строчное представление: HTTP, grep, sed, perl, sh, tcl, SMTP, POP3, ftp://FTP...

monk ★★★★★
()
Ответ на: комментарий от den73

Второй вариант - тоже плохо, т.к. упирается в дефицит значков. Список требует двух значков - границы списка и разделитель. А если учесть, что в тикле есть {} и [], то как бы не пришлось умножать на два.

Так уже есть. Или {... ; ...; ...} или ...\n...\n...

monk ★★★★★
()
Ответ на: комментарий от monk

Не обязательно ... Даже в passwd есть поле комментария произвольной длины

Не обязательно, но в среднем. Оно так и работает: в часто встречающемся случае всё будет хорош, а редко встречающийся встречается редко.

Так уже есть. Или {... ; ...; ...} или ...\n...\n...

Это только в сторону уменьшения размера единицы информации, и только для двухуровневого списка. А для одноуровневого - нету.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

в часто встречающемся случае всё будет хорош, а редко встречающийся встречается редко

Worse is Better. Такова идеология UNIX.

и только для двухуровневого списка. А для одноуровневого - нету.

Ничего не понял.

a
b
c
и
{a; b; c}
одноуровневые списки.

monk ★★★★★
()
Ответ на: комментарий от den73

# tclisp как бы мы хотели в идеале
<if 0 <puts 1> <puts <quote <<a> b>>>>

Хлебать-копать... Как это развидеть? Уймись уже.

anonymous
()
Ответ на: комментарий от monk

одноуровневые списки.

if 1 { puts a ; puts b }
~=
(if 1 (progn (puts a) (puts b)))

Здесь тело if - двухуровневый список: составной оператор, а каждый оператор - это список из слов. Даже если это просто {a ; b; c}, то для интерпретатора это список (progn (a) (b) (c)). Двухуровневый опять же. Команда без аргументов - это список из команды и нуля аргументов.

den73 ★★★★★
() автор топика
Ответ на: комментарий от monk

Такова идеология UNIX

По сути решения два: либо сделать так, чтобы в большинстве случаев было удобно, а в меньшинстве сносно, либо усложнить систему так, чтобы было удобно и в простом случае, и в сложном. Но тогда больше учить. Я стремлюсь в данном случае к минимализму, иначе бы и не копался с таким минималистичным языком, как tcl.

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

Но это уже не будет тикль, поскольку вызов read из eval существенно увеличивает выразительную мощь тикля. Т.е. можно сделать тиклеобразный по синтаксису, более статический «лисп», в котором будут структуры данных, или сделать библиотеку для создания dict-ов из вложенных { { } } списков.

А вопрос о том, хорошо ли сконструирован сам тикль, отложим на завтра.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

А в сокрадённой нотации - так:

сделай-набор-вложенных-словарей { 
  A { 
    Зарегистрируйся 
    Игнорируй тег "Яр"
  }
  Б {
    Нажми Ctrl-W
  } } 

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

что-то мне начинает казаться, что тебе нужно изучить раздел про JSON: http://wiki.tcl.tk/13419
при этом, ознакомиться с Tcllib JSON: http://wiki.tcl.tk/40053
и очень внимательно посмотреть на Alternative JSON: http://wiki.tcl.tk/49031

ещё посмотреть на Playing XPath with JSON: http://wiki.tcl.tk/40865
ну и до кучи rl_json Extensions: http://wiki.tcl.tk/48276 + https://github.com/RubyLane/rl_json

anonymous
()
Ответ на: комментарий от anonymous

Спасибо! Так бы сразу :)

den73 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Посмотрел быстренько. Альтернатива по смыслу похоже на то, что я делал для SLIME, не считая того, что я не превратил это в словари. Т.е. да, круто, что можно сказать, что строка такого-то вида - это json, и подоткнуть под неё эффективное внутреннее представление. При этом она и визуально будет нормально выглядеть (хотя не факт, что всегда захочется видеть всё json дерево - иногда лучше видеть просто некий нумерованный поинтер, а содержимое смотреть по мере надобности). Т.е. в первом приближении можно сказать, что задача хранения структурированных данных таким способом действительно решается. Но всё же то, что она в любой момент и в любой точке может «провалиться» в строку, делает всю конструкцию хрупкой.

Буду думать дальше над всем этим...

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Только надо отметить, что Json из tcllib не является годнотой, т.к. строка неотличима от числа. Т.е. превращение в словарь и обратно необратимо (это не я нашёл, это нашли комментаторы). Это баг, я считаю. А вот альтернатива - да, годно. Единственно, когда я своё такое делал, не придумал, как обращаться к элементам с удобством. Приходится чуть ли не по два вызова делать - распаковка списка и извлечение элемента, при этом помнить, в каком формате то значение, с которым работаю в данный конкретный момент.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

В общем, всё, что я понимаю на данный момент - это то, что «всё строка» - это достаточно мощная и отдельная парадигма представления данных. До этого я знал две - условно говоря, Си с грамматикой и лисп с ридером (он же json). Гибридом между ними является Mathematica, когда снаружи грамматика, а внутри - лисп. Так вот, похоже, что тикль - это третья парадигма. Конечно, я ей давно пользуюсь, т.к. кое-что написал на тикле, и естественно, пользуюсь шеллами. В целом освоил, но никогда не воспринимал её всерьёз именно как парадигму. С начала этой темы её осознаю и всё пока никак не осознАю. Её свойства:

  • она отдельна от остальных
  • она элегантна и эффективна (достаточно посмотреть, какие программы пишутся на tcl в одно лицо)
  • она, наверное, позволяет выразить смысл наиболее плотно, поскольку в каждой точке встраивается, по сути, отдельный парсер.
  • её расширяемость устроена лучше, чем у CL. Она даёт то же, что macro-character-ы, но безопаснее и, зачастую, дешевле.
  • она позволяет оперировать типизированными сущностями
  • но типизированная сущность потеряет свой тип и станет строкой, если постоянно не предпринимать мер против этого

Последняя «фича» перечёркивает большинство плюсов. Как починить?

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Как починить?

сначала, почитать https://ru.wikipedia.org/wiki/Система_типов
затем, освежить в памяти https://ru.wikipedia.org/wiki/Теория_типов
вспомнить https://ru.wikipedia.org/wiki/Теория_категорий
далее, изучить табличку https://ru.wikipedia.org/wiki/Сравнение_языков_программирования#Типизация
и разобраться в своих ожиданиях от типизации: где, в каком виде и зачем она тебе нужна?

anonymous
()
Ответ на: комментарий от anonymous

надеюсь, заметишь немного юмора :)

anonymous
()
Ответ на: комментарий от anonymous

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от menangen

Проблема в том, что команды типа ls должны быть короткими. Даже разница между ls (три нажатия) и ls() (семь) будет вполне ощутимой. Т.е. всё равно нужен язык «типа шелла», а вот как он должен быть устроен? Сейчас я пытаюсь придумать синтакис, который лаконичен, как в шелле, но при этом чтобы язык был нормальным. Т.е. должен масштабироваться. ПОскольку на шелле ничего писать никогда не хотелось, а тикль вполне себе приятен, то вот поэтому и такая темка.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

Ещё такое философское умозаключение. То, что любой объект есть строка, делает его сериализуемым, а значит, более простым по структуре и для понимания. Т.е. это может положительно сказываться на понимаемости программ на tcl. Хотя на самом-то деле, как мы знаем, не все объекты прямо так вот представимы в виде строки (например, массивы «не являются строкой»).

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

И шелл/ls и tcl родом из юникса где изначальной вводной всегда были удаленный сервер и тупая и дешевая электромеханическая печатная машинка в качестве средства общения или как сегодня ssh который недалеко от этого ушел. По этому безтиповый набор символов, поэтому повернутость на конце строки.
В лисп-машинах тех же лет или в CLIM который перенес их идеи на ПК, фигуральный ls будут уже типизированый и «умный» при том же количестве нажатий. Ровно потому что рантайм находтся прямо перед юзером и начинает реагировать по первому символу. Спецификация как это устроено в деталях там есть. Шелл без скобок. Собствено все «новые» шеллы его и перизобретают. Правило Гринспена в действии:(
Единственое что можно сделать с шелом сейчас это перехватить управление в консоли как в zsh или fish, или просто сделать Совсем Другой Теминал как Terminology

antares0 ★★★★
()
Последнее исправление: antares0 (всего исправлений: 1)
Ответ на: комментарий от den73

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

den73 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.