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)

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

Итак, ти-си-лисп, проба №1 Список A: бьётся по строкам и ; , потом каждый фрагмент бьётся на слова и заворачивается ещё в список

(сло_во ; ещё-слово
  (слово) 
  слово1.слово2 ; это - особая конструкция "точка"
  {слово, нарушающее синтаксис слова :)})

`(квази ,цитата)
Список Б: то же, что список А, но НЕ бьётся по строкам. Тот же список, что в примере из списка А, но записанный в виде списка Б.
(: (сло_во) (ещё-слово) ((слово)) (слово1.слово2)
   ({слово, нарушающее синтаксис слова}) :)

Типизированный объект - начинается с @

@123 - целое, 
@.123е5 - плавающее 
@"строка"
@'символ'
@{слово}
; внутри списка всё типизированное без дополнительных @
; типизированный список - всегда типа Б
@('символ' {слово} 123 .123e5)
Слово является типом данных, который отличен от строки и символа. По сути, слово - это токен во входном потоке, до того, как стал известен его тип. Слово можно записать в переменную, но есть неявные преобразования, которые могут быть приписаны к аргументам процедур. Т.е. например, процедура начало-строки(с,ч) в своей сигнатуре может заявить, что первый аргумент - строка, а второй - число. Соответственно,
начало-строки 23 1 
==> 2
По умолчанию все данные печатаются в типизированном виде типизированного списка Б.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 4)
Ответ на: комментарий от den73
пусть з = 23
начало-строки $з 1

Что тут сделано? Мы записали слово {23} в переменную з. Должно ли это слово «отипиться» в момент записи? В тикле, ясное дело, нет, т.к. там вообще только строки. Я бы, наверное, заставил его отипиться в строку в момент присваивания. Т.е. нетипизированные слова - это только сахар для литералов, не более. А внутри мы будем больше похожи на лишпик.

Дальше, вопрос,

начало-строки з 1
// или 
начало-строки $з 1
// ?
Для интерактивного использования выбор очевиден. Для скриптов - нет. Можно сделать так, что само слово начало-строки будет в своей сигнатуре говорить, какие из своих аргументов оно использует как литерал, а какие - как имя переменной. Но стрёмно это. Лично я в таких ситуациях путаюсь. А они есть и в лиспе, и в том же тикле тоже, с теми же массивами или словарями - где-то нужна $, а где-то её быть не должно. Запомнить можно, но слегка цепляет.

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

Кстати, а вот как представляется типичный лисповый код в виде списка A, если немного подкрутить синтаксис лиспа:

(defun foo (x y)
  (let ((z (* 2 x y)))
    (+ (expt x 2) z (expt y 2)))))
С пергой (которую, я использую вдоль и поперёк в своём коде, тотально, которую, конечно, прокляли все true лисперы, но в asdf нечто подобное, под названием nest, всё же включили. Мне кажется лет через 5 после того, как я первый раз её прорекламировал, но не буду настаивать на приоритете - идея-то очевидная) получается так:
(defun foo (x y)
  (perga
    (let z (* 2 x y))
    (+ (expt x 2) z (expt y 2)))))
И дальше, вставляя в proc неявную пергу и используя тиклевый «неявный список, битый по концам строк», получаем на псевдотикле такое:
proc foo {x y} {
  let z [* 2 x y]
  + [expt x 2] z [expt y 2]
}
Очевидно, данный синтаксис получается намного более лёгким, чем был в начале (из 9 пар скобок осталось 5), хотя не все любители скобочек с этим согласятся.

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

Ну ладно, раз никому неинтересно, буду тогда дальше один думать. Всем спасибо, было полезно!

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

Может уже в 2018 сообщество созрело от ухода bash/coreutils gnu? То есть, можно уже переходить к новым ветвям развития линукс систем типа rancher os, к альтернативам glibc и этим же ls, bash. Был же какой-то дистр на основе node.js, где только он и всё (ну и сишная/сиплюс стандартная либа). И пакеты можно было бы ставить через такой “node shell”, который бы имел свой удобный парсер команд, ну и юзер спейс софт всё в докер контейнерах/lxc/lxd, кроме аудио и видео серверов.

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

Да всегда можно было к ним переходить. И было много заходов на эту тему, которые со временем загнулись по нетехническим причинам. JS, кстати, более-менее годен, хотя недостаточно :)

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

Ладно, раз про тикль и иже пошли такие оживлённые разговоры рядом, напишу тут. Дозрел до мысли про «лисп----», у которого всего два типа данных - список и атом. Список - это не кособокое дерево, а просто список. Вычисление требует пинка (доллар или квадратные скобки). Атом - это тиклевая строка.

Соответственно, виды скобок (условные)

« строка как {} в тикле, т.е. без подстановок »
$слово # получить значение слова
{*}$слово # кортеж из значений слова, которое должно быть списком
{элемент $элемент {подсписок}} # вложенный список, $ не работает
[ процедура $арг1 аргN ] # вычислить аргументы и вызвать 
# процедуру 
( контейнер индексы ) 
`{квазицитата ,[подстановка 1] ,$подстановка-2 ,{*}$как-кортеж
  [это не трогаем]}

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

