Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, AndreyFedotov, Вы писали:
AF>> На мой взгляд...
СГ>Дело вкуса и предпочтений — форматирование текста. В остальном же — нельзя полагаться на абстрактные нравится/не нравится, а надо использовать то что наиболее подходит для формального описания/определения/вывода/заключений.
Сергей. Во-первых ты забыл добавить "по моему скромному мнению"
Во-вторых кому надо — пусть тот и используюсь. Я же присоеденяюсь к тем, кому больше нравятся красивые девушки, марочное вино и по человечески написанные, легко читаемые и простые для понимания программы. К сачтью и большой моей радости здесь таких большинство.
Твоя точка зрения про то, что формализмом можно подменить здравый смысл, интуицию, чувство вкуса и меры широко известна. Отчасти мне понятно, чего ты добиваешься. Однако я уже выразил свою точку зрения
по этому поводу и предупредил — чем это может кончится.
Ты можешь прислушаться к чужим мнениям и что то поменять в своём поведении, тогда нам будет о чём поговорить, а можешь продолжать и дожидаться Влада с веслом
PS. Если хочешь, что бы было что обсудить — скажи прямо, чего ты хочешь.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, AVC, Вы писали:
AVC>>Некоторые современные английские языковеды полагают, что в английской грамматике нет будущего времени. AVC>>Например, Geoffrey Broughton: AVC>>
AVC>>Modern grammars argues that modern English... has present and past tenses, (i.e. verb forms which reflect these meanings of time) but no future tense.
AVC>>("Penguin English grammar") AVC>>Глаголы shall и will грамматически принадлежат к present tense и — ничего, справляемся мы с этим как-то...
Д>Я подозреваю, что некоторым современным английским языковедам заняться больше нечем. Хорошо хоть, оверхед считать не начали
Этим ещё Шеннон увлекался. Современным достался уже посчитанный.
Н.В.: Мы должно осторожно употреблять такие термины, как "читаемость", "дружественность к пользователю" и им подобные. В лучшем случае, они туманны и часто ссылаются на такие плохо определенные сущности, как вкусы и установившиеся привычки. Но то, что общепринято, отнюдь не обязательно действительно так уж удобно. В контексте языков программирования, возможно "удобочитаемый" (readable) следует заменить на "подходящий для формальных умозаключений" (formal reasoning). Например, математические формулы едва ли могут удостоиться похвал как легко прочитываемые, но они позволяют выполнять формальный вывод свойств, которые в принципе не могут быть получены из туманных, нечетких, неформальных, "дружественных к пользователю" описаний.
AF>PS. Если хочешь, что бы было что обсудить — скажи прямо, чего ты хочешь.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Н.В.: Мы должно осторожно употреблять такие термины, как "читаемость", "дружественность к пользователю" и им подобные. В лучшем случае, они туманны и часто ссылаются на такие плохо определенные сущности, как вкусы и установившиеся привычки. Но то, что общепринято, отнюдь не обязательно действительно так уж удобно. В контексте языков программирования, возможно "удобочитаемый" (readable) следует заменить на "подходящий для формальных умозаключений" (formal reasoning). Например, математические формулы едва ли могут удостоиться похвал как легко прочитываемые, но они позволяют выполнять формальный вывод свойств, которые в принципе не могут быть получены из туманных, нечетких, неформальных, "дружественных к пользователю" описаний. СГ>[/q]
Сначала подменили читаемость на "дружественность к пользователю", а потом и на "туманных, нечетких, неформальных описаний", после чего разгромили их в пух и прах. Сплошная болтология.
Кстати говоря, как раз общепринятый синтаксис математических формул — это яркий пример "вкусов" и "устоявшихся привычек", и уж в LL(1) он точно не укладывается.
Здравствуйте, Сергей Губанов, Вы писали:
AF>>Сергей. Во-первых ты забыл добавить "по моему скромному мнению"
СГ>А Вы точно уверены, что я "забыл" добавить только своё ИМХО?
СГ>http://www.osp.ru/os/1998/01/41_print.htm СГ>
СГ>Н.В.: Мы должно осторожно употреблять такие термины, как "читаемость", "дружественность к пользователю" и им подобные. В лучшем случае, они туманны и часто ссылаются на такие плохо определенные сущности, как вкусы и установившиеся привычки. Но то, что общепринято, отнюдь не обязательно действительно так уж удобно. В контексте языков программирования, возможно "удобочитаемый" (readable) следует заменить на "подходящий для формальных умозаключений" (formal reasoning). Например, математические формулы едва ли могут удостоиться похвал как легко прочитываемые, но они позволяют выполнять формальный вывод свойств, которые в принципе не могут быть получены из туманных, нечетких, неформальных, "дружественных к пользователю" описаний.
Тогда может быть где-то есть ссылка с объяснением того, что сейчас языки с C-подобным синтаксисом по популярности и распространенности давно заткнули за пояс Pascal-подобные языки (мое жирное ИМХО). Да и феномен распространенности Perl-а так же не мешало бы раскрыть (не смотря на его синтаксис).
А по поводу высказывания Вирта лично у меня есть одно возражение -- сравнивать код программы и математические формулы (и их удобство воспрятия) можно было бы, если бы математикам приходилось написать за месяц формулу в 3-5 тысяч строк. Да не просто написать, а еще и добится того, чтобы она приводила к правильным вычислениям.
AF>>PS. Если хочешь, что бы было что обсудить — скажи прямо, чего ты хочешь.
СГ>Горы хлеба и бездну могущества
-- О, новенький! И кто мы у нас?
-- Я -- Наполеон!
-- А, ну тогда в шестую палату его. Там у нас и Наполеоны, и Суворовы, и Кутузовы...
-- Доктор, вы меня не поняли! Я -- торт Наполеон!
По существу: Сергей, можно ли получить нормальное объяснение цели, на которую ты намекал (Re[3]: Не верю
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, jazzer, Вы писали:
J>>>2) параноидальной честностью
VD>>Круто! Надо будет запомнить. :))
Ш>А лучше почитать что-нибудь.
Ш>здесь
К сожалению, долгая история того, как люди учились не дурачить сами себя и руководствоваться полнейшей научной честностью, не включена ни в один известный мне курс. Мы надеемся, что вы усвоили ее из самого духа науки.
СГ>Н.В.: Мы должно осторожно употреблять такие термины, как "читаемость", "дружественность к пользователю" и им подобные. В лучшем случае, они туманны и часто ссылаются на такие плохо определенные сущности, как вкусы и установившиеся привычки. Но то, что общепринято, отнюдь не обязательно действительно так уж удобно. В контексте языков программирования, возможно "удобочитаемый" (readable) следует заменить на "подходящий для формальных умозаключений" (formal reasoning). Например, математические формулы едва ли могут удостоиться похвал как легко прочитываемые, но они позволяют выполнять формальный вывод свойств, которые в принципе не могут быть получены из туманных, нечетких, неформальных, "дружественных к пользователю" описаний.
Посмотри на эту тему в одной из параллельных веток. Запись математических формул обсуждалась, например,здесь
AF>> Спроси себя — зачем ты затеваешь все эти дискуссии?
E>Ответ на этот вопрос мне известен точно. Практически все затеянные мной дискуссии на этом форуме имеют одну определённую цель.
Это же очевидно — поиск единомышленников. RSDN — место довольно людное, так что "ищу где светло, а не там где потерял". В принципе, не исключено что толку от этого столько же сколько от занятия ловли рыбы в унитазе. Вода есть, удочка тоже и прикармливал регулярно, а не клюет...
Мне вот пришла в голову идея -- а что, если сделать оценки "интересно", "спасибо", "супер" отрицательными? За такой ответ Сергея я бы "минус супер" с удовольствием поставил бы. А то один минус -- это как-то маловато.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Сергей. Во-первых ты забыл добавить "по моему скромному мнению"
СГ>А Вы точно уверены, что я "забыл" добавить только своё ИМХО?
Да забыл. То, что с тобой согласен кто-то ещё, сути дела не меняет. Твоё мнение всё равно остаётся мнением и истиной от этого не становится.
СГ>http://www.osp.ru/os/1998/01/41_print.htm СГ>
СГ>Н.В.: Мы должны осторожно употреблять такие термины, как "читаемость", "дружественность к пользователю" и им подобные. В лучшем случае, они туманны и часто ссылаются на такие плохо определенные сущности, как вкусы и установившиеся привычки. Но то, что общепринято, отнюдь не обязательно действительно так уж удобно. В контексте языков программирования, возможно "удобочитаемый" (readable) следует заменить на "подходящий для формальных умозаключений" (formal reasoning). Например, математические формулы едва ли могут удостоиться похвал как легко прочитываемые, но они позволяют выполнять формальный вывод свойств, которые в принципе не могут быть получены из туманных, нечетких, неформальных, "дружественных к пользователю" описаний.
И что? Ты внимательно читал? Не ужели не очевидна разница между "должны осторожно" и "не должны"? Уж если твой кумир говорит о том всё-таки должны пользоваться, только осторожно — не повод ли это задуматься?
Подозреваю, что с тем, что любые субъективные понятия или сравнения — такие как ясно, легко, удобно, читаемо, красиво и т.д. нужно использовать
аккуратно, т.к. то, что легко для первого сейчас, вовсе может быть не легко для второго, а то и самого же первого спустя некоторое время. Это, по-моему, естественно и очевидно. Но тем не менее это ни повод вообще перестать субъективно сравнивать или оценивать и заменить всё это кандовым формализмом.
Тем паче, что уж если что у Вирта и вызывает интерес — то только не синтаксис его творений.
AF>>PS. Если хочешь, что бы было что обсудить — скажи прямо, чего ты хочешь.
СГ>Горы хлеба и бездну могущества
Прекрасно! Ты уже нашёл единомышленника! (Боюсь правда что заодно и товарища по палате, но такова она — трудная судьба наполеонов )
, с моей точки зрения, и есть корень твоих сложностей, Сергей.
Ты пытаешься искать единомышленников среди людей, к которым относишься высокомерно и, судя по твоим заявлениям, презираешь. Удивительно ли, что ты их не нашёл?
Кодт,
>>> Другое дело, что есть неоднозначность в: >>>
>>> A<B, C>(В)
>>> A < B, C > (В)
>>>
>>> Которая в шарпе решается введением эвристики.
> ПК>Именно о подобных неоднозначностях и идет речь. Они в Шарпе разрешаются способом, недоступным LL(1) парсеру.
> Угловые скобки требуют знания контекста. Если перед '<' имя шаблона, то это скобка (и нужно искать ей пару), а если что-либо другое, то это двухместный оператор. А для этого нужно либо делать контекстную зависимость, либо явно писать кейворд template.
Это в C++. Там грамматика из-за этого вообще становится КЗ, если пытаться устранить неоднозначность непосредственно в ней. В C# принято другое решение данной неоднозначности. Там просто нужен просмотр вперед: если в неоднозначной конструкции после "закрывающей" > идет ( ) ] : ; , . ? == или !=, то < ... > считается аргументами generic, иначе -- нет. Например:
F(G<A, B>(7));
Всегда (независимо от определений F, G, A и B) будет рассматриваться как вызов F с одним аргументом, вызовом generic G с двумя аргументами типа и одним обычным аргументом. Чтобы результатом был вызов функции с двумя аргументами, (G < A) и (B < (7)), в C# нужно изменить синтаксис, и тогда результат разбора тоже от контекста (определений F, G, A и B) зависеть не будет:
F(G<A, (B>(7)));
F((G<A), B>(7));
F(G<A, B>7);
Т.е. в C# вроде бы можно внести разрешение данной неоднозначности непосредственно в грамматику, усложнив ее, но оставив ее КС, но из-за необходимости заглядывания вперед более чем на один токен грамматика LL(1) уже не будет (правда, там она LL(1) не была и без этого из-за других конструкций, вызванных объявлениями в духе C, где тип предшествует определяемой сущности).
> Кстати о синтаксисе шаблонов... > Пусть у нас есть скобочные выражения > — { РазныеСтейтменты } > — ( ВыражениеВСкобках ) > — Функтор ( СписокАргументов ), причём доступ к массиву синтаксически такой же, как функтор (аналогично VB и Fortran'у)
Упс. Любая синтаксическая неоднозначность делает грамматику не LL(1).
> — Шаблон [ СписокПараметров ] > Казалось бы, получаем LL(1). > Или там ещё есть подводные камни?
См. выше или я чего-то недопонял в твоем предложении.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Угловые скобки требуют знания контекста. Если перед '<' имя шаблона, то это скобка (и нужно искать ей пару), а если что-либо другое, то это двухместный оператор. А для этого нужно либо делать контекстную зависимость, либо явно писать кейворд template.
ПК>Это в C++. Там грамматика из-за этого вообще становится КЗ, если пытаться устранить неоднозначность непосредственно в ней. В C# принято другое решение данной неоднозначности. Там просто нужен просмотр вперед: если в неоднозначной конструкции после "закрывающей" > идет ( ) ] : ; , . ? == или !=, то < ... > считается аргументами generic, иначе -- нет.
< пример покоцан > ПК>Т.е. в C# вроде бы можно внести разрешение данной неоднозначности непосредственно в грамматику, усложнив ее, но оставив ее КС, но из-за необходимости заглядывания вперед более чем на один токен грамматика LL(1) уже не будет (правда, там она LL(1) не была и без этого из-за других конструкций, вызванных объявлениями в духе C, где тип предшествует определяемой сущности).
Затейливо. Получается, что неоднозначность вида f<g>(h) — то ли сравнение (f<g)>(h) то ли шаблон (f<g>)(h) — трактуется в пользу шаблона.
Головнячок для программистов
>> Кстати о синтаксисе шаблонов... >> Пусть у нас есть скобочные выражения >> — { РазныеСтейтменты } >> — ( ВыражениеВСкобках ) >> — Функтор ( СписокАргументов ), причём доступ к массиву синтаксически такой же, как функтор (аналогично VB и Fortran'у)
ПК>Упс. Любая синтаксическая неоднозначность делает грамматику не LL(1).
Где здесь неоднозначность? Скобки вокруг выражения versus вокруг списка аргументов? Эта же задача возникает в парсере мат.выражений...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Горы хлеба и бездну могущества
[задумчиво]
А зачем нужны горы хлеба если есть бездна могущества?
[/задумчиво]
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Кодт,
> Затейливо. Получается, что неоднозначность вида f<g>(h) — то ли сравнение (f<g)>(h) то ли шаблон (f<g>)(h) — трактуется в пользу шаблона. Головнячок для программистов
+1
>>> — Функтор ( СписокАргументов ), причём доступ к массиву синтаксически такой же, как функтор (аналогично VB и Fortran'у)
> ПК>Упс. Любая синтаксическая неоднозначность делает грамматику не LL(1).
> Где здесь неоднозначность? Скобки вокруг выражения versus вокруг списка аргументов?
Доступ к элементу массива vs. вызов функции. Можно, правда, попробовать "отбиться", если не вводить в грамматику оба нетерминала "вызов-функции" и "доступ-к-элементу-массива", а ограничиться одним "функтор" (может, ты об этом и говорил?). В этом случае тоже будут вопросы, но они уже будут зависеть от конкретики языка: в каких выражениях могут встречаться типы, функции и массивы; что из этого может быть шаблонами; где могут встречаться объявления, и где -- выражения, и всегда ли их можно будет отличить друг от друга и т.п.
> Эта же задача возникает в парсере мат.выражений...
Там такой неоднозначности нет, т.к. скобка после идентификатора может и должна присутствовать только в случае вызова функции. Т.е. просмотра на одну лексему вперед достаточно, чтобы понять, что перед нами -- вызов функции.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Горы хлеба и бездну могущества WH>[задумчиво] WH>А зачем нужны горы хлеба если есть бездна могущества? WH>[/задумчиво]
Сергей,
>>> А почему Вы думаете, что использование более сложной грамматики чем LL(1) добавит выразительности?
> ПК>Потому что впихнуть в прокрустово ложе LL(1) ряд возможностей, добавляющих языку выразительности, не так уж легко. Например, попробуй добавить в Оберон удобные для использования шаблоны (или хотя бы generics), оставив грамматику LL(1)...
> 7. Parametric Types > http://cvs.sourceforge.net/viewcvs.py/*checkout*/ooc/ooc2/doc/from-v1-to-v2/oo2c-v2.html#SEC19 > > Еще вопросы?
Безусловно. Я так и не увидел впихивания этого добра в LL(1)-грамматику. По ссылке выше приведен фрагмент грамматики. Если считать, что это модификация оригинальной грамматики Oberon-2 из соответствующего Report, то это не LL(1), т.к. оригинальная грамматика в том виде, как она приведена в Oberon-2 Report тоже LL(1) не является. Если же речь идет о модификации какой-то другой грамматики, то приведи, пожалуйста, полную грамматику, включающую параметризованные типы, т.к. по ссылке, приведенной тобой выше, я такой полной грамматики не нашел.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Дарней, Вы писали:
Д>Я подозреваю, что некоторым современным английским языковедам заняться больше нечем. Хорошо хоть, оверхед считать не начали
Точно. Уволить их всех.
Но смысл был в том, что future time вполне можно выразить и без future tense.
Например:
I am leaving tomorrow.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Безусловно. Я так и не увидел впихивания этого добра в LL(1)-грамматику. По ссылке выше приведен фрагмент грамматики. Если считать, что это модификация оригинальной грамматики Oberon-2 из соответствующего Report, то это не LL(1), т.к. оригинальная грамматика в том виде, как она приведена в Oberon-2 Report тоже LL(1) не является. Если же речь идет о модификации какой-то другой грамматики, то приведи, пожалуйста, полную грамматику, включающую параметризованные типы, т.к. по ссылке, приведенной тобой выше, я такой полной грамматики не нашел.
Почему грамматика Оберона-2 не является LL(1)?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC,
> ПК> оригинальной грамматики Oberon-2 из соответствующего Report, то это не LL(1), т.к. оригинальная грамматика в том виде, как она приведена в Oberon-2 Report тоже LL(1) не является
> Почему грамматика Оберона-2 не является LL(1)?
В том виде, как она определена по ссылке выше? Вот одна из наиболее существенных неоднозначностей:
Фактически, это синтаксическая неразличимость между type guard (*) и вызовом процедуры. Это некоторым образом аналогично неоднозначности с угловыми скобками в C++ (аргументы шаблона vs. операции < и >), требующей знания контекста (значения идентификаторов в разбираемом выражении).
От добавления сюда параметризованных типов, дополнительно перегружающих значение скобочек ( и ), картина дополнительно усложняется. Правда, я пока не вполне уверен, можно ли в соответствии с предлагающимся расширением использовать параметризованные типы в выражениях. Если нет, то, помимо прочего, приведенная ссылка еще и не является ответом на первоначальный вопрос, упоминавший удобные для использования шаблоны (или хотя бы generics), а не ограниченные generics в духе Ады.
A type guard v(T) asserts that the dynamic type of v is T (or an extension of T), i.e. program execution is aborted, if the dynamic type of v is not T (or an extension of T). Within the designator, v is then regarded as having the static type T.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
(Боюсь правда что заодно и товарища по палате, но такова она — трудная судьба наполеонов 
Перекуём баги на фичи!
