Re: TCL list substitution
On 2008.10.03 at 13:41:45 +0300, Serhiy Storchaka wrote: Вот это было нужно делать с самого начала, уже при разработке языка. В тикле ведь та же самая проблема, что обсуждалась выше (для шелла). Из-за того, что eval и подобные делают concat своим аргументам перед парсингом. В результате простые примеры прокатывабт и так, а что-то посложнее и понадёжнее - приходится в [list ...] заворачивать. Она гораздо менее актуальна, так как всегда строго известно сколько раундов подстановки будет. В shell это гораздо сложнее предсказать. Кстати, одна из базовы синтаксических конструкций лишняя. Variable substitution. Можно было бы для большей однородности использовать синтаксис command substitution, считая переменные командами, возвращающими своё значение (как в Forth-е для констант). Ну, это несколько осложнило бы жизнь. Все-таки запомнить правила, где переменные это переменные, а команды - это команды проще, чем правила, где переменные и команды это одно и тоже. Хотя на lisp люди пишут. Tcl это некоторый компромисс между математической строгостью Lisp и плохо формализованным мышлением типичного студента CS. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCL list substitution
Нужно было или сразу запретить простые конструкции, провоцирующие ошибки, Что-то тихо стало 8-) Еще одна тема на погудеть. Предлагаю запретить еще вот эту простую конструкцию. tmpfn=get_temp_file_NAME ... get_data $tmpfn Ясное дело конструкция внеязыковая. Исходная позиция: объяснить ВСЕМ программирующим опастность этой конструкции не представляется возможным. Выводы (предложения) ниже. Варианта предлагаю два: 1) Запретить программирование под систему UNIX с общим /tmp наотрез под страхом остаться без еды и питья 2) Сделать таки per-process (per process group или per session) автономные виртуальные персональные /tmp. Ввиду очевидной маргинальности пункта 1) думаю, можно остановиться на варианте 2) :-) -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCL list substitution
Victor Wagner - debian-russian@lists.debian.org @ Fri, 3 Oct 2008 15:40:57
+0400:
Кстати, одна из базовы синтаксических конструкций лишняя. Variable
substitution. Можно было бы для большей однородности использовать
синтаксис command substitution, считая переменные командами,
возвращающими своё значение (как в Forth-е для констант).
VW Ну, это несколько осложнило бы жизнь. Все-таки запомнить правила,
VW где переменные это переменные, а команды - это команды проще, чем
VW правила, где переменные и команды это одно и тоже. Хотя на lisp
VW люди пишут.
На lisp они как раз различаются. Одно и то же они только в Scheme.
VW Tcl это некоторый компромисс между математической строгостью Lisp и
VW плохо формализованным мышлением типичного студента CS.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Пришел в гости математик, почитать новую рукопись. Вычитал из нее трех
героев напрочь, и ушел.
Gimli on #arda
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCL list substitution
Victor Wagner - debian-russian@lists.debian.org @ Fri, 3 Oct 2008 15:40:57 +0400: Кстати, одна из базовы синтаксических конструкций лишняя. Variable substitution. Можно было бы для большей однородности использовать синтаксис command substitution, считая переменные командами, возвращающими своё значение (как в Forth-е для констант). VW Ну, это несколько осложнило бы жизнь. Все-таки запомнить правила, VW где переменные это переменные, а команды - это команды проще, чем VW правила, где переменные и команды это одно и тоже. Хотя на lisp VW люди пишут. На lisp они как раз различаются. Одно и то же они только в Scheme. Что-то ты мутишь. И в лиспе и в схеме программы (команды) - first class value. Команды от данных отличаются только контекстом использования, и в лиспе и схеме. -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCL list substitution
Hello! В сообщении от Friday 03 October 2008 14:41:45 Serhiy Storchaka написал(а): В тикле ведь та же самая проблема, что обсуждалась выше (для шелла). Из-за того, что eval и подобные делают concat своим аргументам перед парсингом. В результате простые примеры прокатывабт и так, а что-то посложнее и понадёжнее - приходится в [list ...] заворачивать. А кто вам мешает все в [list ] завернуть? Выберите стиль программирования, какой нравится. Или eval переопределить. Best regards, Alexey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCL list substitution
Aleksey Cheusov - debian-russian@lists.debian.org @ Fri, 03 Oct 2008 16:33:11
+0300:
Кстати, одна из базовы синтаксических конструкций лишняя. Variable
substitution. Можно было бы для большей однородности использовать
синтаксис command substitution, считая переменные командами,
возвращающими своё значение (как в Forth-е для констант).
VW Ну, это несколько осложнило бы жизнь. Все-таки запомнить правила,
VW где переменные это переменные, а команды - это команды проще, чем
VW правила, где переменные и команды это одно и тоже. Хотя на lisp
VW люди пишут.
На lisp они как раз различаются. Одно и то же они только в Scheme.
AC Что-то ты мутишь. И в лиспе и в схеме программы (команды) - first
AC class value. Команды от данных отличаются только контекстом
AC использования, и в лиспе и схеме.
В лиспе - нет. Попробуй передать car как переменную... Там они
синтаксически разделены, и там возможно у одного символа иметь два
совершенно значения - для использования как команды и как переменной.
При этом в переменной может содержаться функция, но способ ее вызова
синтаксически отличается от способа вызова той функции, которая value
as function. А вот в схеме синтаксис общий, и значение ровно одно.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Он был новичком в Париже, а не в фехтовании.
Alexander Mozhaev в [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCL list substitution
Victor Wagner wrote: On 2008.10.03 at 13:41:45 +0300, Serhiy Storchaka wrote: Вот это было нужно делать с самого начала, уже при разработке языка. В тикле ведь та же самая проблема, что обсуждалась выше (для шелла). Из-за того, что eval и подобные делают concat своим аргументам перед парсингом. В результате простые примеры прокатывабт и так, а что-то посложнее и понадёжнее - приходится в [list ...] заворачивать. Она гораздо менее актуальна, так как всегда строго известно сколько раундов подстановки будет. В shell это гораздо сложнее предсказать. Но всё равно проблема есть. Проблема не в том, что подстановка будет выполнена не там, а что парсинг идёт уже после текстовой подстановки. Кстати, одна из базовы синтаксических конструкций лишняя. Variable substitution. Можно было бы для большей однородности использовать синтаксис command substitution, считая переменные командами, возвращающими своё значение (как в Forth-е для констант). Ну, это несколько осложнило бы жизнь. Все-таки запомнить правила, где переменные это переменные, а команды - это команды проще, чем правила, где переменные и команды это одно и тоже. Хотя на lisp люди пишут. Запомнить одну сущность проще, чем две. Кстати в тикле ведь уже есть несколько стандартных ?псевдопеременных?, синтаксис получения значения которых как у переменных, но значение меняется независимо от пользователя. Ведь это по сути системные команды. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCL list substitution
Alexey Pechnikov wrote: В сообщении от Friday 03 October 2008 14:41:45 Serhiy Storchaka написал(а): В тикле ведь та же самая проблема, что обсуждалась выше (для шелла). Из-за того, что eval и подобные делают concat своим аргументам перед парсингом. В результате простые примеры прокатывабт и так, а что-то посложнее и понадёжнее - приходится в [list ...] заворачивать. А кто вам мешает все в [list ] завернуть? Выберите стиль программирования, какой нравится. Или eval переопределить. Ничего. Но если _все_ авторы специально подчёркивают, что нужно _всегда_ заворачивать аргументы явно в список (даже если для данного конкретного случая не нужно, окажется необходимым при следующей правке), если каждое употребление eval (и всех подобных команд) требует list, то может ошибка в дизайне? Может стоит сразу включить list в eval (а вернее исключить concat из него)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCL list substitution
Hello! В сообщении от Friday 03 October 2008 23:27:51 Serhiy Storchaka написал(а): А кто вам мешает все в [list ] завернуть? Выберите стиль программирования, какой нравится. Или eval переопределить. Ничего. Но если _все_ авторы специально подчёркивают, что нужно _всегда_ заворачивать аргументы явно в список (даже если для данного конкретного случая не нужно, окажется необходимым при следующей правке), если каждое употребление eval (и всех подобных команд) требует list, то может ошибка в дизайне? Может стоит сразу включить list в eval (а вернее исключить concat из него)? В большинстве случаев как раз list не нужен. Иногда нужен, да, но тогда его как раз не проблема явно указать. Это я к тому, что простые случаи составляют подавляющее большинство. Но было бы не удобно при необходимости передать строку с параметрами писать split для превращения этой строки в список. Вот есть полученная откуда-либо строка параметров puts $params -val1 value -val2 value2 Сейчас она подставляется без проблем. Правда, это противоречит идеологии все есть список. И с точки зрения безопасности возможны проблемы. Best regards, Alexey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