При этом AST обладает более богатым набором типов, т.к. $,[],квазицитаты и подстановки создают свои типы. Т.е. пока что круг у нас не замкнулся, а имеется спираль. Но пора спать :)

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

В частности, есть ссылка на вот попытку объединения с ОО на базе хендлов. Также понравилась рассуждение escargo 2005-07-25, похожее на критику. Представление любого объекта строкой порождает не только преимущества, но и недостатки

  • Вне контекста тип объекта неизвестен, поэтому нельзя писать код, работающий с «любым объектом», например, сборщик мусора или какой-нибудь инспектор, показывающий список всех объектов в памяти вместе с информацией об их смысле. Смысла нет - он возникает только в момент использования.
  • Знания о типе нужно хранить где-то, это может иметь свою цену.
  • Можно и легко залезть внутрь любого объекта. Никакой приватности.

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

И ещё одну вещь я понял (возможно, уже писал про это). Есть языки, в которых слово вычисляется. Например f(a.b()) - здесь a вычисляется, а f и b являются константами (обозначающими функцию f и поле b). В тикле же почти всегда слово является константой, обозначающей самое это слово, а чтобы интерпретировать его как переменную, нужно поставить $.

Соответственно, если в коде много констант, то тикль лучше. Если в коде много переменных, то тикль хуже. Здесь наконец-то я начинаю подходить к мысли, что уровень достижимой универсальности ЯП ограничен. Я думал раньше, что существование множества ЯП в основном вызвано криворукостью авторов отдельных ЯП и хаотичностью развития отрасли, и что можно создать какой-то «гипер-лисп», который будет способен поглотить все остальные ЯП.

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

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

Ещё интересно сказано:

the connection between values and types is a many-to-many connection. Most languages assume a 1-to-many connection, so each value has a single type which is associated with it by the language

Но, с другой стороны, и в C, и в С++ можно представлять данные данными другого типа, именно для нужд склеивания. При этом, в обычной жизни тип безопасен (ошибиться сложно), а когда надо, можно его интерпретировать по-иному. И что же, неужели тикль лучше с его полным отсутствием защиты по типу? Подход «почти статически типизированных» языков выглядит явно более здравым.

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

На мой взгляд, всё же, списки существуют. Список - это то, что синтаксически является списком (например, не «{») и то, что было задумано программистом как список.

Засада состоит в том, что грань между списком и просто строкой отсутствует (и более того, религиозно отсутствие такой грани постулируется), а многие операции над строками похожи на операции над списками, которые эти строги могут представлять, но не являются таковыми. Очень легко написать: «a $b c», ожидая получить на выходе список. Это часто будет так, но вообще говоря, никакой список тут не гарантирован. Это особенно плохо потому, что это очень похоже на то, что происходит при вызове функций - там строится действительно список аргументов, и чтобы передать в функцию три аргумента, нужно написать именно «команда a $b c». Насколько я понимаю, подобная проблема часто встречается в коде на тикле, в т.ч., в различных библиотеках.

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

Из-за того, что некоторые команды воспринимают их как специальные символы, а некоторые - нет, поведение {} сложно, они ни в коем случае не столь же надёжны, как () в лиспе. Причём аналога лисповых () в тикле просто-напросто нет, как нет и механизма сериализации/десериализации через print/read. Казалось бы, если строки столь фундаментальны, то должно существовать нечто аналогичное паре print/read, но это либо не так, либо не столь явно (надо подумать, в чём именно тут проблема).

Официальный ответ на эту проблему состоит в том, что нужно применить тот или иной workaround. Т.е., tcl как язык содержит строки - и это хорошо. Но он не содержит деревьев, которые есть в JS, не говоря уже о лиспе. И это плохо. Их легко сделать, но это совсем не то же самое, что наличие деревьев в языке.

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

Обобщая, кажется, я нащупываю, в чём корень проблемы.

С концептуальной точки зрения тикль кажется гениально хорошим: в нём всего один тип данных, причём тот, который наиболее удобен для пользователя, а именно, строка. В апологии особенно подчёркивается, что в Си «всё - это число», и это менее удобно, чем «всё - это строка». А в лиспе есть разные типы данных, поэтому он не в той же степени сведён к минимальному набору аксиом, сложнее и МП в нём тоже сложнее. Это вроде похоже на правду - в лиспе есть отдельно функции и отдельно макросы, а в тикле - только одни команды, при этом МП в тикле не менее мощное.

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

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

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

Каждая команда тикля, в т.ч. встроенная - это новый полный DSL. Сам тикль только лишь подготавливает аргументы по единым правилам, а что внутри аргументов - дело самой команды. И эти DSL-и не совсем точно синхронизированы между собой. Отличия между ними - обычно тонкие, которые в спешке легко не заметить и проскочить. Например, _почти_ каждая строка без пробелов - это список из одного элемента, но не каждая. Синтаксис индексов массивов - почти такой же, как у аргументов в командной строке, но чуть другой. Конкатенация строк похожа на сложение списков. Наверняка каждая такая аномалия оправдана. Но в сумме получается грязновато.

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

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

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

Его же никто не проектировал:( Tcl это классика базарной разработки. Изначально он состоял из маленького рантайма позволяющий добавлять команды без закапывания в глубины исходников и нескольких базовых команд для демонстрации идеи. Остальное уже от «базара». Большинство нынешних команд это написанное левой пяткой под чьи-то собственные нужды:) И еще множество команд не вошли в коробочную поставку и о них мало кто помнит:(

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

C точки зрения концепции он unix-way в чистом виде: простые, независимые программы/команды и текстовый протокол обмена. А строка как обобощающий тип данных растет из бедности типов в С.Так удобнее отлаживать и чуть меньше кода если жить в консоли. Поэтому и ограничения здесь ровно такие, чтобы легко кодить это на нем.
Изначально автор хотел шелл который можно встроить в «жирный» софт, поэтому до мелочей повторил особенности изначальной командной оболочки юникса.А сама концепция команд точное подражание лисп-машинам.

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

Это вроде похоже на правду - в лиспе есть отдельно функции и отдельно макросы,

Автор picolisp написал целую статью о том что макросы лиспа это часть компилятора. А в интерпретаре они не нужны. Picolisp обходится без них, хотя МП в нем есть и сильно отличается от unix-измов шелла.

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

поведение {} сложно, они ни в коем случае не столь же надёжны, как () в лиспе. Причём аналога лисповых () в тикле просто-напросто нет, как нет и механизма сериализации/десериализации через print/read. Казалось бы, если строки столь фундаментальны, то должно существовать нечто аналогичное паре print/read, но это либо не так, либо не столь явно (надо подумать, в чём именно тут проблема).

Для того что бы они существовали нужны списки как структура данных. Которых в С нет. А значит нужно добавлять либо GC как в лиспе, либоы вывод типов как в ML. Для изначального Tool Command Language это все было слишком сложно и противоречило духу «простого» С.

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

Tcl это классика базарной разработки.

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

Для того что бы они существовали нужны списки как структура данных.

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

Стал думать - а насколько хороша та инфраструктура, к-рую тикль создаёт для DSL? Она, по сути, заключается в том, как он разбивает строку на слова. И тут я обнаружил такой, на мой взгляд, косяк.

puts "}"
==> }
if 1 { puts "}" }
==> extra characters after close-brace

Автор picolisp написал целую статью о том что макросы лиспа это часть компилятора. А в интерпретаре они не нужны

При наличии других механизмов, типа eval - в принципе, да. Или fexpr-ов.

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

А строка как обобощающий тип данных растет из бедности типов в С

Не. Это великая идея. Токенизация предельно, экстремально проста (если не считать косяков, вызванных вот этой вот шелло-подобной логикой). Почему великая? Потому что крайне трудно или практически невозможно заложить в язык форматы данных, удобные для всех задач. У CL есть такая проблема. Что вернут эти два выражения?

(type-of 1.2)
(symbolp 'a)
Первое выражение может вернуть single-float или double-float, в зависимости от контекста в процессе чтения. Второе может вернуть истину или ложь в зависимости от контекста чтения - «а» может оказаться числом 10, если включена 16-ричная система счисления при чтении. Лисп расширяем, и после Си кажется, что он офигенно гибкий в плане определения собственных форматов данных. Кажется, что можно почти всё. Но тикль - это следующий огромны шаг в направлении увеличения гибкости. Эта огромность следует осознания тех просторов, в которые попала нога.

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

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

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

Или всё же при тщательном дизайне теряется нечто непонятое, но существенное, что даёт языку реальное качество?

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

https://en.wikipedia.org/wiki/Scott_Fahlman

I'm sure each of us could design a better language than Common Lisp is turning out to be, and that each of those languages would be different. My taste is close to RPG's, I think: in general, I like primitives that I can build with better than generalizations that I can specialize. However, Common Lisp is politics, not art. If we can come up with a single language that we can all live with and use for real work, then we will have accomplished a lot more than if we had individually gone off an implemented N perfect Lisp systems.

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

Для тикля не обязательно списки, можно и вложенные массивы.

Даже вычитывание одномерного массива в argv требует некоторых усилий на «тупом» С. Вложенные массивы аналогичны или даже сложнее списков:( Это я про бедность C на структуры данных. А сложная структура сделала бы подключение новых команд не настолько простым. Это простота основной смысл рождения Tcl.

И тут я обнаружил такой, на мой взгляд, косяк.

puts "\}"
==> }
if 1 { puts "\}" }
==> }

Управляющие последовательности надо экранировать. А про то что нельзя смешивать незакрытые \{ и \" где-то в глубинах доки сказано отдельно:)

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

Потому что крайне трудно или практически невозможно заложить в язык форматы данных, удобные для всех задач. У CL есть такая проблема. Что вернут эти два выражения?

Нельзя его сравнивать с Tcl напрямую, они по задачам разные. Если хочется смотреть как невыразимые типы реализуются в лиспе с помощью МП, то в picolisp зашиты оба подхода. Там у него на сайте и книжка есть в упорядоченном изложении

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

Но тикль - это следующий огромны шаг в направлении увеличения гибкости.

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

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

Толку то с этой гибкости

Можно разделить два вопроса - о том, как устроена эта гибкость, и о том, каков с неё толк.

den73 ★★★★★
() автор топика

Вразумите еретика!

Вам в церковь!!!

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

Базар - это метафора того что люди пытаются понять интересы друг друга.

Т.е. ввиду отсутствия ресурсов разработчик поступается качеством и принимает более-менее любую хрень от тех, кого хочет привлечь/боится обидеть отказом? Если так, то негативный смысл слова остаётся.

puts «\}»

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

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

Если хочется смотреть как невыразимые типы реализуются в лиспе с помощью МП

Можно более конкретное место?

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

Нельзя его сравнивать с Tcl напрямую, они по задачам разные

Я думаю, что вполне даже можно. Одно дело, какие задачи имелись в виду изначально, и другое - какие в итоге оказалось возможным решить.

den73 ★★★★★
() автор топика

Вообще забавно, неужели tcl тоже секта? «Всё есть строка» - на первом уровне. Но на втором оказывается, что есть строка и handle. Который на самом деле есть не объект, а лишь его идентификатор. Попробуйте выкинуть из тикля хендлы - и ничего не останется. Поскольку хендлами являются переменные, команды, потоки ввода-вывода, а в tk - виджеты. Теперь я читаю про

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

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

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

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

люди пытаются понять интересы друг друга <=> разработчик поступается качеством и принимает более-менее любую хрень - как одно из другого выросло?

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

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

Можно более конкретное место?

Как до дома доберусь

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

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

Лисперы привыкают к скобкам, програмисты на шелле к экранированию всякой всячины:)

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

Вопрос в том, как устроен процесс. Допустим, Оустерхаут придумал тикль 1.0. Пришёл Вася и сказал: я написал вот такое расширение, возьми его в тикль. Далее варианты

A. Оустерхаут говорит: твоё расширение не соответствует моей вере, иди лесом. Он теряет соратника.

Б. Оустерхаут говорит: твоё расширение не соответствует моей вере, но если его переделать, то может быть и подойдёт. Далее по обстоятельствам, но можно потерять соратника тоже, и ресурсов прямо сейчас нужно больше.

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

Вот по этой оси А-Б-В и происходит компромисс качество - учёт интересов сообщества.

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

Ещё понял, что возможность иметь строку без кавычек тесно связана с тем, что вычисление происходит с помощью явного префикса $. В лиспе, если мы уравняем по написанию «символ» и просто символ без кавычек, то в коде (print символ) мы не сможем узнать, нужно ли взять значение символа с именем «символ», или просто напечатать слово «символ». Это, вообще-то, очевидно :)

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

Теперь я утверждаюсь в мысли, что tcl был плохо продуман.

Столлману это было очевидно ещё во время срачей «tcl wars»

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

Я думаю, нападки Столлмана были в основном из-за политики (лицензия не та). По сути-то, на tcl/tk можно вполне делать нормальные кросс-платформенные программы с гуем. Ни CL, ни EMACS lisp этим похвастаться не могут, и вообще лисп сдулся. С другой стороны, bash, который я не вижу чем лучше тикля, никуда не делся, и на нём много всего нужного понаписано. Так что Столлман неясно чего добился своей политикой.

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

Не мог. Подумай, почему ни один shell на базе лиспов не стал популярен.

почему? мне непонятно. раскрой тему.

вот например в Inferno sh или в plan9 rc имеет дополнительный тип: список. например, в plan9 PATH это не строка как список :-separated, а нормальный список.

Inferno sh кстати, расширяется tk. получаем tcl/tk без tcl.

в ksh и cde было кстати тоже нечто подобное (про это написано в мануалах gtkserver)

дальнейшим развитием rc/sh является es и его дальнеший форк на С++, xs

из примеров на es: (няшный конфиг рассадник)

adventure.es

в духе текстовых адвентюр типа Zork, MUD-ов, Dungeon из Emacs-а

написан шелл с директориями-комнатами и файлами-монстрами.

вот оно: простое изменение и нормально реализованные списки. и в итоге — лямбды и функции высшего порядка в шелле, нормальная составимость функций, макросы.

значит, можно же реализовать шелл по нормальному, «всё есть список» а не «всё есть строка»

кстати, где там saahriktu. ссылка для него: flask-gopher — gopher-сервер на Python и сервере приложений Flask, отодранный от FastCGI. MOOGopher.pdf оттуда — публикация про гофер-клиент в стиле MUD, реализованный в MOO среде:

>look at gopher slate

The look at command lets you examine objects:

Gopher Slate
1. The U of I Weather Machine <menu>
2. Electronic Frontier Foundation archives <menu>
3. parcftp MOO anonymous FTP information <menu>
4. Gopher sites for biology <menu>
5. Movie reviews <menu>
6. Mankato State University <menu>
7. MSEN inc <menu>
The gopher slate looks like it has a familiar Gopher
menu on it

>pick 2 on slate

Now choose a menu item:
You pick 2. About the Electronic Frontier
Foundation on Gopher Slate:


General Information about the Electronic
Frontier Foundation

The Electronic Frontier Foundation "EFF" was
founded in July...... to assure freedom of
expression in digital media with a
particular emphasis on applying the
principles embodied in the Constitution and
the Bill of Rights to computer
based
communication

-1- of -24-

 'next on Gopher Slate' for more 
anonymous
()
Ответ на: комментарий от den73

не, rms и tla (Tom Lord, аффтар Arch VCS) тогда продвигали схему Guile вместо tcl. и примерно с той же поры велись разговоры как бы elisp в емаксе заменить на правильную guile, примерно с таким же, 0 результатом :)

С другой стороны, bash, который я не вижу чем лучше тикля, никуда не делся, и на нём много всего нужного понаписано.

ага, например крестики-нолики на gtkserver. или встроеный GUI в ksh в CDE.

чего ещё на нём такого нужного понаписано?

вообще вместо bash/gmake/gcc вполне можно было бы заменить тулчейн на rc/mk или redo/kencc или какой-нибудь rexx/rebol вместо шелла.

тот же sh из Inferno со встроенным tk побогаче bash будет.

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

Adventure shell

1. на bash

2. на es

второе гораздо легче читается, потому что списки нормальные и let over lambda.

XS для лисперов — от этого один шаг до какой-нибудь простенькой схемы на таком вот, нормальном шелле.

осталось туда в духе Inferno sh воткнуть tk. а, кажется в исходниках примеров Inferno где-то и есть лисп на sh.

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

осталось туда в духе Inferno sh воткнуть tk. а, кажется в исходниках примеров Inferno где-то и есть лисп на sh.

у caerwinа

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

почему? мне непонятно. раскрой тему.

Потому что UNIX и текстовые данные. Список в любом shell должен нормально воспринимать как список результат ls, find, grep и иметь возможность отправить свой список в качестве аргумента к echo

При попытке использовать лисп получаем кучу мусорных вызовов car/list для преобразования элемент/список из одного элемента. А для оболочки важна лаконичность. Кстати, по этой же причине нет ни одной распространённой оболочки со статической типизацией.

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

Ссылка «на es» неправильная.

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

configure.es стал бы гораздо более человекочитаемый, кабы автолулзы поправить :) впрочем, пофиг.

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

пожалуйста

смоллтокоподобное TctkD

да, двойные кавычки в tcl ведут себя странно :)

$ tclsh8.5
% proc "" {x} {expr {$x * $x}}; "" 5
25
% rename "" ""                ; "" 5
ambiguous command name "": after append apply array auto_execok auto_import auto_load auto_load_index auto_qualify binary break case catch cd chan clock close concat continue dict encoding eof error eval exec exit expr fblocked fconfigure fcopy file fileevent flush for foreach format gets glob global history if incr info interp join lappend lassign lindex linsert list llength load lrange lrepeat lreplace lreverse lsearch lset lsort namespace open package pid proc puts pwd read regexp regsub rename return scan seek set socket source split string subst switch tclLog tell time trace unknown unload unset update uplevel upvar variable vwait while
%
anonymous
()
Ответ на: комментарий от den73

Я думаю, нападки Столлмана были в основном из-за политики (лицензия не та).

Richard Stallman Fri, 23 Sep 94 19:14:52 -0400

Tcl was not designed to be a serious programming language ... It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow.

Some people plan to use Tcl because they want to use Tk. Thankfully, it is possible to use Tk without Tcl. A Scheme interpreter called STk is already available. Please, if you want to use Tk, use it with STk, not with Tcl.


https://vanderburg.org/old_pages/Tcl/war/0000.html

По сути-то, на tcl/tk можно вполне делать нормальные кросс-платформенные программы с гуем.

В 94-ом Tk был по сути бесплатным эстетическим ужасом, но кросплатформенным, да:( Его только к нулевым подтянули до условно съедобного.

С другой стороны, bash, который я не вижу чем лучше тикля, никуда не делся, и на нём много всего нужного понаписано.

он был legacy как dos в win9x. То что он пережил лиспы шутка истории.

Так что Столлман неясно чего добился своей политикой.

Столман ратовал за замкнутую экосистему GNU. Он ее и получил:( А Оустерхаут за несколько месяцев до этого стал почетным работником работником SUN, чем вызвал в сообществе раскол и брожение.

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