Здравствуйте, SilverCloud, Вы писали:
SC>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Так лучше?
SC>Нет . Если хочешь совета, их есть у меня SC>PROCEDURE, BEGIN, END сделай серенькими, чтоб в глаза не лезли. Это мусор, мешающй восприятию. Вообще-то их надо маленткими буквами писать, но, это, я так понимаю, уже Вирт накосячил, и лечению не поддаётся Италик убери нафиг, лучше всё одним шрифтом, ну в крайнем случае — что-нибудь болдом выделять, хотя, имхо, и это от лукавого, а выделять надо только цветом. SC>PS
Как показала практика, с Сергеем спорить абсолютно бесполезно. Это показали многотысячные топики в соседних ветках.
Ну а как спорить с человеком, отрый вот это называет верхом изящества, читаемости и вообще идеалом:
Не спорю, и к такому синтаксису можно привыкнуть. НО!
Здравствуйте, Mamut, Вы писали:
M> Не спорю, и к такому синтаксису можно привыкнуть. НО!
Именно спорите.
M> ОРЕТ НА ЧИТАЮЩЕГО
Вот если бы это был текст на естественном языке, то такие категории к нему были бы применимы.
Но Модулы/Обероны — языки программирования компьютеров. Категория "орать" к ним не применима.
Да и что значит орать? Это что ли:
while ... do ... end перевод: "Уважаемый компьютер, выполните пожалуйста цикл while"
WHILE ... DO ... END перевод: "Эй ты, железяка ржавая! А ну немедленно выполни цикл! Пошевеливайся!"
Заглавными буквами пишутся только служебные зарезервированные слова, идентификаторы пишутся прописными буквами. Это оптимальное и естественное решение — сразу видна структура программы.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Заглавными буквами пишутся только служебные зарезервированные слова, идентификаторы пишутся прописными буквами. Это оптимальное и естественное решение — сразу видна структура программы.
Все это может быть, но я как вспомню А-Васик (и, кажется, тоже самое — Ку-Васик), то страшно становится, как мне задолбало жат ькнопку Шифт.....
Да и читать такие программы плохо — переменные почему-то так и норовят проскочить мимо взгляда
Но это. как я понимаю, чисто субъективное восприятие
Здравствуйте, AlLucky, Вы писали:
AL>Да и читать такие программы плохо — переменные почему-то так и норовят проскочить мимо взгляда
AL>Но это. как я понимаю, чисто субъективное восприятие
Может и субъективно. Однако, если служебные слова бросаются в глаза, объекты данных при чтении отходят на второй план. Вы это сказали и я согласен. А ведь именно для обработки данных пишутся программы. То есть,прежде всего, должно быть видно, что мы обрабатываем. Вопрос, как обрабатываем, все-таки, вторичен. Поэтому желательно, чтобы служебные слова находились "в тени".
M>> Не спорю, и к такому синтаксису можно привыкнуть. НО!
СГ>Именно спорите.
Это у меня в крови
M>> ОРЕТ НА ЧИТАЮЩЕГО
СГ>Вот если бы это был текст на естественном языке, то такие категории к нему были бы применимы. СГ>Но Модулы/Обероны — языки программирования компьютеров. Категория "орать" к ним не применима.
СГ>Да и что значит орать? Это что ли:
СГ>while ... do ... end перевод: "Уважаемый компьютер, выполните пожалуйста цикл while" СГ>WHILE ... DO ... END перевод: "Эй ты, железяка ржавая! А ну немедленно выполни цикл! Пошевеливайся!"
СГ>Заглавными буквами пишутся только служебные зарезервированные слова, идентификаторы пишутся прописными буквами. Это оптимальное и естественное решение — сразу видна структура программы.
ТО, что мы пишем, копьютеру абсольтно пофиг. Все равно компилятор переведет это дело в машинные коды (ну или в другое удобное, но абсолютно неудобочитаемое представление)
Программы в первую очередь читаются/пишутся людьми. С \той точки зрения Оберон нечитаем. Как правильно заметил Игорь Привалов
То есть,прежде всего, должно быть видно, что мы обрабатываем. Вопрос, как обрабатываем, все-таки, вторичен. Поэтому желательно, чтобы служебные слова находились "в тени".
Здравствуйте, Mamut, Вы писали:
M>Программы в первую очередь читаются/пишутся людьми. С \той точки зрения Оберон нечитаем.
Упреки в нечитаемости Оберона (да и любого языка) из уст поклонников C/C++ ? Забавно.
Видяй сломицу в оке ближнего, не зрит в своем ниже бруса. Строг и свиреп быши к рифмам ближнего твоего, сам же,
аки свинья непотребная, рифмы негодные и уху зело вредящие сплел еси. Иди в огонь вечный, анафема.
Здравствуйте, Трурль, Вы писали:
Т>Упреки в нечитаемости Оберона (да и любого языка) из уст поклонников C/C++ ? Забавно.
А в чем проблема? C++ вполне даже удобен при чтении. Другой вопрос, что там имеется масса всякой скрытой активности, которая временами сильно усложняет жизнь.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Трурль, Вы писали:
Т>>Упреки в нечитаемости Оберона (да и любого языка) из уст поклонников C/C++ ? Забавно.
Д>А в чем проблема? C++ вполне даже удобен при чтении. Другой вопрос, что там имеется масса всякой скрытой активности, которая временами сильно усложняет жизнь.
Вообще-то Оберон более удобен для чтения — LL(1) грамматика, однако. Читаешь слева на право сверху вниз, заглядываешь вперед всего на одно слово и сразу понимаешь смысл читаемого.
В тоже время, в С/С++ для понимания смысла нужно считать целое предложение целиком, а затем хорошенько его обдумать учитывая контекст в котором оно находится, а также надо знать что обозначают использованные в предложении идентификаторы, ну а если к этому добавить возможность перегрузки операторов/шаблоны/макросы, то можно утверждать, что в общем случае совершенно не возможно понять написанное предложение не ознакомившись со всем остальным текстом программы.
Сергей,
> Вообще-то Оберон более удобен для чтения — LL(1) грамматика, однако. Читаешь слева на право сверху вниз, заглядываешь вперед всего на одно слово и сразу понимаешь смысл читаемого. > В тоже время, в С/С++ для понимания смысла нужно считать целое предложение целиком <...>
Ну зачем же так подставляться? Я понимаю, что тебе Оберон нравится, и программы на Обероне тебе читать легче, чем программы на Си++. Но вот пытаться выдать подобные предпочтения за что-то объективное с помощью использования подобной аргументации... В общем, твой аргумент сводится к тому, что чем проще грамматика языка, тем легче читать текст на нем. Простые контрпримеры показывают, что это не так.
Регулярные выражения описываются регулярной грамматикой. Еще проще чем LL(1). Читаются очень нелегко, если нет соответствующего навыка.
Естественный язык в LL(1) не уложится и близко. Преимущественно читается намного легче Оберона или Си++.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Регулярные выражения описываются регулярной грамматикой. Еще проще чем LL(1). Читаются очень нелегко, если нет соответствующего навыка.
Такие регулярные выражения как 123, x11, "Hello world" читаются (имхо) очень легко.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ну зачем же так подставляться? Я понимаю, что тебе Оберон нравится, и программы на Обероне тебе читать легче, чем программы на Си++. Но вот пытаться выдать подобные предпочтения за что-то объективное с помощью использования подобной аргументации... В общем, твой аргумент сводится к тому, что чем проще грамматика языка, тем легче читать текст на нем. Простые контрпримеры показывают, что это не так.
ПК>Регулярные выражения описываются регулярной грамматикой. Еще проще чем LL(1). Читаются очень нелегко, если нет соответствующего навыка.
Ну и где эти контр примеры? Давайте же, приводите текст на регулярном языке.
"+123456789E-64" — такой текст сложен?
"+7 (1234) 63-74-72" — а может такой текст сложен?
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Регулярные выражения описываются регулярной грамматикой. Еще проще чем LL(1). Читаются очень нелегко, если нет соответствующего навыка.
Не уверен, что это так
Как быть с такими конструкциями?
СГ>>Вы привели описание какой-то регулярной грамматики, а надо привести пример самого текста, который она распознает.
Д>Ну так ты говорил, что они должны легко читаться? Вот и прочитай.
Да что читать-то? Вы привели не текст, а саму грамматику, приведите текст распознаваемой этой грамматикой. Вот его-то и почитаем.
Вот примеры текста на регулярных языках: "12.08.2005", "12345", "-3773.074E+12", "+7 (1234) 56-78-90" — все они читаются с полпинка.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Да что читать-то? Вы привели не текст, а саму грамматику, приведите текст распознаваемой этой грамматикой. Вот его-то и почитаем.
СГ>Вот примеры текста на регулярных языках: "12.08.2005", "12345", "-3773.074E+12", "+7 (1234) 56-78-90" — все они читаются с полпинка.
Если я не ошибаюсь, речь шла о самом языке описания регулярных выражений, а не о языках, которые можно с их помощью описать. Пусть Трурль поправит, если я ошибаюсь.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Дарней, Вы писали: Д>>Ну так ты говорил, что они должны легко читаться? Вот и прочитай.
СГ>Да что читать-то? Вы привели не текст, а саму грамматику, приведите текст распознаваемой этой грамматикой. Вот его-то и почитаем.
СГ>Вот примеры текста на регулярных языках: "12.08.2005", "12345", "-3773.074E+12", "+7 (1234) 56-78-90" — все они читаются с полпинка.
Сергей, вы программы читаете или их грамматику? Или входные данные для программ вообще?
Есть грамматика рег. выражений, есть сами выражения.
Есть грамматика оберона, есть программы на нём.
Всё ещё логики не улавливаете?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, Дарней, Вы писали: Д>>>Ну так ты говорил, что они должны легко читаться? Вот и прочитай.
СГ>>Да что читать-то? Вы привели не текст, а саму грамматику, приведите текст распознаваемой этой грамматикой. Вот его-то и почитаем.
СГ>>Вот примеры текста на регулярных языках: "12.08.2005", "12345", "-3773.074E+12", "+7 (1234) 56-78-90" — все они читаются с полпинка.
К>Сергей, вы программы читаете или их грамматику? Или входные данные для программ вообще? К>Есть грамматика рег. выражений, есть сами выражения. К>Есть грамматика оберона, есть программы на нём. К>Всё ещё логики не улавливаете?
Я читаю текст который был порожден какой-то грамматикой. Чем проще та грамматика, тем проще прочитать текст.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Я читаю текст который был порожден какой-то грамматикой. Чем проще та грамматика, тем проще прочитать текст.
А теперь прочитай, что тебе Павел написал, хотя грамматика у русского сложная, видимо трудно тебе приходится
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Я читаю текст который был порожден какой-то грамматикой. Чем проще та грамматика, тем проще прочитать текст.
Это что ж, товарищи, получается? Выходит, Форт и Лисп читать проще всего?
Здравствуйте, Oyster, Вы писали:
O>Это что ж, товарищи, получается? Выходит, Форт и Лисп читать проще всего?
Есть еще другая проблема. Для распознавания текста порожденного регулярной грамматикой нужно мысленно сотворить у себя в голове соответствующий конечный автомат. Но если число его состояний будет большим (а возможности человеческого мозга в среднем ограничиваются по заявлениям психологов 7-ю плюс минус 2 объектами рассматриваемыми одновременно), то такой автомат может показаться "сложным", но не потому что он на самом деле сложен, а потому что он большой и просто целиком в голове не убрался.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Oyster, Вы писали:
O>>Это что ж, товарищи, получается? Выходит, Форт и Лисп читать проще всего?
СГ>Есть еще другая проблема. Для распознавания текста порожденного регулярной грамматикой нужно мысленно сотворить у себя в голове соответствующий конечный автомат. Но если число его состояний будет большим (а возможности человеческого мозга в среднем ограничиваются по заявлениям психологов 7-ю плюс минус 2 объектами рассматриваемыми одновременно), то такой автомат может показаться "сложным", но не потому что он на самом деле сложен, а потому что он большой и просто целиком в голове не убрался.
И как же я это русский понимаю и не только русский? Когда там дофигищи состояний...
Видимо, я гений
Здравствуйте, Сергей Губанов, Вы писали:
O>>Это что ж, товарищи, получается? Выходит, Форт и Лисп читать проще всего?
СГ>Есть еще другая проблема. Для распознавания текста порожденного регулярной грамматикой нужно мысленно сотворить у себя в голове соответствующий конечный автомат. Но если число его состояний будет большим (а возможности человеческого мозга в среднем ограничиваются по заявлениям психологов 7-ю плюс минус 2 объектами рассматриваемыми одновременно), то такой автомат может показаться "сложным", но не потому что он на самом деле сложен, а потому что он большой и просто целиком в голове не убрался.
Иными словами — если текст, описанный простой грамматикой, сложно читать — то это исключительно проблема читающего?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, Oyster, Вы писали:
O>>>Это что ж, товарищи, получается? Выходит, Форт и Лисп читать проще всего?
СГ>>Есть еще другая проблема. Для распознавания текста порожденного регулярной грамматикой нужно мысленно сотворить у себя в голове соответствующий конечный автомат. Но если число его состояний будет большим (а возможности человеческого мозга в среднем ограничиваются по заявлениям психологов 7-ю плюс минус 2 объектами рассматриваемыми одновременно), то такой автомат может показаться "сложным", но не потому что он на самом деле сложен, а потому что он большой и просто целиком в голове не убрался.
К>И как же я это русский понимаю и не только русский? Когда там дофигищи состояний... К>Видимо, я гений
Состояний может быть бесконечно много, но если они, например, перенумерованы, то достаточно помнить только номер. Соответственно человек легко будет помнить одновременно 7 +/- 2 номеров.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Курилка, Вы писали:
К>>И как же я это русский понимаю и не только русский? Когда там дофигищи состояний... К>>Видимо, я гений
СГ>Состояний может быть бесконечно много, но если они, например, перенумерованы, то достаточно помнить только номер. Соответственно человек легко будет помнить одновременно 7 +/- 2 номеров.
Ну стопудово гений, на лету всю грамматику перенумеровываю...
СГ>>Состояний может быть бесконечно много, но если они, например, перенумерованы, то достаточно помнить только номер. Соответственно человек легко будет помнить одновременно 7 +/- 2 номеров.
Хотя, конечно, на счет бесконечности это я не прав. Ведь сам номер состояния может быть таким большим что в голове не уберется.
Здравствуйте, Курилка, Вы писали:
К>Ну стопудово гений, на лету всю грамматику перенумеровываю...
Распознаватель грамматики русского языка уже у Вас в голове сформирован практически "аппаратно". Это случилось тогда когда Вы изучали русский язык.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>Состояний может быть бесконечно много, но если они, например, перенумерованы, то достаточно помнить только номер. Соответственно человек легко будет помнить одновременно 7 +/- 2 номеров.
СГ>Хотя, конечно, на счет бесконечности это я не прав. Ведь сам номер состояния может быть таким большим что в голове не уберется.
СГ>Здравствуйте, Курилка, Вы писали:
К>>Ну стопудово гений, на лету всю грамматику перенумеровываю...
СГ>Распознаватель грамматики русского языка уже у Вас в голове сформирован практически "аппаратно". Это случилось тогда когда Вы изучали русский язык.
И? Регулярные выражения кончено же игнорируются. Распознаватель их должен бы элементарно формироваться у людей, а вот фиг — многие испытывают трудности чтения их и составления.
Тогда как, допустим, иностранные языки даются проще, хотя грамматики несопоставимо разные.
Здравствуйте, Курилка, Вы писали:
К>И? Регулярные выражения кончено же игнорируются. Распознаватель их должен бы элементарно формироваться у людей, а вот фиг — многие испытывают трудности чтения их и составления.
Это мной чего-то игнорируется? Вообще-то это я просил показать трудночитаемый текст порожденный регулярной грамматикой, а до сих пор такого текста не показано (вместо текста мне показывали саму грамматику). И наоборот, примеры текста порожденного регулярной грамматикой показанные мной (и Трурлем) как раз-то были очень легко читаемыми. То есть утверждение о том, что чем проще грамматика тем проще читать текст ей порожденный, которое можно было бы опровергнуть одним единственным контрпримером, так до сих пор и не опровергнуто, стало быть до сих пор правильное.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Курилка, Вы писали:
К>>И? Регулярные выражения кончено же игнорируются. Распознаватель их должен бы элементарно формироваться у людей, а вот фиг — многие испытывают трудности чтения их и составления.
СГ>Это мной чего-то игнорируется? Вообще-то это я просил показать трудночитаемый текст порожденный регулярной грамматикой, а до сих пор такого текста не показано (вместо текста мне показывали саму грамматику). И наоборот, примеры текста порожденного регулярной грамматикой показанные мной (и Трурлем) как раз-то были очень легко читаемыми. То есть утверждение о том, что чем проще грамматика тем проще читать текст ей порожденный, которое можно было бы опровергнуть одним единственным контрпримером, так до сих пор и не опровергнуто, стало быть до сих пор правильное.
Сказано было что грамматика для таких выражений не сложная (грамматики в наличи нет, сорри).
И прочитать ты отказался, почему-то приводя строки, которые подходят под это выражение (которые совсем не при чём).
Специально для тебя повторяю аналогию:
Есть грамматика Оберона, есть программы на Обероне, есть данные, с которыми работает программа Оберона.
Есть грамматика рег. выражений, есть сами рег. выражения, есть строки, которые удовлетворяют этим выражениям.
Мда, перепутал автора сообщения. Я говорил про вот это:
Регулярные выражения описываются регулярной грамматикой. Еще проще чем LL(1). Читаются очень нелегко, если нет соответствующего навыка.
Речь шла именно о самих регулярных выражениях, а не порожденных ими языках.
Т>А такие разве описываются регулярной грамматикой?
А вот это уже одельный вопрос. Наверно, скорее "нет", чем "да", поскольку стандартные регулярные выражения не поддерживают рекурсивные определения. Но уж LL(k) они точно описываются. Тоже должны читаться... достаточно легко
Здравствуйте, Курилка, Вы писали:
К>Специально для тебя повторяю аналогию: К>Есть грамматика Оберона, есть программы на Обероне, есть данные, с которыми работает программа Оберона. К>Есть грамматика рег. выражений, есть сами рег. выражения, есть строки, которые удовлетворяют этим выражениям. К>Надеюсь, что уж достаточно разжевал
Ну и? Будет сегодня хоть один пример трудно читаемой строки порожденной регулярной грамматикой?
Здравствуйте, Трурль, Вы писали:
СГ>>Ну и? Будет сегодня хоть один пример трудно читаемой строки порожденной регулярной грамматикой?
Т>jfdb-erhfj+fdfgdf74$$ 7(jjjd89(( sdhd/5&8 3488467g gv 6^^ )
А регулярная грамматика которая ее порождает, конечно же такая:
Знак = j | f | d | b | — | e | r | h | + | 7 | 4 | $ | ( | 8 | 9 | s | / | 5 | & | 3 | 6 | пробел | v | 6 | ^| ) |
Слово = {Знак}
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Да что читать-то? Вы привели не текст, а саму грамматику, приведите текст распознаваемой этой грамматикой. Вот его-то и почитаем.
Он привел текст описывающий граматику. Привести строку ей удовлетворяющей бессмысленно, так как это будет частный случай.
Тебе просто объясняют, что граматика самих регэкспов очень примитивна. Но читать ее очень не просто.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Я читаю текст который был порожден какой-то грамматикой. Чем проще та грамматика, тем проще прочитать текст.
Блин, я хринею.
Приблизительная граматика регекспов:
Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>Для распознавания текста порожденного регулярной грамматикой нужно мысленно сотворить у себя в голове соответствующий конечный автомат... СГ>Состояний может быть бесконечно много,
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Вообще-то Оберон более удобен для чтения — LL(1) грамматика, однако.
VD>Тебе уже сказали, что регекспы тоже LL(1)-граматика. Даже проще. Так что забудь этот несостоятельный аргумент.
Чем проще грамматика — тем проще ее распознавать (понимать, читать, писать). Этот аргумент еще ни кто не смог опровергнуть. Хотя хватило бы и одного контрпримера.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Чем проще грамматика — тем проще ее распознавать (понимать, читать, писать). Этот аргумент еще ни кто не смог опровергнуть. Хотя хватило бы и одного контрпримера.
Сказано верно, но очень многие путают простоту и примитивность. Простая граматика действительно просто читается, примитивная нет.
Например, азбука морзе — это не простота, а галимый примитив и читается ужасно.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Я читаю текст который был порожден какой-то грамматикой. Чем проще та грамматика, тем проще прочитать текст.
Нет такой связи. Языки, типа BF и некоторые другие из "задвинутых" описываются регулярной грамматикой, а попробуй прочти.
Если из ASM-а исключить макросы и вложенные арифметические выражения (со скобками и старшинством операций), то такой ASM тоже можно будет описать регулярной грамматикой. Опять же, читается легко только людьми с определенными навыками.
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Я читаю текст который был порожден какой-то грамматикой. Чем проще та грамматика, тем проще прочитать текст.
O>Это что ж, товарищи, получается? Выходит, Форт и Лисп читать проще всего?
Форт действительно читать легко, особенно если создаешь свои предметные словари и не ленишься писать compile-time слова (определяющие слова), то программа получается весьма читабельной. Правда, в случае наличия собственных определяющих слов, каждое из них вносит свои правила в грамматику программы. Вообще, Форт незаслуженно обделен вниманием. И это при том, что породить собственный качественный DSL на нем легче даже, чем где бы то ни было. Собственно, в этом и состоит основная философия Forth-а — порождение DSL, максимально близких к предметной области. По этому критерию даже С++-у с перегрузкой операторов и шаблонами до Forth-а ооочень далеко. Да и уровень рефлексии в транслируемых реализациях может быть абсолютно произвольным (каким захочет разработчик). По эффективности исполнения он значительно превосходит другие интерпретируемые языки. До эпохи C++ + inline + aggressive optimization мне удавалось писать на Forth-е программы, не уступающие по производительности аналогичным на С. Кстати, написать Лисп на Форте — вообще ерунда, единственно что — так это надо после открывающей скобки пробел ставить (хотя и это можно обойти).
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>А регулярная грамматика которая ее порождает, конечно же такая:
СГ>>
СГ>>Знак = j | f | d | b | — | e | r | h | + | 7 | 4 | $ | ( | 8 | 9 | s | / | 5 | & | 3 | 6 | пробел | v | 6 | ^| ) |
СГ>>Слово = {Знак}
Т>Скорее такая: Т>
Т>Знак = пробел | ! | " | ...
Т>Слово = {Знак}
Т>
В такой грамматике любое выражение целиком будет являться одним словом. т.е. пример малость неудачный. Надо было привести пример грамматики, которая имеет хотя бы пару конечных состояний, т.е. где требуется отделять слова друг от друга.
Типа:
A = 1 0 0
B = 1 0 1
C = (0 1 1 0) | (0 1 0 1)
S1 = (A C B) (A C)* | (C A B)* | (B C (A | (C A))*)
S2 = ((A C) | (A B С))* | ((C B A) | (B C))*
потом породить достаточной длины цепочку и отдать на прочтение
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>Вообще-то Оберон более удобен для чтения — LL(1) грамматика, однако.
VD>>Тебе уже сказали, что регекспы тоже LL(1)-граматика. Даже проще. Так что забудь этот несостоятельный аргумент.
СГ>Чем проще грамматика — тем проще ее распознавать (понимать, читать, писать).
Ты вообще способен воспринимать аргументы? Тебе уже показали совершенно нечитаемый регексп. И показали приблизительную грамматику регекспов, которая проста как три копейки.
Запомни на будующее — простота грамматики упрощает исключительно построение парсера! Никакой корреляция между простотой граматики и простотой чтения текстов удовлетворяющих этой граматике нет!
СГ> Этот аргумент еще ни кто не смог опровергнуть.
Ты просто не вспринимашь аргументы. Пример с регулярными выражениями и их грамматикой изумительно опровергает твою теорию.
СГ> Хотя хватило бы и одного контрпримера.
Тебе, кстати, никто не обязан приводить контр-примеры (хотя оных было предостаточно). Это ты обязан доказать состоятельность своего утверждения. И ты это даже не попытался сделать.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
СГ>> Хотя хватило бы и одного контрпримера.
VD>Тебе, кстати, никто не обязан приводить контр-примеры (хотя оных было предостаточно). Это ты обязан доказать состоятельность своего утверждения. И ты это даже не попытался сделать.
LL(1) грамматика: читаешь слева на право сверху вниз, заглядываешь вперед всего на одно слово и сразу понимаешь смысл читаемого слова.
Регулярная грамматика: читаешь слева на право сверху вниз по одному слову, понимаешь каждое слово сразу.
Ничего проще быть не может.
Ну а то что сложность может возникнуть просто от того, что грамматика большая и в голове не убирается, моего утверждения не опровергает, просто потому, что не LL(1) или не регулярная грамматика аналогичного размера была бы еще труднее для восприятия. Так что если хотите сравнить сложность регулярной грамматики или LL(1) грамматики с какой-нибудь другой грамматикой, то сравнивайте грамматики сопоставимых друг с другом размеров, дабы исключить сложность вносимую самим размером.
Так что чем проще грамматика, тем проще читать, без компромисов.
Здравствуйте, Сергей Губанов, Вы писали:
VD>>Тебе, кстати, никто не обязан приводить контр-примеры (хотя оных было предостаточно). Это ты обязан доказать состоятельность своего утверждения. И ты это даже не попытался сделать.
СГ>Вообще-то, с этого-то всё и началось:
СГ>http://www.rsdn.ru/Forum/Message.aspx?mid=1322914&only=1
СГ>LL(1) грамматика: читаешь слева на право сверху вниз, заглядываешь вперед всего на одно слово и сразу понимаешь смысл читаемого слова.
Это доказательство? Ты хоть на оценки то поглядел? Всем просто смешно это читать.
СГ>Регулярная грамматика: читаешь слева на право сверху вниз по одному слову, понимаешь каждое слово сразу.
Ты русский то так же читашь? Хотя похоже так же. Иначе воспринимал бы аргументы. "Регулярная грамматика" бывают разные. Бывает, например, EBNF, который прикроасно читается. А бывают регулярные выражение которые в более менее сложных случаях без пол литры не осилить.
СГ>Ну а то что сложность может возникнуть просто от того, что грамматика большая и в голове не убирается, моего утверждения не опровергает, просто потому, что не LL(1) или не регулярная грамматика аналогичного размера была бы еще труднее для восприятия. Так что если хотите сравнить сложность регулярной грамматики или LL(1) грамматики с какой-нибудь другой грамматикой, то сравнивайте грамматики сопоставимых друг с другом размеров, дабы исключить сложность вносимую самим размером.
Ты хоть понимашь смысл слова "читаемость"?
СГ>Так что чем проще грамматика, тем проще читать, без компромисов.
Ладно тратить на тебя свое время просто бессмысленно. Оставайся при своих заблаждениях.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>потом породить достаточной длины цепочку и отдать на прочтение
VD>Кстати, а что там мудрить?
VD>
Так надо привести пример трудно читаемой (понимаемой). А эта легко читается (понимается) — любая последовательность нулей и единиц соответствует заявленной грамматике. Читаем по одному символу, проверяем равен ли он 0 или 1, если да, то читаем дальше, в противном случае констатируем ошибку. Всё элементарно.
Здравствуйте, achp, Вы писали:
A>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Ну и? Будет сегодня хоть один пример трудно читаемой строки порожденной регулярной грамматикой?
A>Пример уже, кажется, приведён.
A>http://www.rsdn.ru/Forum/Message.aspx?mid=1323168&only=1
Если это пример самой строки, а не грамматики, то тогда пусть сначала приведут регулярную грамматику, которая эту строку порождает. Тогда можно будет понять является ли разбор той строки сложным или нет. А так, без предъявления грамматики, можно заявить, что та строка была порождена регулярной грамматикой вида
Знак = ...любой ASCII символ...
Слово = {Знак}
А такая регуларная грамматика читается очень легко: Берем и считываем следующий символ и ищем его в таблице ASCII символов, если находим, значит хорошо, мы поняли написанное, в противном случае констатируем синтаксическую ошибку.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Так надо привести пример трудно читаемой (понимаемой). А эта легко читается (понимается) — любая последовательность нулей и единиц соответствует заявленной грамматике. Читаем по одному символу, проверяем равен ли он 0 или 1, если да, то читаем дальше, в противном случае констатируем ошибку. Всё элементарно.
Ну хорошо!
Вот тебе кусок текста, который описывается предельно простой грамматикой. То есть, насколько я понимаю, он должен очень легко читаться (пониматься)
Расскажи ка мне пожалуйста, о чем там идет речь?
Здравствуйте, Дарней, Вы писали:
Д>Ну хорошо! Д>Вот тебе кусок текста, который описывается предельно простой грамматикой. То есть, насколько я понимаю, он должен очень легко читаться (пониматься) Д>Расскажи ка мне пожалуйста, о чем там идет речь?
Вы забыли привести саму регулярную грамматику породившую этот текст. Приведите грамматику тогда почитаем.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Вы забыли привести саму регулярную грамматику породившую этот текст. Приведите грамматику тогда почитаем.
Д>например, такая: Д>
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Курилка, Вы писали:
К>>Специально для тебя повторяю аналогию: К>>Есть грамматика Оберона, есть программы на Обероне, есть данные, с которыми работает программа Оберона. К>>Есть грамматика рег. выражений, есть сами рег. выражения, есть строки, которые удовлетворяют этим выражениям. К>>Надеюсь, что уж достаточно разжевал
СГ>Ну и? Будет сегодня хоть один пример трудно читаемой строки порожденной регулярной грамматикой?
Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая.
Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Чего это за такое? Я не понимаю. Приведите пожалуйста как положено для грамматик — в EBNF форме.
Ну только не надо к мелочам придираться. Не поверю, что ты не понимаешь регулярные выражения.
Хотя вообще, любопытно. Хочешь сказать, что если я не поленюсь и перепишу в EBNF, ты сможешь прочитать эти данные и сказать, что они означают?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Чего это за такое? Я не понимаю. Приведите пожалуйста как положено для грамматик — в EBNF форме.
Д>Ну только не надо к мелочам придираться. Не поверю, что ты не понимаешь регулярные выражения. Д>Хотя вообще, любопытно. Хочешь сказать, что если я не поленюсь и перепишу в EBNF, ты сможешь прочитать эти данные и сказать, что они означают?
Конечно смогу. Чего такого сложного дерево разбора выражения для регулярной грамматики построить? Вот если бы грамматика была бы какая-нибудь контекстно-зависимая или еще более сложная, вот тогда может быть и не смог бы.
А к мелочам я не придираюсь. Как это интересно не имея EBNF-а для грамматики я Вам буду дерево разбора строить?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Конечно смогу. Чего такого сложного дерево разбора выражения для регулярной грамматики построить? Вот если бы грамматика была бы какая-нибудь контекстно-зависимая или еще более сложная, вот тогда может быть и не смог бы.
СГ>А к мелочам я не придираюсь. Как это интересно не имея EBNF-а для грамматики я Вам буду дерево разбора строить?
Здравствуйте, Sergey J. A., Вы писали:
SJA>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая. SJA>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?
SJA>
Increment the pointer
Increment the pointer
Increment the pointer
Increment the byte at the pointer
Increment the pointer
Increment the pointer
Increment the byte at the pointer
Increment the byte at the pointer
Increment the byte at the pointer
Increment the byte at the pointer
Increment the byte at the pointer
Increment the pointer
Increment the pointer
Increment the byte at the pointer
Increment the byte at the pointer
...
и т.д.
А что, у Вас были какие-то проблемы с парсингом этого выражения?
Всё предельно просто: читаете символ, смотрите в таблицу что он обозначает, вот и всё. Никаких заглядываний вперед, ни какой контекстной зависимости. Всё элементарно.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Конечно смогу. Чего такого сложного дерево разбора выражения для регулярной грамматики построить? Вот если бы грамматика была бы какая-нибудь контекстно-зависимая или еще более сложная, вот тогда может быть и не смог бы.
СГ>>А к мелочам я не придираюсь. Как это интересно не имея EBNF-а для грамматики я Вам буду дерево разбора строить?
Д>А дерево разбора поможет тебе понять СМЫСЛ кода?
Того кода, который Вы привели — нет. По моему там абракадабра, случайная последовательность знаков. А зачем Вам нужно чтобы я понимал смысл той абракадабры?
Здравствуйте, Bigger, Вы писали:
B>Здравствуйте, Сергей Губанов, Вы писали:
B>skip
СГ>>Я читаю текст который был порожден какой-то грамматикой. Чем проще та грамматика, тем проще прочитать текст.
B>Тогда самый простой язык для чтения BrainFuck. BrainFuck-программа составляется из 8 разных символов-инструкций.
B>
Я так понял, Сергей хочет сказать, что, чем проще грамматика, тем проще понять, что написано с грамматической точки зрения. Вы же все приводите примеры с трудной семантикой, это совсем другое. Я легко могу сказать правильна ли БрейнФак программа грамматически, а сделать тоже самое для программы на С++ в несколько раз сложнее, а в некоторых случаях просто невозможно для человека.
Здравствуйте, Bigger, Вы писали:
B>Здравствуйте, Сергей Губанов, Вы писали:
B>skip
СГ>>Я читаю текст который был порожден какой-то грамматикой. Чем проще та грамматика, тем проще прочитать текст.
B>Тогда самый простой язык для чтения BrainFuck. BrainFuck-программа составляется из 8 разных символов-инструкций.
B>
Increment the pointer
затем 10 раз делает Increment the byte at the pointer
затем выполняет инструкцию [
Increment the pointer
затем 7 раз делает Increment the byte at the pointer
...
и т.д.
Еще примеры трудных для парсинга, тьфу т.е. для чтения текстов порожденных простой грамматикой (регулярной или LL(1)) будут? Или может уже пора с этим делом завязать из-за бесперспективности?
Здравствуйте, Quintanar, Вы писали:
Q>Я так понял, Сергей хочет сказать, что, чем проще грамматика, тем проще понять, что написано с грамматической точки зрения. Вы же все приводите примеры с трудной семантикой, это совсем другое. Я легко могу сказать правильна ли БрейнФак программа грамматически, а сделать тоже самое для программы на С++ в несколько раз сложнее, а в некоторых случаях просто невозможно для человека.
Читаем исходное его сообщение:
Вообще-то Оберон более удобен для чтения — LL(1) грамматика, однако. Читаешь слева на право сверху вниз, заглядываешь вперед всего на одно слово и сразу понимаешь смысл читаемого.
Теперь очень сложный вопрос — смысл читаемого это грамматика или семантика?
Но до некоторых несколько упёртых людей смысл собственных слов, видимо, не понятен
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Того кода, который Вы привели — нет. По моему там абракадабра, случайная последовательность знаков. А зачем Вам нужно чтобы я понимал смысл той абракадабры?
С чего ты взял, что это абракадабра? Вполне осмысленный фрагмент. Но с листа его даже тренированный глаз не прочитает.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Того кода, который Вы привели — нет. По моему там абракадабра, случайная последовательность знаков. А зачем Вам нужно чтобы я понимал смысл той абракадабры?
P>С чего ты взял, что это абракадабра? Вполне осмысленный фрагмент. Но с листа его даже тренированный глаз не прочитает.
skip СГ>Она делает следующее:
СГ>Increment the pointer СГ>затем 10 раз делает Increment the byte at the pointer СГ>затем выполняет инструкцию [ СГ>Increment the pointer СГ>затем 7 раз делает Increment the byte at the pointer СГ>... СГ>и т.д.
СГ>http://www.rsdn.ru/Forum/Message.aspx?mid=1328802&only=1
СГ>Еще примеры трудных для парсинга, тьфу т.е. для чтения текстов порожденных простой грамматикой (регулярной или LL(1)) будут? Или может уже пора с этим делом завязать из-за бесперспективности?
skip
Q>Я так понял, Сергей хочет сказать, что, чем проще грамматика, тем проще понять, что написано с грамматической точки зрения. Вы же все приводите примеры с трудной семантикой, это совсем другое. Я легко могу сказать правильна ли БрейнФак программа грамматически, а сделать тоже самое для программы на С++ в несколько раз сложнее, а в некоторых случаях просто невозможно для человека.
Дык писать так, чтобы сам запутался, можно на любом языке
После баг-фикса очень большой проги на VB 6, мне досталась программа на C++, с использованием ATL, так там всё было на несколько порядков понятнее чем в VB
Здравствуйте, Сергей Губанов, Вы писали:
P>>С чего ты взял, что это абракадабра? Вполне осмысленный фрагмент. Но с листа его даже тренированный глаз не прочитает.
СГ>А по каким правилам его нужно читать?
СГ>>Регулярная грамматика: читаешь слева на право сверху вниз по одному слову, понимаешь каждое слово сразу. VD>Ты русский то так же читашь? Хотя похоже так же.
По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все-рвано ткест чтаитсея без побрелм. Пичрионй эгото ялвятеся то, что мы не чиатем кдаужЮ бкуву по отдльенотси, а все солво цликеом.
Здравствуйте, Сергей Губанов, Вы писали:
К>>Теперь очень сложный вопрос — смысл читаемого это грамматика или семантика? СГ>1) Понять что написано — это одно.
Написана куча символов... И что?
СГ>2) Понять, что написанная программа будет делать, как будет делать и почему — это другое. СГ>Моя фраза относится к пункту (1).
Ну если для тебя в этом смысл...
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Therion — Crazy Nights";
Здравствуйте, Сергей Губанов, Вы писали:
СГ>LL(1) грамматика: читаешь слева на право сверху вниз, заглядываешь вперед всего на одно слово и сразу понимаешь смысл читаемого слова. СГ>Регулярная грамматика: читаешь слева на право сверху вниз по одному слову, понимаешь каждое слово сразу. СГ>Ничего проще быть не может.
Кому легче читать LL(1) грамматику — человеку или парсеру?
СГ>Так что чем проще грамматика, тем проще читать, без компромисов.
Тебе же привели кучу примеров когда это не так. И регулярные выражения и иероглафическое письмо.
PS. По мере прочтения данной фразы ты можешь позволить себе осознать, что ум, чьи заключения противоречат реальности умом не является
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Курилка, Вы писали:
К>>Теперь очень сложный вопрос — смысл читаемого это грамматика или семантика?
СГ>1) Понять что написано — это одно. СГ>2) Понять, что написанная программа будет делать, как будет делать и почему — это другое.
СГ>Моя фраза относится к пункту (1).
Расшифруй "понять, что написано"
Понять, что написан оператор или ключевое слово и какое именно как правило достаточно просто на любом языке.
Однако, даже в грамматически простом коде, вроде такого:
Здравствуйте, AndreyFedotov, Вы писали:
AF>Кому легче читать LL(1) грамматику — человеку или парсеру?
Обоим.
AF>Тебе же привели кучу примеров когда это не так. И регулярные выражения и иероглафическое письмо.
Ничего подобного. Те примеры, которые до сих пор приводили — очень легко читались/парсились. Более того, мой собственный пример с числом с плавающей точкой: "12345.6787E-26"; или пример с телефонным номером: "+7 (123) 45-67-89", пожалуй и то сложнее для парсинга т.е. для чтения, чем грамматика BrainFuck, грамматика любой последовательности 0 и 1, или грамматика допускающая любую последовательность символов ASCII.
Здравствуйте, Quintanar, Вы писали:
Q>Я так понял, Сергей хочет сказать, что, чем проще грамматика, тем проще понять, что написано с грамматической точки зрения. Вы же все приводите примеры с трудной семантикой, это совсем другое. Я легко могу сказать правильна ли БрейнФак программа грамматически, а сделать тоже самое для программы на С++ в несколько раз сложнее, а в некоторых случаях просто невозможно для человека.
Товарищь утверждал, что есть зависимость между люкостью чтения кода человеком и простотой граматики. Легкость чтения человеком — это не граматика или семантика. Это простота восприятия смысла написанного. То есть простота распознования и правильной интерпретации информации.
Так вот нет никакой зависимости между простотой граматики и простотй воспритяи (чтения) кода на этой граматике. БрэйнФак и регекспы это и демонстрируют. В то же время языки с более сложной граматикой зачастую бывают более понятны человеку (легче читаются) нисмотря на то, что обладают большим количеством грамматических кострукций.
Причем зависимости нет не только прямой (проще граматика проще читать), но и обратной (сложнее грамматика, сложнее читать).
Именро по этому проще читаются программы которые:
1. Хорошо отформатированы.
2. Имеют подсветку синтаксиса.
3. Внятные имена идентиификаторов (и сами идентификаторы).
4. Хорошо структурированы.
5. При написании которых использовались высокоуровневые операторы и функции.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Чего это за такое? Я не понимаю. Приведите пожалуйста как положено для грамматик — в EBNF форме.
Д>Ну только не надо к мелочам придираться. Не поверю, что ты не понимаешь регулярные выражения. Д>Хотя вообще, любопытно. Хочешь сказать, что если я не поленюсь и перепишу в EBNF, ты сможешь прочитать эти данные и сказать, что они означают?
Если бы только это. Он же утверждает, что это вообще проще сделать, нежели имея читабельное описание того, что же это такое.
Здравствуйте, Курилка, Вы писали:
К>Сергей, вы программы читаете или их грамматику? Или входные данные для программ вообще? К>Есть грамматика рег. выражений, есть сами выражения. К>Есть грамматика оберона, есть программы на нём. К>Всё ещё логики не улавливаете?\
Это все верно, только регуляные выражения грамматикой никак не назовешь. Это язык описания регулярных языков, но не грамматика для описания. Так что пример не катит.
Здравствуйте, mefrill, Вы писали:
M>Здравствуйте, Курилка, Вы писали:
К>>Сергей, вы программы читаете или их грамматику? Или входные данные для программ вообще? К>>Есть грамматика рег. выражений, есть сами выражения. К>>Есть грамматика оберона, есть программы на нём. К>>Всё ещё логики не улавливаете?\
M>Это все верно, только регуляные выражения грамматикой никак не назовешь. Это язык описания регулярных языков, но не грамматика для описания. Так что пример не катит.
Володя, ты хочешь сказать, что регулярные выражения не описываются никакой грамматикой? То, что рег. выражения есть грамматика я вообще-то не говорил (но утверждали некоторые в т.ч. СГ)
Здесь надо соотносится с леммой о накачке для регулярных языков. Максимальная длина строки, при прохождении которой автомат не повторит ноиера состояния, не может превышать количества всех состояний. Поэтому, если запомнил состояния, то читать легко, дочитал максимум n символов, где n = число осстояний в автомате, и пошли повторы.
Насчет сложности, мне кажется, что можно выделить две сложности: иерархическую или реляционную и, если можно так выразиться, объемную. То, о чем говорит Сергей Губанов, это иерархическая сложность, в зависимости от типа грамматики, возрастает число различных связей между сущностями языка. Даже, я бы сказал, качество этих связей. Например, такая-то строка может быть в языке только, если впереди есть семь таких же строк. С этой точки зрения Губанов прав. Есть еще сложность как количество таких связей в грамматике. Вот это объемная сложность, в автомате выражающаяся через количество состояний.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Расшифруй "понять, что написано"
Построить (мысленно) дерево синтаксического разбора.
AF>Понять, что написан оператор или ключевое слово и какое именно как правило достаточно просто на любом языке. AF>Однако, даже в грамматически простом коде, вроде такого: AF>
AF>a+=c+++d; // А ведь это LL(1) грамматика!
AF>
AF>Может быть черезвычайно сложно разобраться.
Сложность может появляться еще и от размера грамматики. Так что сравнивая две грамматики на предмет какая из них проще, нужно в первую очередь убедится, что они более-менее одинакового объема. В данном случе синтаксис пересыщен терминалами "+=", "++", поэтому казалось бы простая LL(1) просто из-за своего размера уже как бы и не совсем простая. Однако смотря с чем сравнивать. Какая-нибудь, более сложная грамматика (например, контекстно зависимая) при таком же объеме синтаксиса конечно была бы еще более сложной. При одинаковых объемах LL(1) или регулярная грамматика проще других грамматик.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, Курилка, Вы писали:
К>>>Специально для тебя повторяю аналогию: К>>>Есть грамматика Оберона, есть программы на Обероне, есть данные, с которыми работает программа Оберона. К>>>Есть грамматика рег. выражений, есть сами рег. выражения, есть строки, которые удовлетворяют этим выражениям. К>>>Надеюсь, что уж достаточно разжевал
СГ>>Ну и? Будет сегодня хоть один пример трудно читаемой строки порожденной регулярной грамматикой?
SJA>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая. SJA>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?
Тебе его не переспорить. Для тебя читаемость — это возможность понять смысл кода
А для Сергея читаемость — это понимание того, что представляет из себя та или иная конструкция кода — примерно как для компилятора.
Потому, когда мы приводим примеры вроде "%!!%!& — для нас это бред, пример того, как не надо делать. Мы говорим, что это ужас, который нельзя прочесть и уж тем более — понять. Ну а для него? Для него (как и для компилятора) — это прекрасная программа.
Ведь если вместо символов подставить некие инструкции, например:
" — открыть базу данных
% — отобразить статус операции
! — запросить очередную таблицу из базы
& — закрыть базу
То с его точки зрения получается прекрасная, компактная программа. Он ещё и оверхед над C++ или C# по данной грамматике может начать подсчитывать...
<...> VD>Причем зависимости нет не только прямой (проще граматика проще читать), но и обратной (сложнее грамматика, сложнее читать).
+1
VD>Именро по этому проще читаются программы которые: VD>2. Имеют подсветку синтаксиса.
Это скорее не программы, а средства просмотра программ обепечивают. На самом деле идеально, когда программа читается даже будучи распечатаной в моноширинном шрифте без каких либо ухищрений (вроде выделения отдельных лексем жирным/подчеркиванием).
VD>5. При написании которых использовались высокоуровневые операторы и функции.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Расшифруй "понять, что написано"
СГ>Построить (мысленно) дерево синтаксического разбора.
AF>>Понять, что написан оператор или ключевое слово и какое именно как правило достаточно просто на любом языке. AF>>Однако, даже в грамматически простом коде, вроде такого: AF>>
AF>>a+=c+++d; // А ведь это LL(1) грамматика!
AF>>
AF>>Может быть черезвычайно сложно разобраться.
СГ>Сложность может появляться еще и от размера грамматики. Так что сравнивая две грамматики на предмет какая из них проще, нужно в первую очередь убедится, что они более-менее одинакового объема. В данном случе синтаксис пересыщен терминалами "+=", "++", поэтому казалось бы простая LL(1) просто из-за своего размера уже как бы и не совсем простая. Однако смотря с чем сравнивать. Какая-нибудь, более сложная грамматика (например, контекстно зависимая) при таком же объеме синтаксиса конечно была бы еще более сложной. При одинаковых объемах LL(1) или регулярная грамматика проще других грамматик.
Согласен. В этом ты прав.
Однако замечу, что всего два оператора + и ++ подряд и уже не читаемо. Однако поставь там же скобки или хотя бы пробел — и ситуация кардинально изменится. Читать это станет элементарно. Притом отмечу, что грамматика сама по себе не изменилась — изменилось лишь оформление кода. Следовательно в данном случае не грамматика, а именно оформление является ключевым фактором.
Вывод прост — грамматика является всего лишь одним из огромного множества факторов, которые влияют на воспрятие кода человеком и, как правило, не самым важным.
А в целом — маленький совет. Постарайся смотреть на картину целиком, а не вбуривться в детали. Вот как ты на красивую девушку смотришь. Ты же не вычисляешь, какая у неё форма носа или соотношение периметра ключицы к диаметру коленной чашечки?
Если смотреть на мир в целом и научиться замечать его красоту, то постепенно приходит чувство прекрасного, вкус и начинаешь понимать, почему марочно вино стоит гораздо дороже, чем буратино, а от длинного и многословного повествования писателя получаешь гораздо больше удовольствия, чем от чтения хорошо структурированных и компактных счетов на оплату квартиры.
Здравствуйте, VladD2, Вы писали:
VD>Товарищь утверждал, что есть зависимость между люкостью чтения кода человеком и простотой граматики. Легкость чтения человеком — это не граматика или семантика. Это простота восприятия смысла написанного. То есть простота распознования и правильной интерпретации информации.
Лёгкость чтения это то на сколько легко можно мысленно построить дерево разбора выражения. Понятно, что деревья разбора легче строить для LL(1) грамматики или, вообще, для регулярной. Опять же не надо забывать про размер грамматик. Конечно всегда можется статься так, что какая-нибудь простая но слишком объемная LL(1) грамматика может проиграть какой-нибудь контекстно зависимой, но чрезвычайно компактной грамматике. Так что, для справедливости, сравнивать надо грамматики примерно одинакового объема.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Кому легче читать LL(1) грамматику — человеку или парсеру?
СГ>Обоим.
Ну если быть столь же вежливым — то в общем случае — только парсеру
AF>>Тебе же привели кучу примеров когда это не так. И регулярные выражения и иероглафическое письмо.
СГ>Ничего подобного. Те примеры, которые до сих пор приводили — очень легко читались/парсились. Более того, мой собственный пример с числом с плавающей точкой: "12345.6787E-26"; или пример с телефонным номером: "+7 (123) 45-67-89", пожалуй и то сложнее для парсинга т.е. для чтения, чем грамматика BrainFuck, грамматика любой последовательности 0 и 1, или грамматика допускающая любую последовательность символов ASCII.
Видишь ли. Ты сам жульничаешь. Разберём твои же примеры:
Ты ведь пишешь 12345.6787E-26, а не .00000000000000000000000000123456787
Аналогично пишешь "+7 (123) 45-67-89", а не +7123456789, а ведь грамматика стала ещё проще!
Но ведь про то, что читать стало легче ты, надеюсь, утвержать не будешь?
То есть что ты сам делаешь? Ты сознательно повышаешь сложность грамматики, что бы повысить читаемость — улучшить восприятие твоего кода человеком.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, VladD2, Вы писали:
VD>>Товарищь утверждал, что есть зависимость между люкостью чтения кода человеком и простотой граматики. Легкость чтения человеком — это не граматика или семантика. Это простота восприятия смысла написанного. То есть простота распознования и правильной интерпретации информации.
СГ>Лёгкость чтения это то на сколько легко можно мысленно построить дерево разбора выражения. Понятно, что деревья разбора легче строить для LL(1) грамматики или, вообще, для регулярной. Опять же не надо забывать про размер грамматик. Конечно всегда можется статься так, что какая-нибудь простая но слишком объемная LL(1) грамматика может проиграть какой-нибудь контекстно зависимой, но чрезвычайно компактной грамматике. Так что, для справедливости, сравнивать надо грамматики примерно одинакового объема.
А по-моему лёгкость чтения — это когда никакого дерева разбора строить не нужно, даже не нужно вообще знать о том, что оно есть!
Здравствуйте, VladD2, Вы писали:
VD>Товарищь утверждал, что есть зависимость между люкостью чтения кода человеком и простотой граматики. Легкость чтения человеком — это не граматика или семантика. Это простота восприятия смысла написанного. То есть простота распознования и правильной интерпретации информации.
С этим не соглашусь, мне кажется и грамматика тоже. Классическийй пример: глюковатые синявки манделили на мосе. Смысл, очевидно, отсюда кое-какой вытащить можно, что подтверждает тот факт, что синтаксические конструкции языка также играют важную роль в понимании текста человеком.
VD>Так вот нет никакой зависимости между простотой граматики и простотй воспритяи (чтения) кода на этой граматике. БрэйнФак и регекспы это и демонстрируют. В то же время языки с более сложной граматикой зачастую бывают более понятны человеку (легче читаются) нисмотря на то, что обладают большим количеством грамматических кострукций.
Мне кажется, что как раз такая зависимость есть. Как я уже писал выше, навскидку можно выделить две сложности языка: количество связей между сущностями языка и качество таких связей. Если задавать языки порождающей граматикой, то иерархия Хомского отражает качество или "сложность" таких связей, а количество правил граматики, а также некоторые другие параметры, о которых я здесь не хочу говорить, отражают количество связей. Так что все правы, победила дружба, как говорится.
VD>Причем зависимости нет не только прямой (проще граматика проще читать), но и обратной (сложнее грамматика, сложнее читать).
Мы же здесь говорим о синтаксисе, а не о семантике. Т.е. мы абстрагируемся сейчас от семантики, полагая, что смысл лексем языка понятен не зависимо от качества грамматики, посредством которой данный язык выражается. В нашем, конкретном случае, и в Обероне и в Си++ выражены примерно одни и те же концепции, которые понимаются современным программистом среднего уровня.
С другой стороны, я конечно, не знаток Оберона, но мне кажется, что Си++ сложен, если так можно выразиться, концептуально. Т.е. в нем "больше идей", типа обобщенного программирования и программирования времени компиляции. Эти идеи для реализации используют старый синтаксис, поэтому часто получается неоднозначность, т.е. качество (сложность) связей повышается. Точно также происходит и в естественном языке, для новых областей знания используются старые термины ивыражения, только в новом значении, которое часто тесно связано со старым. В языках, писавшихся "с нуля" подобная эволюция не прослеживается. Но, если язык удачен и принят многими в программистком сообществе, то его "эволюция" в направлении увеличения качественной сложности неизбежна.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Видишь ли. Ты сам жульничаешь. Разберём твои же примеры: AF>Ты ведь пишешь 12345.6787E-26, а не .00000000000000000000000000123456787 AF>Аналогично пишешь "+7 (123) 45-67-89", а не +7123456789, а ведь грамматика стала ещё проще! AF>Но ведь про то, что читать стало легче ты, надеюсь, утвержать не будешь? AF>То есть что ты сам делаешь? Ты сознательно повышаешь сложность грамматики, что бы повысить читаемость — улучшить восприятие твоего кода человеком.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, Курилка, Вы писали:
К>>>Специально для тебя повторяю аналогию: К>>>Есть грамматика Оберона, есть программы на Обероне, есть данные, с которыми работает программа Оберона. К>>>Есть грамматика рег. выражений, есть сами рег. выражения, есть строки, которые удовлетворяют этим выражениям. К>>>Надеюсь, что уж достаточно разжевал
СГ>>Ну и? Будет сегодня хоть один пример трудно читаемой строки порожденной регулярной грамматикой?
SJA>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая. SJA>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Лёгкость чтения это то на сколько легко можно мысленно построить дерево разбора выражения. Понятно, что деревья разбора легче строить для LL(1) грамматики или, вообще, для регулярной. Опять же не надо забывать про размер грамматик. Конечно всегда можется статься так, что какая-нибудь простая но слишком объемная LL(1) грамматика может проиграть какой-нибудь контекстно зависимой, но чрезвычайно компактной грамматике. Так что, для справедливости, сравнивать надо грамматики примерно одинакового объема.
Нда. Тяжулый случай.
Ну, давай попробуем по другому...
Ты не будешь спорить что с точки зрения грамматики Оберон очень значительно проще чем C# 2.0?
Если не будешь, то следующий вопрос...
Ты знаком с паттерном "Итератор"? Ну, предоставление поседовательного доступа (перебора) к некоторой коллекции. Будь добр, продемонстрируй реализацию этого паттерна на Обероне. В качестве коллекции вопсользуйся банальным массивом. Создай функцию на входе которой будет массив, а на выходе объект-итератор позволяющий перебрать элементы массива.
Потом я приведу решение на C# 2.0 и сравним что проще читается и вообще что проще.
ОК?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Володя, ты хочешь сказать, что регулярные выражения не описываются никакой грамматикой? То, что рег. выражения есть грамматика я вообще-то не говорил (но утверждали некоторые в т.ч. СГ)
Ага, понял, ты имеешь ввиду язык регулярных выражений как целевой язык, а его грамматику как целевую грамматику? Но, тогда язык РЕ не описывается регулярной грамматикой, там же иерархия явная, куча вложенных скобок. По своему опыту могу сказать, что там КС-грамматика. Поэтому, пример все-равно не катит. Трудность в тех примерах, которые ты привел, заключается просто в отсутствии навыков чтения РЕ. В этом языке нет знакомых нам конструкций, типа ключевых слов, вытащенных из английского языка, и потому понятных всем. При некотором опыте сформируются связи между понятием и его графическим изображением, и все будет читаться легко.
Dog>По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все-рвано ткест чтаитсея без побрелм. Пичрионй эгото ялвятеся то, что мы не чиатем кдаужЮ бкуву по отдльенотси, а все солво цликеом.
Dog>
Это только, когда пробелы между словами есть. А их стали ставить совсем недавно. Старославянская писменность все без пробелов, что естественно, так как мы воспринимаем слова на слух тоже без пробелов. В общем, очередное подтверждение важности правильного форматирования .
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Видишь ли. Ты сам жульничаешь. Разберём твои же примеры: AF>>Ты ведь пишешь 12345.6787E-26, а не .00000000000000000000000000123456787 AF>>Аналогично пишешь "+7 (123) 45-67-89", а не +7123456789, а ведь грамматика стала ещё проще! AF>>Но ведь про то, что читать стало легче ты, надеюсь, утвержать не будешь? AF>>То есть что ты сам делаешь? Ты сознательно повышаешь сложность грамматики, что бы повысить читаемость — улучшить восприятие твоего кода человеком.
СГ>Идея хорошая, я обязательно над ней подумаю.
Только очень надеюсь, что ты её правильно понял. Потому, как я вообще то, говорил о балансе. Доведя до крайней формы практически любую идею можно получить нечто ужасное. Ты ведь на машину Тьюринга с примитивной грамматикой не пересаживаешься, бросив любимый Оберон? И не бросаешься писать на ассемблере — который обладает более простым синтаксисом, чем Оберон, да в добавок позволяет писать наиболее эффективный код из всех возможных вариантов? Но ведь и на каком-нибудь заумном языке с навороченным синтаксисом тоже не пишешь? То есть ты просто выбрал для себя нечто среднее, компромисное, сбалансированное. Вот такой же комплексный, системный подход я тебя и призаваю применить к анализу читабельности кода.
> B>Так чтоже делает эта программа?
> Я так понял, Сергей хочет сказать, что, чем проще грамматика, тем проще понять, что написано с грамматической точки зрения. Вы же все приводите примеры с трудной семантикой, это совсем другое.
, что один язык "более удобен для чтения" на основании того, что описывается простой грамматикой, LL(1). Более того, даже пояснил, что речь идет о понимании смысла написанного. А теперь, когда ему привели множество примеров, их смысл он отказывается понимать, сводя весь анализ приводимых примеров к синтаксическому разбору.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Это скорее не программы, а средства просмотра программ обепечивают.
Да. Но тем не менее если подсветка есть, то проще выделить базовые элементы и код воспринимается проще. И так везде. Даже вот лиспари умудряются код подсвечивать. И даже говорят, что мол вам не понятен код на Лиспе потому что нет подсветки.
E> На самом деле идеально, когда программа читается даже будучи распечатаной в моноширинном шрифте без каких либо ухищрений (вроде выделения отдельных лексем жирным/подчеркиванием).
Даже самый идеальный код будучи подсвеченным будет читаться еще лучше.
VD>>5. При написании которых использовались высокоуровневые операторы и функции.
E>А вот это не всегда так. Вот наглядный пример: Re: boost::multi_index + boost::tuple
Это пример эмуляции пдобных конструкций. Если бы они были именно конструкциями языка, и не содержали много лишнего, то читаемость была бы куда лучше.
Сравни к примеру работу с функциями высшего порядка в С++ и в любом ФЯ. Да что там ФЯ? Даже в C# 2.0 работа с ними выглядит прекрасно. А в С++ из-за эмуляции все превращается в кошмар.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>Насчет сложности, мне кажется, что можно выделить две сложности: иерархическую или реляционную и, если можно так выразиться, объемную. То, о чем говорит Сергей Губанов, это иерархическая сложность, в зависимости от типа грамматики, возрастает число различных связей между сущностями языка. Даже, я бы сказал, качество этих связей. Например, такая-то строка может быть в языке только, если впереди есть семь таких же строк. С этой точки зрения Губанов прав. Есть еще сложность как количество таких связей в грамматике. Вот это объемная сложность, в автомате выражающаяся через количество состояний.
Мне кажется, что ты как и Губанов ошибашся. Только Губанов ошибается так как просто неспособен адекватно оценить реальность. А на тебя слишком сильно давлеет профессиональный опыт.
Простота и сложность восприятия человеком (а именно об этом вроде бы мы все тут говорим) определятся куда большим количеством факторов. А вот как раз LL(1) тут ни на что не влияет.
Человек не компьютер. Он на уровне подсознания существо параллельное. Мы не читаем поток символов слева на право. Мы даже не читаем отдельные символы. Мы воспринимаем слова целиком и даже объеденяем их в предложения и абзацы. Мы можем даже не заметить мелких ошибок (иначе как бы вы все тут меня читали ), так как наш мозг просто отбрасывает их в следствии не существенности.
Так же мы воспринимаем и программы. Мы не LL(1)-сканер. Мы воспринимаем придложение. Когда я вижу кострукцию:
foreach (a in list)
f(a);
то я сначала улавливаю, что это перебор коллекции. Потом я обращаю внимание на то, что за коллекция. Потом забываю об этом и сосредотачиваюсь на том что творится с каждым ее элементом. В этот момент я конечно подразумеваю, что речь идет о итерации, но я уже мысленно абстрагировался от этого.
Для меня совершенно все равно как будет записан данный код. Если он будет выглядеть так:
list.ForEach(f);
то в отличии от компилятора, я восприйму этот код точно так же, так как я выделяю главную суть кода. Я распознаю паттерн и абстрагируюсь от него.
А ведь код просто таки развернулся с точностью до наоборт. Теперь, чтобы понять смысл конструкции прийдется дочитать его до конца.
А вот если точно тот же код записать как-то так:
foreach(a ib list)f(a);
то мое восприятие резко ухудшится. А если еще выключить подсветку синтаксиса:
foreach(a ib list)f(a);
то в куче другого кода я вообще начну теряться. В то же время для LL(1)-парсера все это не существенно.
Теперь перейдем к простоте. Более простой язык не обладает теми самыми паттернами или конструкциями для их реализации. Стало быть тот же самый паттерн прийдется записать куда более громоздкой конструкцией:
IEnumerator enumList list = .GetEnumerator();
while (enumList.MoveNext())
f(enumList.Current);
или
for (int i = 0; i < list.Count; i++)
f(list[i]);
на Обероне пусть пишет Губанов. Думаю, будет еще хуже.
Так вот все это ухудшает восрпиятие человеком. По этому скорее язык обладающий более сложным синтаксимом но позвляющий более кратко и интуитивно записать конструкцию окажется для меня более понятным.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>Ага, понял, ты имеешь ввиду язык регулярных выражений как целевой язык, а его грамматику как целевую грамматику? Но, тогда язык РЕ не описывается регулярной грамматикой, там же иерархия явная, куча вложенных скобок. По своему опыту могу сказать, что там КС-грамматика. Поэтому, пример все-равно не катит.
Пример катит, так как Губанов делал свои утверждения на базе LL(1) грамматики. РВ как раз можно описать LL(1)-грамматикой.
M> Трудность в тех примерах, которые ты привел, заключается просто в отсутствии навыков чтения РЕ.
Нет. Трудность именно в плохой читаемости. То же описание в EBNF будет читаться без запинки с теми же навыками.
M> В этом языке нет знакомых нам конструкций, типа ключевых слов, вытащенных из английского языка, и потому понятных всем.
В EBNF тоже нет. Но это ничего не менят. Главная разница в том, что в EBNF нам есть за что зацепиться. Мы можем выделить понятийные сущности в правила. Отделить пробелами части. Выделить участки грамматики которые яыляются чистыми образцами и части которые являются использованием правил.
M> При некотором опыте сформируются связи между понятием и его графическим изображением, и все будет читаться легко.
При некотором опыте и БрэйнФак можно привыкнуть читать. Только у нас разговор не о возможностях человеческого мозга адаптироваться к самым бредовым извращениям. А о простоте восприятия и о том, от чего она зависит.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
SJA>>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая. SJA>>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?
SJA>>
...
СГ>Increment the byte at the pointer СГ>Increment the byte at the pointer СГ>... СГ>и т.д.
СГ>А что, у Вас были какие-то проблемы с парсингом этого выражения?
Ну, раз никаких проблем у вас с этим кодом нет, то что он делает ? Думаю это несложно сказать, раз всё так просто читается ?
Здравствуйте, cranky, Вы писали:
SJA>>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая. SJA>>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?
C>[...]
C>Э-э, вопрос этики?
Здравствуйте, mefrill, Вы писали:
M>С другой стороны, я конечно, не знаток Оберона, но мне кажется, что Си++ сложен, если так можно выразиться, концептуально.
Ну, С++ действительно сложно воспринимать. Для сравнения лучше брать Шарп. Его граматика значительно сложее чем даже С++-ная. Но программы на нем читаются даже лучше чем на Обероне. А это уже полный парадокс если принять за правду утверждение Губанова о том, что простая LL(1)-граматика воспринимается человеком проще.
Граматика Шарпа довольно часто вообще не соотвествует LL(1). То и дело приходится заглядывать вперед и даже вставлять разные левые контексные правила.
M> Т.е. в нем "больше идей", типа обобщенного программирования и программирования времени компиляции. Эти идеи для реализации используют старый синтаксис, поэтому часто получается неоднозначность, т.е. качество (сложность) связей повышается. Точно также происходит и в естественном языке, для новых областей знания используются старые термины ивыражения, только в новом значении, которое часто тесно связано со старым. В языках, писавшихся "с нуля" подобная эволюция не прослеживается. Но, если язык удачен и принят многими в программистком сообществе, то его "эволюция" в направлении увеличения качественной сложности неизбежна.
Наверно. Но вопрос то не в этом. Вопрос в том, что человек не прасер. У него нет пробелм в заглядывании в перд. Более тог, он вообще легко и безошибочно пропускает целые части выражений. Например:
try
{
куча кода
...
}
catch (Xxx xx)
{
}
для сразу равно воспринимается как обработка исключения Xxx. У меня нет проблем в заглядывании. Я так же спокойно пропущу все параметры и посморю на тело фукнции. Или мне все равно где описывается тип возвращаемого значения функции.
В общем, мы не парсеры. И критерии применимые для оценки сложности пареров не применимы к людям.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> M> Т.е. в нем "больше идей", типа обобщенного программирования и программирования времени компиляции. Эти идеи для реализации используют старый синтаксис, поэтому часто получается неоднозначность, т.е. качество (сложность) связей повышается. <...> > > Наверно. Но вопрос то не в этом. Вопрос в том, что человек не прасер. У него нет пробелм в заглядывании в перд.
В случае C++ mefrill прав: (внешне) одна и та же конструкция может означать разные вещи, и заглядыванием вперед, в отличие от того же C#, эти неоднозначности не разрешаются.
Например:
C();
Если С — тип, то это создание временного объекта, иначе — вызов функции.
Еще:
class C;
C c(A());
Если A — тип, то это объявление функции, иначе — определение переменной.
Или:
C < a > b;
Если C — шаблон, то это определение переменной типа C<a>, иначе — вызов операций сравнения (C < a) > b.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В прошлый раз, делая это утверждение, ты так и не обосновал его. Так что лучше в качестве аргумента его не использовать...
Тебе показалось. Сравни размер граматик и даже вопрос не возникнет.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В случае C++ mefrill прав: (внешне) одна и та же конструкция может означать разные вещи, и заглядыванием вперед, в отличие от того же C#, эти неоднозначности не разрешаются.
Дык тогда о чем речь. Губанов то именно про необходимость заглядывания говорит. Мол не надо заглядвать — кода на языке читается просто. Надо — сложно.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>В прошлый раз, делая это утверждение, ты так и не обосновал его. Так что лучше в качестве аргумента его не использовать...
> Тебе показалось. Сравни размер граматик и даже вопрос не возникнет.
Это не сложность, а объем. Суть ортогональные вещи. Можно "наколбасить" регулярную грамматику, заметно большего объема, чем какую-нибудь КЗ-грамматику. От этого она станет объемнее, а не сложнее.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это не сложность, а объем. Суть ортогональные вещи. Можно "наколбасить" регулярную грамматику, заметно большего объема, чем какую-нибудь КЗ-грамматику. От этого она станет объемнее, а не сложнее.
В граматике сложность и определяется объемом. Ты же говоришь о семантической сложности.
Собственно опять таки исходим из Губановских данных.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> В случае C++ mefrill прав: (внешне) одна и та же конструкция может означать разные вещи, и заглядыванием вперед, в отличие от того же C#, эти неоднозначности не разрешаются.
> Дык тогда о чем речь. Губанов то именно про необходимость заглядывания говорит. Мол не надо заглядвать — кода на языке читается просто. Надо — сложно.
Имхо, то о чем говорит mefrill (количество "идей" и сложность связей между ними), более интересно. И упоминаемая им неоднозначность, имхо, тоже напрямую связана со сложностью чтения.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Имхо, то о чем говорит mefrill (количество "идей" и сложность связей между ними), более интересно. И упоминаемая им неоднозначность, имхо, тоже напрямую связана со сложностью чтения.
Опять таки возможно. Но причем тут Губановское утверждение о том, что простую LL(1)-грамматику проще читать человеку?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>Это не сложность, а объем. Суть ортогональные вещи. Можно "наколбасить" регулярную грамматику, заметно большего объема, чем какую-нибудь КЗ-грамматику. От этого она станет объемнее, а не сложнее. > > В граматике сложность и определяется объемом.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А такая регуларная грамматика читается очень легко: Берем и считываем следующий символ и ищем его в таблице ASCII символов, если находим, значит хорошо, мы поняли написанное, в противном случае констатируем синтаксическую ошибку.
Ты что, правда, не понимаешь?
Ты же кандидат наук, ну не верю, что ты совсем не соображаешь, с другой стороны, не хочется верить, что ты намеренно подменяешь предмет обсуждения с легкости понимания смысла кода на легкость его грамматического разбора.
Ты говоришь: "если находим, значит хорошо, мы поняли написанное" — так вот мы ничего не поняли, кроме того, что данный текст грамматике соответствует и компилятор не выдаст на него синтаксической ошибки.
Не более того.
Но к СМЫСЛУ написанного, к пониманию цели написанного кода тебя это не приблизит никак.
Если ты видишь выражение типа i++, ты понимаешь, что это постинкремент, но без знания того, что такое i, ты не можешь сказать о коде абсолютно ничего осмысленного.
Если ты видишь "WHILE ... DO ... END", ты можешь только сказать ,что в программе есть цикл, но это примерно соответствует ценности информации, содержащейся в знаменитой фразе "У ней внутре неонка".
Главное для языка программирования — чтобы человек понимал ОБЩИЙ СМЫСЛ написанного с первого взгляда.
И все. Понимаешь?
То же самое относится к естественным языкам: их грамматика на порядок сложнее и контекстно-зависимее любого из компьютерных языков, тем не менее человек понимает смысл написанного сразу же. Более того, он поймет даже неграмотно написанный текст, т.е. текст, который грамматике не соответствует.
Так что тип грамматики на читабельность текста программы не оказывает никакого влияния.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Всё предельно просто: читаете символ, смотрите в таблицу что он обозначает, вот и всё. Никаких заглядываний вперед, ни какой контекстной зависимости. Всё элементарно.
Здравствуйте, jazzer, Вы писали:
J>Ты что, правда, не понимаешь? J>Ты же кандидат наук, ну не верю, что ты совсем не соображаешь
Прошу никого не воспринимать мое высказывание как переход на личности, но...
У нас в фирме работали два доктора наук в разное время... (скажу сразу, что недолго работали). Оба — совершенно невменяемые Боюсь, что в нашей стране это становится тенденцией.
Здравствуйте, VladD2, Вы писали:
VD>Опять таки возможно. Но причем тут Губановское утверждение о том, что простую LL(1)-грамматику проще читать человеку?
Я имел ввиду связь между иерархией Хомского и сложностью понимания языка. Т.е. мне казалось, что вопрос стоял гораздо шире. Относительно же утверждения про LL(1)-грамматику, то здесь, вероятно, есть доля истны. Число связей, в сравнении с КС-грамматикой без ограничений, ограничено. Ну например, неоднозначные грамматики не могут быть LL(1), уже много для легкости понимания выигрывается. Согласен, что человек — не парсер, и процесс чтения текста им, это совсем не то, что процесс чтния текста машиной. Мой руководитель любит говорить, что если для передвижения человек изобрел колесо — свой способ, которого нет в природе, то для чтения были изобретены порождающие грамматики — метод чтения, которого нет в природе. Иначе говоря, порождающие грамматики — это этакое колесо в линвистике. Но, вот оказывается, что иерархия грамматики отражает синтаксическую сложность структуры языка. Как человек ее в себе держит и какие процессы протекают у него во время чтения, мы сказать не можем. Но, мы можем сказать несомненно, что сложность вместе с иерархией увеличивается. В случае с LL(1)-грамматиками связь, конечно, очень тонкая и не столь ощутимая, здесь бОльшую роль играют другие факторы: адекватное выражение синтаксических конструкций графически, связь с программисткой традицией, обозначение ключевых слов и т.д. Вот, например, введение в язык оператора цикла с параметром: for( ; ; ) {}. Ну кто может жогадаться, что третья конструкция должна выполняться ПОСЛЕ исполнения тела цикла? Дя человека гораздо естественнее было бы что-то типа for( ; ) {}(поститерация). Но мы воспринимаем сейчас эту неестественную конструкцию как само собой разумеещуюся. Размещение указателя на конструкцию в заключительной метке блока "end метка" традиционно решается форматированием и не засоряет код программы мусором. В общем, Оберон кажется сложнее для чтения именно из-за противостояния сишной традиции, которая есть, на смаом деле, традиция программисткого сообщества. И здесь, конечно, сложность грамматики отходит на второй план. Но, если ставить вопрос обощенно, то несоменно, при прочих равных условиях, язык, определяемый LL(1)-грамматикой, читать легче, нежели язык, определяемый КС-грамматикой без ограничений.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Здравствуйте, cranky, Вы писали:
SJA>>>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая. SJA>>>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?
C>>[...]
C>>Э-э, вопрос этики?
SJA>Э-э... Не понял вопроса...
Здравствуйте, mefrill, Вы писали:
M>Но, если ставить вопрос обощенно, то несоменно, при прочих равных условиях, язык, определяемый LL(1)-грамматикой, читать легче, нежели язык, определяемый КС-грамматикой без ограничений.
Человек действительно НЕ читает текст слева направо, так же как и не читает справа налево — он читает сразу целыми кусками, переходя от целого к деталям. Во всяком случае, человек, который не является начинающим в чтении.
Поэтому значение имеет только узнаваемость отдельных конструкция языка. Которая абсолютна ортогональна величине значения k в LL.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, jazzer, Вы писали:
J>>Ты что, правда, не понимаешь? J>>Ты же кандидат наук, ну не верю, что ты совсем не соображаешь
Д>Прошу никого не воспринимать мое высказывание как переход на личности, но... Д>У нас в фирме работали два доктора наук в разное время... (скажу сразу, что недолго работали). Оба — совершенно невменяемые :xz: Боюсь, что в нашей стране это становится тенденцией.
Просто я, будучи отчасти (от скромности не умру, ага) ученым-физиком, имел удовольствие общаться с очень умными людьми, причем обладавшими
1) большой гибкостью ума
2) параноидальной честностью и точностью.
Т.е. ситуации типа наблюдаемой здесь (в регэкспами) мне в научной среде казались в принципе невозможными, просто потому что я с ними не встречался, хотя общался с очень многими учеными.
Здравствуйте, Сергей Губанов, Вы писали:
SJA>>Да. Пожалста. Вот вам пример на BF. Граматики под руками нет, но думаю она вполне простая. SJA>>Что программа делает думаю объяснять не надо ? Ведь всё хорошо читается ?
SJA>>
...
СГ>Increment the byte at the pointer СГ>Increment the byte at the pointer СГ>... СГ>и т.д.
СГ>А что, у Вас были какие-то проблемы с парсингом этого выражения?
Ну, раз никаких проблем у вас с этим кодом нет, то что он делает ? Думаю это несложно сказать, раз всё так просто читается ?
Здравствуйте, VladD2, Вы писали:
VD>Простота и сложность восприятия человеком (а именно об этом вроде бы мы все тут говорим) определятся куда большим количеством факторов.
С этим абсолютно солидарен.
VD>А вот как раз LL(1) тут ни на что не влияет.
А с этим не согласен. Ограничение на грамматику означает ограничение на сложность структуры языка, что в свою очередь, означает ограничение на его сложность при понимании. Поэтому, я бы сказал так: простота и сложность восприятия человеком языка определяется множеством факторов, и в том числе, ограничением на структуру порождающей грамматики языка.
VD>Человек не компьютер. Он на уровне подсознания существо параллельное. Мы не читаем поток символов слева на право. Мы даже не читаем отдельные символы. Мы воспринимаем слова целиком и даже объеденяем их в предложения и абзацы. Мы можем даже не заметить мелких ошибок (иначе как бы вы все тут меня читали ), так как наш мозг просто отбрасывает их в следствии не существенности.
Согдасен полностью. Порождающие грамматики — колесо лингвистики. Но, часть сысла вытекает из синтаксической структуры языка. Следовательно, чем сложнее синтаксическая структура языка, тем сложнее понять его смысл (не принимая во внимание другие факторы).
VD>Так вот все это ухудшает восрпиятие человеком. По этому скорее язык обладающий более сложным синтаксимом но позвляющий более кратко и интуитивно записать конструкцию окажется для меня более понятным.
И с этим соглашусь. Но, повторюсь, для меня вопрос стоял не в том, что ТОЛЬКО структура грамматики языка определяет его читабельность (иначе бы, маткематические статьи было также легко читать как анекдоты), а в том, что она определяет читабельность (легкость восприятия) в числе многих факторов.
Вношу изменения в свой тезис: "Чем проще грамматика тем легче читать/писать текст". Для компилятора — это так (без компромисов), но для человека есть по крайней мере еще два фактора которые необходимо учитывать.
Во-первых, это объем грамматики. У человека конечный объем памяти который он использует для мысленного разбора читаемого выражения, поэтому даже если грамматика будет простая, но слишком объемная, то она может не убраться целиком в голове, в связи с чем человек будет испытывать трудности. Тем не менее, при условии равноценных объемов, конечно же выигрывает более простая грамматика.
Во-вторых, для человека играет большую роль оформление/форматирование текста. То есть грамматика не должна быть слишком простой, а как минимум должна предоставлять возможность форматировать текст так как это нравится человеку. То есть, если есть такая возможность, то не надо упрощать грамматику до абсолютного минимума, а надо упрощать ее лишь до разумно оправданного минимума, который оставляет определённую (калибровочную) свободу в форматировании текста согласно вкусам и предпочтениям человека.
Вывод:
Сделай грамматику меньше и проще на столько на сколько это возможно, но не меньше и не проще чем это необходимо для возможности (разумного) форматирования текста согласно вкусам и предпочтениям человека.
Здравствуйте, Дарней, Вы писали:
Д>У нас в фирме работали два доктора наук в разное время... (скажу сразу, что недолго работали). Оба — совершенно невменяемые Боюсь, что в нашей стране это становится тенденцией.
Ага, эти ученые, они же просто придурки все, сумасшедшие. (крэзи саенсист)
E>>с ходу далеко не у всех получится.
VD>Это пример эмуляции пдобных конструкций. Если бы они были именно конструкциями языка, и не содержали много лишнего, то читаемость была бы куда лучше.
VD>Сравни к примеру работу с функциями высшего порядка в С++ и в любом ФЯ. Да что там ФЯ? Даже в C# 2.0 работа с ними выглядит прекрасно. А в С++ из-за эмуляции все превращается в кошмар.
Необорот, это сама по себе высокоуровневая конструкция, которая дает короткий псевдоним (my_container) сложному типу, а именно -- контейнеру, элементами которо являются tuple (с именем my_type), поддерживающий три индекса: по каждому из элементов tuple в отдельности. Думаю, что для предоставления такого контейнера на C# или Java пришлось бы попотеть гораздо больше.
Но вот читабелность такого выражения имхо, оставляет желать много лучшего.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>Поэтому значение имеет только узнаваемость отдельных конструкция языка. Которая абсолютна ортогональна величине значения k в LL.
Это поверхностное понимание того, что такое LL(k)-грамматика. На самом деле, ситуация гораздо глуже, LL(k) ограничение ограничивает также и качество структурных связей языка, т.е. его структурную сложность. То, что это выражается в линейном процессе чтения, это уже совсем другой и, думается, более сложный вопрос о взаимосвязи линейных процессов (в данном случае, алгоритмов) обработки языка и семантики языка.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mefrill, Вы писали:
M>>Ага, понял, ты имеешь ввиду язык регулярных выражений как целевой язык, а его грамматику как целевую грамматику? Но, тогда язык РЕ не описывается регулярной грамматикой, там же иерархия явная, куча вложенных скобок. По своему опыту могу сказать, что там КС-грамматика. Поэтому, пример все-равно не катит.
VD>Пример катит, так как Губанов делал свои утверждения на базе LL(1) грамматики. РВ как раз можно описать LL(1)-грамматикой.
M>> Трудность в тех примерах, которые ты привел, заключается просто в отсутствии навыков чтения РЕ.
VD>Нет. Трудность именно в плохой читаемости. То же описание в EBNF будет читаться без запинки с теми же навыками.
M>> В этом языке нет знакомых нам конструкций, типа ключевых слов, вытащенных из английского языка, и потому понятных всем.
VD>В EBNF тоже нет. Но это ничего не менят. Главная разница в том, что в EBNF нам есть за что зацепиться. Мы можем выделить понятийные сущности в правила. Отделить пробелами части. Выделить участки грамматики которые яыляются чистыми образцами и части которые являются использованием правил.
M>> При некотором опыте сформируются связи между понятием и его графическим изображением, и все будет читаться легко.
VD>При некотором опыте и БрэйнФак можно привыкнуть читать. Только у нас разговор не о возможностях человеческого мозга адаптироваться к самым бредовым извращениям. А о простоте восприятия и о том, от чего она зависит.
Здравствуйте, VladD2, Вы писали:
VD>В EBNF тоже нет. Но это ничего не менят. Главная разница в том, что в EBNF нам есть за что зацепиться. Мы можем выделить понятийные сущности в правила. Отделить пробелами части. Выделить участки грамматики которые яыляются чистыми образцами и части которые являются использованием правил.
Не совсем понял, причем здесь EBNF? Что мы сравниваем, легкость чтения EBNF и РВ? но, какое тогда это отношение имеет к осуждаемому вопросу?
ПК>>Регулярные выражения описываются регулярной грамматикой. Еще проще чем LL(1). Читаются очень нелегко, если нет соответствующего навыка.
СГ>Ну и где эти контр примеры? Давайте же, приводите текст на регулярном языке.
СГ>"+123456789E-64" — такой текст сложен?
СГ>"+7 (1234) 63-74-72" — а может такой текст сложен?
Это не текст "программы" на регулярных выражениях. Это — данные для такой программы. А вот программа на РВ, обрабатывающая такие данные, даже такие простые данные, уже будет на грани непонимания.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Вношу изменения в свой тезис: "Чем проще грамматика тем легче читать/писать текст". Для компилятора — это так (без компромисов), но для человека есть по крайней мере еще два фактора которые необходимо учитывать.
<...bla-bla-bla поскипаны...>
СГ>Вывод: СГ>
СГ>Сделай грамматику меньше и проще на столько на сколько это возможно, но не меньше и не проще чем это необходимо для возможности (разумного) форматирования текста согласно вкусам и предпочтениям человека.
На восприятие текста программы влияет намного больше факторов, чем здесь упомянуто. И простота/сложность грамматики вообще не имеет значения, когда мы хотим понять _смысл_ программы. Еще сложнее, когда мы пытаемся проанализировать программу и представить себе, чем она нам грозит.
Например, возьмем абстрактное выражение:
a = b + (c - d)/2;
Очевидно, что оно описывается весьма простой грамматикой.
Понятен ли нам его смысл?
Вряд ли, т.к. не известно, что такое a, b, c, d.
Предположим, что это объекты каких-то классов.
Стало понятнее?
Пойдем дальше. Предположим, что операции могут порождать исключения.
Сколько исключений здесь может быть потенциально порождено?
Как обеспечить гарантию безопасности исключений для этого выражения?
А при наличии side-эффектов?
Блин, Сергей Губанов просто монстр какой-то! Целая ветка для того, чтобы убедить его в абсурдности предположения "Чем проще грамматика тем легче читать/писать текст". И все без толку.
Иконка "харакири" есть в планах RSDN Team?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Видишь ли. Ты сам жульничаешь. Разберём твои же примеры: AF>Ты ведь пишешь 12345.6787E-26, а не .00000000000000000000000000123456787 AF>Аналогично пишешь "+7 (123) 45-67-89", а не +7123456789, а ведь грамматика стала ещё проще! AF>Но ведь про то, что читать стало легче ты, надеюсь, утвержать не будешь?
AF>То есть что ты сам делаешь? Ты сознательно повышаешь сложность грамматики, что бы повысить читаемость — улучшить восприятие твоего кода человеком.
Вполне естественный процесс. Я уже где-то высказывался, что легкость и простота — синонимы далеко не всегда, так же, как трудность и сложность. Классический пример: чековек пытается взлететь. Прицепил к рукам крылья и начал ими махать — простейший способ. Однако так взлететь человек не сможет никогда. Облегчить себе жизнь человек смог, пойдя по пути гораздо более сложному — построив самолет.
Здравствуйте, eao197, Вы писали:
E> На восприятие текста программы влияет намного больше факторов, чем здесь упомянуто.
Возможно это так, но мне они не известны. Если они известны Вам, то будьте так любезны, сообщите их пожалуйста.
E> И простота/сложность грамматики вообще не имеет значения, когда мы хотим понять _смысл_ программы.
Прежде чем дойти до понимания смысла прочитанного выражения, сперва нужно суметь прочитать это выражение, то есть сперва нужно суметь провести синтаксический разбор этого читаемого выражения.
E>Блин, Сергей Губанов просто монстр какой-то! Целая ветка для того, чтобы убедить его в абсурдности предположения "Чем проще грамматика тем легче читать/писать текст". И все без толку.
Во всей той ветке, по делу было только два замечания (про объем и про форматирование) именно их-то я и учел в своем скорректированном тезисе:
Сделай грамматику меньше и проще на столько на сколько это возможно, но не меньше и не проще чем это необходимо для возможности (разумного) форматирования текста согласно вкусам и предпочтениям человека.
Здравствуйте, mefrill, Вы писали:
M>Это поверхностное понимание того, что такое LL(k)-грамматика. На самом деле, ситуация гораздо глуже, LL(k) ограничение ограничивает также и качество структурных связей языка, т.е. его структурную сложность.
Не совсем понятно. Каким образом ограничивает и что именно?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, eao197, Вы писали:
E>> На восприятие текста программы влияет намного больше факторов, чем здесь упомянуто.
СГ>Возможно это так, но мне они не известны. Если они известны Вам, то будьте так любезны, сообщите их пожалуйста.
Ну, например, "цель, с которой код программы читается".
Примеры:
-- я хочу понять алгоритм;
-- я хочу оценить примитивную безопасность кода (нет ли деления на ноль, обращения к повисшим/не инициализированным указателям, переполнения, неправильные преобразования типов и пр.);
-- я хочу оценить безопасность кода по отношению к исключениям;
-- я хочу оценить ресурсоемкость кода;
-- я хочу прикинуть приблизительное быстродействие кода;
...
-- я хочу посмотреть, используется ли где-нибудь комментарий:
/* А эти строчки вообще следовало бы выбросить нафиг! */
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>Не совсем понятно. Каким образом ограничивает и что именно?
Качество структурных связей языка. Например, неоднозначностей быть не может. Или больше, определенной ситуации, двух идущих подряд эпсилон-правил. Примеров таких можно привести много. Главное, что проще синтаксическая структура языка.
Здравствуйте, eao197, Вы писали:
E>Ну, например, "цель, с которой код программы читается".
Хороший пример.
Чувствую, что скоро мне придется еще больше уточнить свой тезис дополнив его словами, типа:
1) "Если Вы пишите текст для того чтобы....";
2) "Если Вы читаете текст для того чтобы...".
3) "Если Вы хорошо выспались, то..."
4) "Если Вы носите очки, но забыли их дома..."
...
Здравствуйте, mefrill, Вы писали:
M>Здравствуйте, Дарней, Вы писали:
Д>>Не совсем понятно. Каким образом ограничивает и что именно?
M>Качество структурных связей языка. Например, неоднозначностей быть не может. Или больше, определенной ситуации, двух идущих подряд эпсилон-правил. Примеров таких можно привести много. Главное, что проще синтаксическая структура языка.
Но для этого грамматика не обязательно должна быть LL(k), насколько я понимаю.
Здравствуйте, eao197, Вы писали:
E>На восприятие текста программы влияет намного больше факторов, чем здесь упомянуто. И простота/сложность грамматики вообще не имеет значения, когда мы хотим понять _смысл_ программы. Еще сложнее, когда мы пытаемся проанализировать программу и представить себе, чем она нам грозит.
Как раз значение имеет, но только как один из факторов. В лингвистике есть такое понятие как наследуемая (копозиционная) семантика. А наследуется семантика (т.е. смысл) из смысла лексем языка. Иначе говоря, мы определяем смысл предложения исходя из смысла слов и синтаксической структуры предложения. Понятно, что чем сложнее синтаксис, тем сложнее понять смысл предложения. Конечно, этим понимание не исчерпывается, смыслов у слов может быть много и смысл предложения зависит как от уже произнесенных ранее предложений, так и от еще непроизнесенных. Т.е. на самом деле, как говорит Кибрик, преложение никогда не заканчивается, поэтому порождающие грамматики Хомского не применимы для анализа естественных языков. Есть еще трудности, когда предложения с одинаковой синтаксической структурой имеют разный смысл несмотря не то, что смысл слов предложения один и тот же. Например, выражение "бить баклуши" имеет двойной смысл и здесь напрушается принцип композиционной семантики. Но синтаксис играет в понимании смысла определяющую роль.
E>Например, возьмем абстрактное выражение: E>
E>a = b + (c - d)/2;
E>
E>Очевидно, что оно описывается весьма простой грамматикой.
E>Понятен ли нам его смысл? E>Вряд ли, т.к. не известно, что такое a, b, c, d. E>Предположим, что это объекты каких-то классов.
Пример неадекватный. Если мы знаем смысл лексем, то определить смысл предложения нам будет тем проще, чем грамматика языка проще. Что значит проще? Я уже писал, что сложность исходного языка определяется сложностью грамматики этого языка. Грамматик у языка может быть бесконечное множество, но мы подразумеваем, что имеем самую простую, определяющую данный язык. Итак, существует иерархия Хомского для грамматик, что определяет качественную структурную сложность языка, т.е. качество его взаимосвязей. Также, можно определить объем грамматики, который определяет количественную сложность языка, выражающуюся в количестве структурных связей языка. Для одинаковых по качественной сложности языков грамматики могут существенно различаться по объему, что, очевидно, также влияет на сложность языков.
Здравствуйте, Дарней, Вы писали:
M>>Качество структурных связей языка. Например, неоднозначностей быть не может. Или больше, определенной ситуации, двух идущих подряд эпсилон-правил. Примеров таких можно привести много. Главное, что проще синтаксическая структура языка.
Д>Но для этого грамматика не обязательно должна быть LL(k), насколько я понимаю.
Насчет LL я не уверен, надо подумать, а вот, чтобы проверить грамматику на неоднозначность, можно построить LR-автомат. Если он будет детермииинированным, то это значит, что грамматика однозначная. Конечно это условие только необходимое, а не достаточное — существуют однозначные грамматики, для которых нельзя построить LR-автомат. Короче, смысл здесь в том, что есть ограничения, которые делают проще синтаксическую структуру языка.
Здравствуйте, mefrill, Вы писали:
E>>На восприятие текста программы влияет намного больше факторов, чем здесь упомянуто. И простота/сложность грамматики вообще не имеет значения, когда мы хотим понять _смысл_ программы. Еще сложнее, когда мы пытаемся проанализировать программу и представить себе, чем она нам грозит.
<...пространные объяснения после прочтения поскипаны...> M>Но синтаксис играет в понимании смысла определяющую роль.
Ну-ну, блажен кто верует.
E>>Например, возьмем абстрактное выражение: E>>
E>>a = b + (c - d)/2;
E>>
E>>Очевидно, что оно описывается весьма простой грамматикой.
E>>Понятен ли нам его смысл? E>>Вряд ли, т.к. не известно, что такое a, b, c, d. E>>Предположим, что это объекты каких-то классов.
M>Пример неадекватный.
Имхо, вполне адекватный.
M> Если мы знаем смысл лексем, то определить смысл предложения нам будет тем проще, чем грамматика языка проще. Что значит проще? Я уже писал, что сложность исходного языка определяется сложностью грамматики этого языка.
Нифига подобного. Добавте в язык поддержку исключений и перегрузку операторов, а попробуйте понять _смысл_ программы.
Возвращаясь к приведенному примеру -- что же это все таки такое?
Может быть сложение целых?
Или комплексных?
Или операции над векторами?
Или над множествами?
Но синтаксис при этом совершенно понятен.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Возвращаясь к приведенному примеру -- что же это все таки такое? E>Может быть сложение целых? E>Или комплексных? E>Или операции над векторами? E>Или над множествами? E>Но синтаксис при этом совершенно понятен.
Ситуация описанная Вами действительно имеет место быть, однако в данной ветке форума обсуждается только синтаксис, а именно влияние характеристик грамматики на легкость синтаксического разбора которое человек осуществляет у себя в голове при чтении текста.
Здравствуйте, Сергей Губанов, Вы писали:
E>>Возвращаясь к приведенному примеру -- что же это все таки такое? E>>Может быть сложение целых? E>>Или комплексных? E>>Или операции над векторами? E>>Или над множествами? E>>Но синтаксис при этом совершенно понятен.
СГ>Ситуация описанная Вами действительно имеет место быть, однако в данной ветке форума обсуждается только синтаксис, а именно влияние характеристик грамматики на легкость синтаксического разбора которое человек осуществляет у себя в голове при чтении текста.
Упс...
Ладно. Но тогда это напоминает абстрактное чтение абстрактных программ абстрактными программистами. Т.е., в переводе на фольклер -- поиск сферического коня в вакууме.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ситуация описанная Вами действительно имеет место быть, однако в данной ветке форума обсуждается только синтаксис, а именно влияние характеристик грамматики на легкость синтаксического разбора которое человек осуществляет у себя в голове при чтении текста.
Хм, изначально мелькали слова про "смысл", сейчас уже парсеры в голове... Синтаксический разбор в голове — это настолько несущественная мелочь, что даже и смотреть на нее не стоит... Причем доподлинно неизвестно, как этот разбор там (в голове) происходит. Уж деревья точно не строятся Я лично не ощущаю никаких сложностей, когда смотрю на заплюсованный код, как и не становится мне легче, когда я смотрю на паскалевый синтаксис.
Бодяга это все...
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Therion — Raven of Dispersion";
Здравствуйте, mefrill, Вы писали:
M>А с этим не согласен. Ограничение на грамматику означает ограничение на сложность структуры языка, что в свою очередь, означает ограничение на его сложность при понимании. Поэтому, я бы сказал так: простота и сложность восприятия человеком языка определяется множеством факторов, и в том числе, ограничением на структуру порождающей грамматики языка.
Сама сложность конечно влияет. Но для человека нет необходимости читать код с лева на право. Об этом я и виду речь.
M>Согдасен полностью. Порождающие грамматики — колесо лингвистики. Но, часть сысла вытекает из синтаксической структуры языка. Следовательно, чем сложнее синтаксическая структура языка, тем сложнее понять его смысл (не принимая во внимание другие факторы).
Опять не спорю. Но опять же причем тут LL(1)? Например, введение конекстного ключевого "partial" в C# 2.0 сильно усложнило создание парсера средствами построителей LL(1)-парсеров. Но для человекта никакой сложности нет. Мы легко отличаем где это просто имя идентификатора, а где ключевое слово.
M>И с этим соглашусь. Но, повторюсь, для меня вопрос стоял не в том, что ТОЛЬКО структура грамматики языка определяет его читабельность (иначе бы, маткематические статьи было также легко читать как анекдоты), а в том, что она определяет читабельность (легкость восприятия) в числе многих факторов.
Опять же не буду спорить. Именно многих факторов. И сложность граматики один из них. Но все не так прямолинийно как утвреждает губанов. Требования LL(1) точно не имеют ничего общего с требованиями мозга человека. И объем граматики может оказаться только плюсом если он содержит более ёмкие конструкции (конечно если они интуитивно понятны).
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>Не совсем понял, причем здесь EBNF?
При том что EBNF прекрасно подходит для описания регулярных граматик вроде РВ.
M> Что мы сравниваем, легкость чтения EBNF и РВ?
Да.
M> но, какое тогда это отношение имеет к осуждаемому вопросу?
EBNF в отличии от РВ обладает некоторым набором характеристик упрощающим восприятие описания для человека. В то же время РВ значительно проще для распознаования компьюетром.
Ну, а цель этого примера показать, что LL(1)-совместимость недостаточна для того чтобы язык стал простым.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>Вот, например, введение в язык оператора цикла с параметром: for( ; ; ) {}. Ну кто может жогадаться, что третья конструкция должна выполняться ПОСЛЕ исполнения тела цикла? Дя человека гораздо естественнее было бы что-то типа for( ; ) {}(поститерация). Но мы воспринимаем сейчас эту неестественную конструкцию как само собой разумеещуюся.
В том то и дело, что привыкли. Как я уже говорил, привыкнуть можно к чему угодно. Но зачем привыкать к плохому.
Есть же и Паскаль с прямолинейным и простым синтаксисом. И разеные Питоны с Руби где проблема for решена изумительно.
Как тебе вот такое решение:
foreach (int i in 0..2..100)
...
foreach (int i in Generator(start = 0, end = 100, step 3))
...
То есть вообще избавиться от императивного задания выполнения, а вместо этого задавать нужную информацию декларавтивно.
M> Размещение указателя на конструкцию в заключительной метке блока "end метка" традиционно решается форматированием и не засоряет код программы мусором. В общем, Оберон кажется сложнее для чтения именно из-за противостояния сишной традиции, которая есть, на смаом деле, традиция программисткого сообщества. И здесь, конечно, сложность грамматики отходит на второй план.
+1
M>Но, если ставить вопрос обощенно, то несоменно, при прочих равных условиях, язык, определяемый LL(1)-грамматикой, читать легче, нежели язык, определяемый КС-грамматикой без ограничений.
И все же я думаю, что на читаемость намного больше влияют другие фактроы.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>Здравствуйте, Дарней, Вы писали:
Д>>Поэтому значение имеет только узнаваемость отдельных конструкция языка. Которая абсолютна ортогональна величине значения k в LL.
M>Это поверхностное понимание того, что такое LL(k)-грамматика.
Э... LL(k) и LL(1) все же разыне вещи. LL(*) так вообще может описать почти все что нужно для ЯП.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>Качество структурных связей языка. Например, неоднозначностей быть не может.
Неоднозначностей может не быть и в не LL(1)-языке. В том же Шарпе не мало усилий было приложено на решение всех неоднозначностей.
M> Или больше, определенной ситуации, двух идущих подряд эпсилон-правил. Примеров таких можно привести много. Главное, что проще синтаксическая структура языка.
Не факт. Ты говоришь не о реальных языках, а о потенциальных возможностях. Вот в С++ действительно много неоднозначностей, что усложняет чтение коднов на нем. И то не всегда. А в Шарпе неоднозначностей (не разрешенных) нет. И получается, что при не совместимой с LL(1)-граматикой при том еще и довольно обемной код все же читается очень просто. Наличие же высокоуровневых конструкций хотя и усложныет краматику и семантику, но чтение только упрощает.
Прицип тут простой. Декларация понятнее императивного описания более низкоуровневыми средствами. А чтобы добиться большей декларативности унжно или иметь некие очень не простые механизым ее достижения, либо расширять и усложнять грамматику чтобы впихнуть в нее эти декларативные конструкции.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>Ага, эти ученые, они же просто придурки все, сумасшедшие. (крэзи саенсист)
Не обижайся. Разные бывают люди.
Но, кстати, не раз замечал, что у действительно талантливых людей частенько бывает сдвиг по фазе в том или ином направлении.
Видимо то что в одном применении является гениальным, в другом является совершенно не практичным. Мыслит человек по другому... Это позволяет ему увидеть то, что не видят другие. Но и то что другие видят он может не заметить или не понять. Селявя.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
M>Данные: <TAG[^>]*>(.*?)</TAG> (запись частично использует РВ)
Это не верная граматика. Например, она неверно распознает ХТМЛ вроде:
[c#]
<p id="a>">
[/c#]
M>Программа: <([A-Z][A-Z0-9]*)[^>]*>(.*?)</\1>
M>
Опять же очень упрощенная версия. Рельный регексп займет пол экрана и прочесть его будет ооОочень не просто.
Так что все намного сложнее. И мменно тут прекрасно проявляют себя более читаемые краматики вроде EBNF. Ввел правило писывающее строку и пиши на его базе другие:
Tag = '<' idenifier { Attribut } '>' { Tag | Text } '<' '/' idenifier '>'.
Attribut = idenifier [ '=' ( String | idenifier | Number ) ].
...
Вроде как длиннее. Вроде как сложнее. Но, что характерно, читается наааАаамного лучше.
Вопрос почему? Да все те же принципы:
1. Имеются средства структурирования — правила.
2. Паттерны текста хорошо отличаются от управляющих конструкций и правил. И их не нужно эскейпить.
3. Элементы граматики хорошо выделятся в тексте и могут быть отформатированы пробелами, табуляциями и концами строк для большей читаемости.
4. Производится абстрагирование от не важных вещей вроде пробелов.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
mefrill,
> если ставить вопрос обощенно, то несоменно, при прочих равных условиях, язык, определяемый LL(1)-грамматикой, читать легче, нежели язык, определяемый КС-грамматикой без ограничений.
Грубо говоря, похоже, что ты исходишь примерно из такой предпосылки: чем сложнее грамматика, тем больше возможностей написать на соответствующем языке непонятную программу. Это так. В теории. Однако, на практике есть и другой, имхо, более существенный фактор: более сложные языки (в т.ч. и синтаксически) дают большую свободу в выражении своих мыслей, и, соответственно, при сознательном стремлении написать понятную программу, очень вероятно, что на более сложном языке это может получиться лучше. Примеры привести легко:
тексты на естественных языках, обладающих очень высокой синтаксической сложностью по сравнению с языками программирования, понимать обычно проще, чем на последних;
BrainFuck потрясающе прост синтаксически, но совершенно недостаточен для возможности внятно выразить даже простейшую программу "Hello World":
принципиально более сложный C позволяет это сделать намного понятнее:
#include <stdio.h>
int main()
{
printf("Hello World!\n");
}
однако (и здесь мы возвращаемся к предполагаемой тобой предпосылке) он позволяет вытворить и такое:
#include"stdio.h"#define e 3
#define g (e/e)
#define h ((g+e)/2)
#define f (e-g-h)
#define j (e*e-g)
#define k (j-h)
#define l(x) tab2[x]/h
#define m(n,a) ((n&(a))==(a))
long tab1[]={ 989L,5L,26L,0L,88319L,123L,0L,9367L };
int tab2[]={ 4,6,10,14,22,26,34,38,46,58,62,74,82,86 };
int main(m1,s) char *s; {
int a,b,c,d,o[k],n=(int)s;
if(m1==1){ char b[2*j+f-g]; main(l(h+e)+h+e,b); printf(b); }
else switch(m1-=h){
case f:
a=(b=(c=(d=g)<<g)<'<g)<<g;
return(m(n,a|c)|m(n,b)|m(n,a|d)|m(n,c|d));
case h:
for(a=f;a=e)for(b=g<<g;b<n;++b)o[b]=o[b-h]+o[b-g]+c;
return(o[b-g]%n+k-h);
default:
if(m1-=e) main(m1-g+e+h,s+g); else *(s+g)=f;
for(*s=a=f;a<e;) *s=(*s<<e)|main(h+a++,(char *)m1);
}
}
хотя это и не BrainFuck, но понять очень сложно.
Резюме: имхо, говорить о читабельности языков столь же некорректно, как и говорить об их производительности. Вместо последнего стоит говорить о производительности конкретных реализаций. Вместо первого -- о читабельности конкретных программ.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Сергей! Ты действительно предложил лучший вариант, чем был изначально. Но дело тут вовсе не в тезисе.
Дело в том, что сама область настолько обширна, что просто-напросто не описывается разумным образом с помощью каких-либо тезисов.
Это как красивая девушка. Или красивая картина, интересный фильм, шикарный автомобиль или марочное вино. Можно выдвинуть сколько угодно тезисов — как верных так и не верных. И всё равно — тезисы это одно — а девушка как и картина — совсем другое.
Тут есть ещё одно интересное наблюдение. Умение выдвигать правильные тезисы относительно чьих-то картин ещё не означает способность создать нечто подобное и уж тем более — лучшее. Разве мало критиков, которые сами не в состоянии ничего сделать (в той области которую критикуют) — зато лезут со справедливой критикой?
В общем анализ — одно, а синтез или творчество — совсем иное. Спроси себя — зачем ты затеваешь все эти дискуссии? Если твоя цель — создать нечто своё — то как я только что показал — ты ошибочно выбрал дорогу. Если же цель — анализ ради анализа — то подумай — так ли это интересно для всех остальных? (Судя по реакции — по-моему не очень )
Чтобы внести чуть-чуть юмора...
AF> В общем анализ — одно, а синтез или творчество — совсем иное.
Синтез и творчество по отношению к картине -- понятно. И про автомобиль понятно. Даже про марочное вино понять можно.
Но вот синтез по отношению к девушке -- это как?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Не обижайся. Разные бывают люди.
А я и не обижаюсь . Просто, повертевшись лет этак 15 в научном сообществе, могу сказать, что там такие же люди, как и везде. Есть умные, есть глупые, есть талантливые и есть бездари. "Крэзи Саенсит" — это всего-лишь общественное клише, не более.
Здравствуйте, VladD2, Вы писали:
M>> Что мы сравниваем, легкость чтения EBNF и РВ? VD>Да.
Тогда мы имеем два целевых языка? EBNF и РВ. И две КС-грамматики для них? ТИ мы должны сравнить эти грамматики, а не сами языки?
M>> но, какое тогда это отношение имеет к осуждаемому вопросу? VD>EBNF в отличии от РВ обладает некоторым набором характеристик упрощающим восприятие описания для человека. В то же время РВ значительно проще для распознаования компьюетром.
Хорошо, как тебе такая EBNF:
A:B"45"CB:'3'+'G'*T'|HN:F':'K и т.д. Как вопринимается? И, кстати, попробуй прочитать это не слева направо, а иерархически.
VD>Ну, а цель этого примера показать, что LL(1)-совместимость недостаточна для того чтобы язык стал простым.
Я снова не понял цели. Есть сложное РВ. Как мы его рассматриваем? Как язык, о котором мы говорим и который задается другой КС-грамматикой и не является регулярным, или как способ задания регулярного языка? И где здесь LL(1)? Честно, я не понял о чем ты говоришь.
Здравствуйте, eao197, Вы писали:
E>Синтез и творчество по отношению к картине -- понятно. И про автомобиль понятно. Даже про марочное вино понять можно. E>Но вот синтез по отношению к девушке -- это как? Это про разработчиков... резиновых, наверное. Сначала долго анализируют, а потом синтезируют.
Здравствуйте, VladD2, Вы писали:
VD>Неоднозначностей может не быть и в не LL(1)-языке. В том же Шарпе не мало усилий было приложено на решение всех неоднозначностей. VD>Не факт. Ты говоришь не о реальных языках, а о потенциальных возможностях. Вот в С++ действительно много неоднозначностей, что усложняет чтение коднов на нем. И то не всегда. А в Шарпе неоднозначностей (не разрешенных) нет. И получается, что при не совместимой с LL(1)-граматикой при том еще и довольно обемной код все же читается очень просто. Наличие же высокоуровневых конструкций хотя и усложныет краматику и семантику, но чтение только упрощает.
Т.е. ты хочешь сказать, что LL(1)-граматика имеет меньше ограничений на синтаксис, чем не LL(1)-граматика??? Если нет, тогда о чем мы спорим?
VD>Прицип тут простой. Декларация понятнее императивного описания более низкоуровневыми средствами. А чтобы добиться большей декларативности унжно или иметь некие очень не простые механизым ее достижения, либо расширять и усложнять грамматику чтобы впихнуть в нее эти декларативные конструкции.
В выделенное не въехал. Почему понятнее? Кроме того, язык может быть и не декларативный и не императивный, а может сочетать в себе и то и другой, например, русский язык. Я уже несколько раз пытался объяснить: в лингвистике есть такой принцип композиционной семантики. Он говорит о том, что смысл предложения языка определяется смыслом входящих в предложение лексем и синтаксической конструкцией предложения. Хотя бывают, конечно, и исключения. Если отталкиваться от этого принципа, то при всех прочих равных факторах, чем сложнее структура предложения, тем сложнее его понимать. Что же здесь нелогичного?
Здравствуйте, eao197, Вы писали:
E>Чтобы внести чуть-чуть юмора...
Тут уже не чуть-чуть. Тут уже психиаторов пора вызывать...
E>Но вот синтез по отношению к девушке -- это как?
Да в общем то так же как и тысячу лет назад. Сообразить — что и как нужно сделать что бы с ней познакомиться и ей понравится. Подозреваю, что чем меньше думать о LL(n) грамматиках — тем это проще.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Грубо говоря, похоже, что ты исходишь примерно из такой предпосылки: чем сложнее грамматика, тем больше возможностей написать на соответствующем языке непонятную программу. Это так. В теории. Однако, на практике есть и другой, имхо, более существенный фактор: более сложные языки (в т.ч. и синтаксически) дают большую свободу в выражении своих мыслей, и, соответственно, при сознательном стремлении написать понятную программу, очень вероятно, что на более сложном языке это может получиться лучше. Примеры привести легко:
ПК> тексты на естественных языках, обладающих очень высокой синтаксической сложностью по сравнению с языками программирования, понимать обычно проще, чем на последних;
Тезис очень спорный. Как, например, читаются математические статьи?
ПК> BrainFuck потрясающе прост синтаксически, но совершенно недостаточен для возможности внятно выразить даже простейшую программу "Hello World": ПК>
Здесь я снова, в который уже раз, напишу что такое принцип композиционной семантики, применяемый в линвистике. Он говорит о том, что смысл предложения складывается из смысла слов этого предложения и его синтаксической структуры. Есть исключения, когда предложение имеет еще и контекст, но об этом мы здесь не говорим. Итак, а приведенном выше примере почему непонятен смысл?
1. Мы не знаем грамматику языка, т.е. его синтаксис.
2. Мы не знаем смысл лексем этого языка.
Почему понятен пример ниже?
1. Все на форуме знают грамматику языка си.
2. Смысл лексем print и Hello World! унаследовал от английского языка, и потому ясен.
Поэтому, приведенные примеры некорректны в том смысле, что не отражают обсуждаемой темы.
ПК>принципиально более сложный C позволяет это сделать намного понятнее: ПК>
ПК>Резюме: имхо, говорить о читабельности языков столь же некорректно, как и говорить об их производительности. Вместо последнего стоит говорить о производительности конкретных реализаций. Вместо первого -- о читабельности конкретных программ.
Т.е. вообще нет смысла говорить о сложности языка? Согласен ли ты с тезисом: чем сложнее язык — тем сложнее его понимание?
Здравствуйте, AndreyFedotov, Вы писали:
E>>Чтобы внести чуть-чуть юмора... AF>Тут уже не чуть-чуть. Тут уже психиаторов пора вызывать...
Как по мне — так уже давно
E>>Но вот синтез по отношению к девушке -- это как? AF>Да в общем то так же как и тысячу лет назад. Сообразить — что и как нужно сделать что бы с ней познакомиться и ей понравится. Подозреваю, что чем меньше думать о LL(n) грамматиках — тем это проще.
А я вот думаю что чем больше думаешь о LL(n) то тем сложнее это будет. Впрочем справедливости ради наверное это касается и всех остальных LL- грамматик. Про остальные не знаю
Здравствуйте, AndreyFedotov, Вы писали:
E>>Чтобы внести чуть-чуть юмора...
AF>Тут уже не чуть-чуть. Тут уже психиаторов пора вызывать...
Да в этой ветке без юмора вообще делать нечего
E>>Но вот синтез по отношению к девушке -- это как?
AF>Да в общем то так же как и тысячу лет назад. Сообразить — что и как нужно сделать что бы с ней познакомиться и ей понравится.
Так это же, имхо, чистый анализ!
Мне показалось, что синтез -- это когда пластический хирург или косметолог/стилист создает красоту. А ты все это финансируешь
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
mefrill,
> ПК> тексты на естественных языках, обладающих очень высокой синтаксической сложностью по сравнению с языками программирования, понимать обычно проще, чем на последних; > > Тезис очень спорный. Как, например, читаются математические статьи?
Обычно легче, чем соответствующие им программы.
> ПК>
> > Здесь я снова, в который уже раз, напишу что такое принцип композиционной семантики, применяемый в линвистике. Он говорит о том, что смысл предложения складывается из смысла слов этого предложения и его синтаксической структуры. Есть исключения, когда предложение имеет еще и контекст, но об этом мы здесь не говорим. Итак, а приведенном выше примере почему непонятен смысл? > 1. Мы не знаем грамматику языка, т.е. его синтаксис. > 2. Мы не знаем смысл лексем этого языка.
Мы знаем и то, и другое -- там знать нечего. Тем не менее, понимать очень тяжело. По другой причине: язык оперирует очень низкоуровневыми понятиями, и не предоставляет достаточных средств для абстракции.
> Почему понятен пример ниже? > 1. Все на форуме знают грамматику языка си. > 2. Смысл лексем print и Hello World! унаследовал от английского языка, и потому ясен. > Поэтому, приведенные примеры некорректны в том смысле, что не отражают обсуждаемой темы.
Это смотря кто какую тему обсуждает... Мне интересна фактическая читабельность реальных программ.
> ПК>Резюме: имхо, говорить о читабельности языков столь же некорректно, как и говорить об их производительности. Вместо последнего стоит говорить о производительности конкретных реализаций. Вместо первого -- о читабельности конкретных программ.
> Т.е. вообще нет смысла говорить о сложности языка?
Отчего же? Конечно имеет. Но не отождествляя с легкостью чтения программ на нем.
> Согласен ли ты с тезисом: чем сложнее язык — тем сложнее его понимание?
Смотря что понимается под "пониманием языка".
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Потрясающе! Подмечено умно, тонко, глубоко — и совершенно бесполезно
M>Здесь я снова, в который уже раз, напишу что такое принцип композиционной семантики, применяемый в линвистике. Он говорит о том, что смысл предложения складывается из смысла слов этого предложения и его синтаксической структуры. Есть исключения, когда предложение имеет еще и контекст, но об этом мы здесь не говорим. Итак, а приведенном выше примере почему непонятен смысл? M>1. Мы не знаем грамматику языка, т.е. его синтаксис. M>2. Мы не знаем смысл лексем этого языка.
Это как раз то, о чём писал Влад — поиск сферических коней в вакууме.
Потому, как на бумаге всё красиво и логично, но вот почему то оДнА и тАЖе фРаЗА (одна и таже фраза) тем не менее воспринимается по-разному — соответствуя при этом красивым научным принципам...
M>Почему понятен пример ниже? M>1. Все на форуме знают грамматику языка си. M>2. Смысл лексем print и Hello World! унаследовал от английского языка, и потому ясен.
Так ведь и так очевидно, что если бы лет эдак 900 назад за основу английского алфавита взяли бы не латынь, а арабский шрифт, а британия была бы завоёвана маврами — и язык был бы другой и пример бы выглядел по-другому. И мы наверняка его бы не поняли. Аналогично и с синтаксисом Си. Если бы в 70-х СССР завоевал бы америку и заставил бы их писать UNIX на рапире — нам роднее, ближе и понятнее был бы его синтаксис и увидев пример из этой параллельной вселенной мы тоже долго удивлялись бы.
Да что там! Замените Hello World на аналогичную надпись на японском — и уже не поймёшь что делает программа.
Но ведь мы то живём здесь и сейчас в конкретном историческом и конкретном культурном контексте. И естественно, для того, что бы сделать код более или менее читабельным потребуется учитвать этот контекст. Но к грамматикам это никакого отношения не имеет.
Вот потому я полностью согласен с выводом Павла:
Резюме: имхо, говорить о читабельности языков столь же некорректно, как и говорить об их производительности.
Вместо последнего стоит говорить о производительности конкретных реализаций.
Вместо первого -- о читабельности конкретных программ.
M>Т.е. вообще нет смысла говорить о сложности языка? Согласен ли ты с тезисом: чем сложнее язык — тем сложнее его понимание?
Есть. Но очень аккуратно и рассуждая не в общем — а делая осторожные обобщения на конкретных примерах, с учётом как положительных, так и отрицательных примеров.
Здравствуйте, xBlackCat, Вы писали:
E>>Мне показалось, что синтез -- это когда пластический хирург или косметолог/стилист создает красоту. А ты все это финансируешь
BC>Нет, синтез — это когда ты с этой девушкой делаешь такую же (или похожую) девушку
За точность цитаты не ручаюсь, но все же:
Однажды на светском приеме к Бернарду Шоу, у которого была страшноватая внешность, подошла знаменитая светская красавица и сказала: "О, мистер Шоу, я много о вас слышала и знаю, что вы очень умный. Представляете себе, какие у нас были бы дети? Они обладали бы моей внешностью и вашим умом". Бернард Шоу сказал: "Это очень хорошо, но представьте, что будет, если наши дети будут обладать моей внешностью и вашим умом?"
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>За точность цитаты не ручаюсь, но все же: E>
E>Однажды на светском приеме к Бернарду Шоу, у которого была страшноватая внешность, подошла знаменитая светская красавица и сказала: "О, мистер Шоу, я много о вас слышала и знаю, что вы очень умный. Представляете себе, какие у нас были бы дети? Они обладали бы моей внешностью и вашим умом". Бернард Шоу сказал: "Это очень хорошо, но представьте, что будет, если наши дети будут обладать моей внешностью и вашим умом?"
Здравствуйте, eao197, Вы писали:
E>За точность цитаты не ручаюсь, но все же: E>
E>Однажды на светском приеме к Бернарду Шоу, у которого была страшноватая внешность, подошла знаменитая светская красавица и сказала: "О, мистер Шоу, я много о вас слышала и знаю, что вы очень умный. Представляете себе, какие у нас были бы дети? Они обладали бы моей внешностью и вашим умом". Бернард Шоу сказал: "Это очень хорошо, но представьте, что будет, если наши дети будут обладать моей внешностью и вашим умом?"
На сколько я помню, наследование происходит чаще всего так, как говорит Бернард Шоу. Хорошо, что он отказал
Здравствуйте, AndreyFedotov, Вы писали:
AF>Да в общем то так же как и тысячу лет назад. Сообразить — что и как нужно сделать что бы с ней познакомиться и ей понравится. Подозреваю, что чем меньше думать о LL(n) грамматиках — тем это проще.
Эээ, сдается мне, все не так просто. Наблюдал как-то в автобусе: кто-то кого-то толкнул, то ли он ее, то ли наоборот. Неумышленно, конечно. Завязывается непринужденная беседа. Через пару минут слышу, она его спрашивает, разбирается ли он в компьютерах и знает ли английский язык. Так что, возможно, знакомиться девушки скоро будут только с теми, у кого под мышкой выглядывает журнал "Хакер", не иначе.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Да в общем то так же как и тысячу лет назад. Сообразить — что и как нужно сделать что бы с ней познакомиться и ей понравится. Подозреваю, что чем меньше думать о LL(n) грамматиках — тем это проще.
P>Эээ, сдается мне, все не так просто. Наблюдал как-то в автобусе: кто-то кого-то толкнул, то ли он ее, то ли наоборот. Неумышленно, конечно. Завязывается непринужденная беседа. Через пару минут слышу, она его спрашивает, разбирается ли он в компьютерах и знает ли английский язык. Так что, возможно, знакомиться девушки скоро будут только с теми, у кого под мышкой выглядывает журнал "Хакер", не иначе.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Если же цель — анализ ради анализа — то подумай — так ли это интересно для всех остальных? (Судя по реакции — по-моему не очень )
Как раз наоборот. Если бы не было интересно, разве была бы такая бурная реакция?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Чего это за такое? Я не понимаю. Приведите пожалуйста как положено для грамматик — в EBNF форме.
Регулярные грамматики можно приводить в регулярной форме. Правда, в несколько иной, чем привел автор (язык регулярных выражений, пришедший из Юникс — это не язык описания регулярных грамматик, тем более, что позволяет задавать грамматики, не являющиеся регулярными).
Я помню из института две похожие нотации регулярных грамматик, отличались только тем, что в первой циклы задавались фигурными скобками {}, а во второй — звездочкой *.
Есть еще расширенный язык регулярных выражений. Допускается использовать ранее определенные правила и символ '+', обозначающий цикл, начинающийся с, как минимум, одной итерации.
Здравствуйте, VladD2, Вы писали:
ПК>>В прошлый раз, делая это утверждение, ты так и не обосновал его. Так что лучше в качестве аргумента его не использовать...
VD>Тебе показалось. Сравни размер граматик и даже вопрос не возникнет.
В прошлый раз, вроде, сошлись на том, что есть т.н. "полная" грамматика языка, и есть подходы к реализации компиляторов, которые разбивают процесс распознавания предложений языка на несколько этапов, каждый из которых оперирует упрощенными правилами и результатами предыдущих этапов.
Применительно к С++, даже если у него меньше синтаксических конструкций (меньше ли, учитывая разный синтаксис для обычных, и 2-х видов ссылочных переменных?), то это лишь означает меньше правил для этапа синтаксического анализа. Однако, у каждого синтаксически корректного предложения языка может быть несколько семантических значений, определямых той самой "полной" грамматикой. В С++ очевидно, мы получаем гораздо больше неоднозначностей на этапе синтаксического разбора.
Грамматика, на которой построен синтаксический анализатор, не есть грамматика языка.
Здравствуйте, vdimas, Вы писали:
V>В прошлый раз, вроде, сошлись на том, что есть т.н. "полная" грамматика языка, и есть подходы к реализации компиляторов, которые разбивают процесс распознавания предложений языка на несколько этапов, каждый из которых оперирует упрощенными правилами и результатами предыдущих этапов.
Ты может и сходился. Я как считал, что есть грамматика и все остальное, так и считаю. Все же понятие определенное и довольно однозначное.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>Т.е. ты хочешь сказать, что LL(1)-граматика имеет меньше ограничений на синтаксис, чем не LL(1)-граматика??? Если нет, тогда о чем мы спорим?
Нет. Я хочу сказать, что для человека не важно является ли грамматика LL(1), а важны совсем другие факторы.
VD>>Прицип тут простой. Декларация понятнее императивного описания более низкоуровневыми средствами. А чтобы добиться большей декларативности унжно или иметь некие очень не простые механизым ее достижения, либо расширять и усложнять грамматику чтобы впихнуть в нее эти декларативные конструкции.
M>В выделенное не въехал. Почему понятнее?
Потому что это декларация, а не клгоритм. Ну, понятнее людям:
foreach (A a in array)
f(a);
нежели:
for (int i = 0; i < 0; i++)
f(array[i]);
M> Кроме того, язык может быть и не декларативный и не императивный, а может сочетать в себе и то и другой, например, русский язык.
Ну, русский лучше не брать. А в ЯП действительно бывает по разному. И понятнее получается как раз тот где для часто встречающихся конструкций есть более простой (более декларативный) синтаксис. Объем грамматики при этом увеличивается, но восприятие человеком не только не уменьшается, но и увеличивается.
M> Я уже несколько раз пытался объяснить: в лингвистике есть такой принцип композиционной семантики. Он говорит о том, что смысл предложения языка определяется смыслом входящих в предложение лексем и синтаксической конструкцией предложения. Хотя бывают, конечно, и исключения. Если отталкиваться от этого принципа, то при всех прочих равных факторах, чем сложнее структура предложения, тем сложнее его понимать. Что же здесь нелогичного?
Здесь все логично. Не логично утверждение что язык с более простой грамматикой проще понимать.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mefrill, Вы писали:
M>>> Что мы сравниваем, легкость чтения EBNF и РВ? VD>>Да.
M>Тогда мы имеем два целевых языка? EBNF и РВ. И две КС-грамматики для них? ТИ мы должны сравнить эти грамматики, а не сами языки?
Прямо как в той рекламе — да, беда...
Мы имеем возможность выразить свои мысли на двух языках, а потом сравнить восприятие результата пользователем (читателем).
M>Хорошо, как тебе такая EBNF:
M>A:B"45"CB:'3'+'G'*T'|HN:F':'K и т.д. Как вопринимается? И, кстати, попробуй прочитать это не слева направо, а иерархически.
Хреново, так как плохо отформатировано (все слитно), идетификаторы (имена правил) не осмысленные, не совсем знаком с данным диалектом. Но все это легко решаемые проблемы. В то же время в РВ проблемы не решаются.
M>Я снова не понял цели. Есть сложное РВ. Как мы его рассматриваем? Как язык, о котором мы говорим и который задается другой КС-грамматикой и не является регулярным, или как способ задания регулярного языка? И где здесь LL(1)? Честно, я не понял о чем ты говоришь.
LL(1) здесь в описании самих РВ и EBNF. Речь идет об этих языках и их читабельности, а не о грамматиках порождаемых уже на них. Т.е. порождаемая граматика меня интересует только как код который мне нужно понять.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, xBlackCat, Вы писали:
E>>За точность цитаты не ручаюсь, но все же: E>>
E>>Однажды на светском приеме к Бернарду Шоу, у которого была страшноватая внешность, подошла знаменитая светская красавица и сказала: "О, мистер Шоу, я много о вас слышала и знаю, что вы очень умный. Представляете себе, какие у нас были бы дети? Они обладали бы моей внешностью и вашим умом". Бернард Шоу сказал: "Это очень хорошо, но представьте, что будет, если наши дети будут обладать моей внешностью и вашим умом?"
BC>На сколько я помню, наследование происходит чаще всего так, как говорит Бернард Шоу. Хорошо, что он отказал
Злые вы, может баба была непризнанным гением?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Сгласен со всем кроме последнего:
ПК>Резюме: имхо, говорить о читабельности языков столь же некорректно, как и говорить об их производительности. Вместо последнего стоит говорить о производительности конкретных реализаций. Вместо первого -- о читабельности конкретных программ.
Все же от языка, как и от того как на нем пишут очень даже зависит читаемость текста. Ты же сам привел БрэйнФак на котором в принципе нельзя написать понятную программу. Та же фигня и у РВ, хотя не так страшно.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Синтез и творчество по отношению к картине -- понятно. И про автомобиль понятно. Даже про марочное вино понять можно. E>Но вот синтез по отношению к девушке -- это как?
А я вот все задаюсь вопросом... Любовь к Родине это как? Ну, в смысле кто кого имеет?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>В прошлый раз, вроде, сошлись на том, что есть т.н. "полная" грамматика языка, и есть подходы к реализации компиляторов, которые разбивают процесс распознавания предложений языка на несколько этапов, каждый из которых оперирует упрощенными правилами и результатами предыдущих этапов.
VD>Ты может и сходился. Я как считал, что есть грамматика и все остальное, так и считаю. Все же понятие определенное и довольно однозначное.
А какая именно грамматика из бесконечного множества? КС-грамматика, КЗ или грамматика без ограничений? Можно си++ задать и регулярной грамматикой, а все остальное парсить вручную. О какой грамматике ты писал?
VladD2,
> ПК> Резюме: имхо, говорить о читабельности языков столь же некорректно, как и говорить об их производительности. Вместо последнего стоит говорить о производительности конкретных реализаций. Вместо первого -- о читабельности конкретных программ.
> Все же от языка, как и от того как на нем пишут очень даже зависит читаемость текста. Ты же сам привел БрэйнФак на котором в принципе нельзя написать понятную программу. Та же фигня и у РВ, хотя не так страшно.
В такой постановке и я бы согласился. Т.е., если язык не позволяет написать читабельную программу — да, дефект (в плане читабельности) в нем. Но пока похоже, что mefrill говорит о чем-то другом, т.к. обсуждаемые языки программирования со сложными грамматиками читабельные программы писать позволяют.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, mefrill, Вы писали:
M>Т.е. вообще нет смысла говорить о сложности языка? Согласен ли ты с тезисом: чем сложнее язык — тем сложнее его понимание?
Я не согласен.
Если ты пытаешься выразить сложную мысль на слишком простом языке, то получится очень хреново. Просто потому, что объем высказываний очень быстро превысит критический предел понимания. Например, можно предположить, что чертовски трудно прочитать доклад о новейших достижениях программирования на языке эскимосов
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, mefrill, Вы писали:
M>>Т.е. вообще нет смысла говорить о сложности языка? Согласен ли ты с тезисом: чем сложнее язык — тем сложнее его понимание?
Д>Я не согласен. Д>Если ты пытаешься выразить сложную мысль на слишком простом языке, то получится очень хреново. Просто потому, что объем высказываний очень быстро превысит критический предел понимания. Например, можно предположить, что чертовски трудно прочитать доклад о новейших достижениях программирования на языке эскимосов
В языке "эскимосов" просто нет соответсвующих терминов. То есть нет соответсвующих терминалов. Сложность же не зависит от количества терминалов, а зависит только от класса по Хомскому. От количества терминалов зависит объем.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>В языке "эскимосов" просто нет соответсвующих терминов. То есть нет соответсвующих терминалов. Сложность же не зависит от количества терминалов, а зависит только от класса по Хомскому. От количества терминалов зависит объем.
Не только терминов, но и конструкций, с помощью которых их можно объединять. К примеру, если в языке нет будущего времени, то становится намного сложнее выражать некоторые мысли.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Сергей! Ты действительно предложил лучший вариант, чем был изначально. Но дело тут вовсе не в тезисе. AF>Дело в том, что сама область настолько обширна, что просто-напросто не описывается разумным образом с помощью каких-либо тезисов.
AF> Это как красивая девушка. Или красивая картина, интересный фильм, шикарный автомобиль или марочное вино. Можно выдвинуть сколько угодно тезисов — как верных так и не верных. И всё равно — тезисы это одно — а девушка как и картина — совсем другое.
Позвольте Вам не поверить. Я думаю, что программирование — это не искуство, а смесь науки и технологии. Поэтому не допускаю мысли об иррациональном подходе к данной дисциплине. Более того, языки программирования компьютеров — это инструменты. Инструменты могут быть простыми или сложными, маленькими или большими, но они всегда рациональны, стало быть обозримы, понятны, формализуемы и т. п..
AF> Спроси себя — зачем ты затеваешь все эти дискуссии?
Ответ на этот вопрос мне известен точно. Практически все затеянные мной дискуссии на этом форуме имеют одну определённую цель.
Здравствуйте, VladD2, Вы писали:
BC>>На сколько я помню, наследование происходит чаще всего так, как говорит Бернард Шоу. Хорошо, что он отказал
VD>Злые вы, может баба была непризнанным гением?
Зато Бернард Шоу, может и не гений, но признанный.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ответ на этот вопрос мне известен точно. Практически все затеянные мной дискуссии на этом форуме имеют одну определённую цель.
неужели эта цель — популяризация оберона в массах?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Ответ на этот вопрос мне известен точно. Практически все затеянные мной дискуссии на этом форуме имеют одну определённую цель.
Д>неужели эта цель — популяризация оберона в массах?
Что-то мне дак это больше напоминает дискредитацию оного
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Позвольте Вам не поверить. Я думаю, что программирование — это не искуство, а смесь науки и технологии. Поэтому не допускаю мысли об иррациональном подходе к данной дисциплине. Более того, языки программирования компьютеров — это инструменты. Инструменты могут быть простыми или сложными, маленькими или большими, но они всегда рациональны, стало быть обозримы, понятны, формализуемы и т. п..
Дак ведь инструменты художника: кисть, краски, холст, палитра, добавьте, что я пропустил, тоже рациональны. Или скульптора: камень, резец, ну или гипс, глина, что там еще. А почему статуями древнегреческих мастеров до сих пор восторгаются как знатоки, так и любители? Не потому ли, что греческие скульпторы уделяли внимание анатомии — как по мне, слишком скучная дисциплина. Да и процесс создания статуй или картин вполне рационален.
Инструмент писателя — еще проще: карандаш и бумага. Однако, "Евгений Онегин" или "Конек-Горбунок" не стареют.
Кстати, где-то читал, Поль Дирак получил свое уравнение практически "по наитию" после нескольких недель бесплодных игр с уравнениями.
А почему Кнут назвал свой труд "Искусство программирования"?
А еще попробуй найти в Сети книгу "Философский камень в программировании" ("progstone"). Может быть, прочитав ее, ты пересмотришь свои взгляды на жизнь.
Здравствуйте, Privalov, Вы писали:
P>Дак ведь инструменты художника: кисть, краски, холст, палитра, добавьте, что я пропустил, тоже рациональны.
А ведь действительно. Уж у художников, казалось бы, все стандартизовано. Инструменты стандартные, краски стандартные, даже техники рисунка стандартные. Только у одних получаются шедевры, а у других — никчемные поделки. Парадокс?
Здравствуйте, Дарней, Вы писали:
P>>Дак ведь инструменты художника: кисть, краски, холст, палитра, добавьте, что я пропустил, тоже рациональны.
Д>А ведь действительно. Уж у художников, казалось бы, все стандартизовано. Инструменты стандартные, краски стандартные, даже техники рисунка стандартные. Только у одних получаются шедевры, а у других — никчемные поделки. Парадокс?
Собственно так же, как и у математиков -- понятия и математический аппарат у всех одинаковый. А открытия почему-то только единицы делают.
Или взять очень близкое нам программирование. Тем же C++ масса людей пользуется. Только у одних почему-то все получается и не глючит, а другим руки отрывать нужно.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, mefrill, Вы писали:
M>При прочих равных критериях!? Согласен ты с тем, что сложность грамматики — это один из критериев сложности языка? Большего я не утверждаю.
Один из — да. И то при условии наличия кучи других факторов.
Но опять же может быть довольно простая не LL(1)-грамматика. Ну, мало ли какая-нить хрень должна будет быть в конце конструкции? Для человека пустяк. А для LL(1)-прсера неразрешимая проблема.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В такой постановке и я бы согласился. Т.е., если язык не позволяет написать читабельную программу — да, дефект (в плане читабельности) в нем.
+1
ПК> Но пока похоже, что mefrill говорит о чем-то другом, т.к. обсуждаемые языки программирования со сложными грамматиками читабельные программы писать позволяют.
Ох...ох...ооох... Похоже здесь все говорят о чем-то своем.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>Если я не ошибаюсь, речь шла о самом языке описания регулярных выражений, а не о языках, которые можно с их помощью описать. Пусть Трурль поправит, если я ошибаюсь.
Мнэээ. А разве язык регекспов регулярный? Мне казалось, что он LL(1). Хотя бы потому, что там есть скобки.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Сергей! Ты действительно предложил лучший вариант, чем был изначально. Но дело тут вовсе не в тезисе. AF>>Дело в том, что сама область настолько обширна, что просто-напросто не описывается разумным образом с помощью каких-либо тезисов.
AF>> Это как красивая девушка. Или красивая картина, интересный фильм, шикарный автомобиль или марочное вино. Можно выдвинуть сколько угодно тезисов — как верных так и не верных. И всё равно — тезисы это одно — а девушка как и картина — совсем другое.
СГ>Позвольте Вам не поверить. Я думаю, что программирование — это не искуство, а смесь науки и технологии. Поэтому не допускаю мысли об иррациональном подходе к данной дисциплине. Более того, языки программирования компьютеров — это инструменты. Инструменты могут быть простыми или сложными, маленькими или большими, но они всегда рациональны, стало быть обозримы, понятны, формализуемы и т. п..
А кто говорит об иррациональном подходе?
Я как раз исхожу из того, что любое искусство, любое мастерство, любая магия имеет совершенно чёткую структуру — которую можно выделить, воспроизвести и которой можно научиться самому и научить других. Вопрос лишь в умении это делать.
Однако это вовсе не означает, что оптимальный путь научиться водить автомобиль — это изучение атомарной струкуры вещества, из которого состоит автомобиль. И для того, что бы научиться рисовать врядли будет оптимальным проводить многомерный статистический анализ распределения краски на холсте
Нужно выбирать средства адекватные цели.
AF>> Спроси себя — зачем ты затеваешь все эти дискуссии?
СГ>Ответ на этот вопрос мне известен точно. Практически все затеянные мной дискуссии на этом форуме имеют одну определённую цель.
Это очень похоже на банальный снобизм и высокомерное пренебрежение по отношению к другим участникам форума. Мол вам не дано понять. Ну и стоит ли удивляться тому, что мы постоянно наблюдаем адекватную реакцию?
Будь проще. Ну и что страшного, если ты просто поделишься со всеми остальными своей целью? Ну скажешь ты, что занимаешься анализом закономерностей в синтаксисе языка и их влиянием на качество кода. Кто-то тебя поддержит. Кто-то посмеётся и будет против. Но в любом случае это заслуживает уважения и наверняка найдутся такие, кто захотят помочь. Ведь тот же Влад при правильном к нему подходе может тебе здорово помочь, вместо того, что бы лупить веслом по голове.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>Состояний может быть бесконечно много, но если они, например, перенумерованы, то достаточно помнить только номер. Соответственно человек легко будет помнить одновременно 7 +/- 2 номеров.
СГ>Хотя, конечно, на счет бесконечности это я не прав. Ведь сам номер состояния может быть таким большим что в голове не уберется.
Потому что сама постановка вопроса неправильная.
В голове у человека не 7 номеров, а стек из 7 ячеек.
Так что для случаев, когда мы имеем дело с конструкциями языка, дающими вложенность более, чем размер стека, то есть, 5-7 нетерминальных символов (пусть сколь угодно сложных, поскольку человек не нумерует мысли, а воспринимает их скорее как цельные образы — свёрнутые или развёрнутые), сложность семантического (сворачивающего-разворачивающего смыслы этих символов) анализа оказывается столь великой, что практически неподъёмной, что я и демонстрирую написанием данного предложения.
Здравствуйте, Дарней, Вы писали:
К>>Мнэээ. А разве язык регекспов регулярный? Мне казалось, что он LL(1). Хотя бы потому, что там есть скобки.
Д>Да нет, конечно. Он даже не LL(1), а скорее LL(*). Но сложен в прочтении он совсем не поэтому.
Здравствуйте, Кодт, Вы писали:
К>...что я и демонстрирую написанием данного предложения.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, Дарней, Вы писали:
Д>А ведь действительно. Уж у художников, казалось бы, все стандартизовано. Инструменты стандартные, краски стандартные, даже техники рисунка стандартные. Только у одних получаются шедевры, а у других — никчемные поделки. Парадокс?
Возможно. Однако, главная часть любого инструмента есть голова его владельца (c) не помню. По-моему, я (а может, и не я) уже это постил. IMHO, все же в этом направлении следует искать разгадку этого парадокса — в мышлении.
Здравствуйте, Кодт, Вы писали:
Д>>Да нет, конечно. Он даже не LL(1), а скорее LL(*). Но сложен в прочтении он совсем не поэтому.
К>Естественно, что не поэтому.
Ну вот осталось только убедить в этом великого и ужасного СГ
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Состояний может быть бесконечно много, но если они, например, перенумерованы, то достаточно помнить только номер. Соответственно человек легко будет помнить одновременно 7 +/- 2 номеров.
23 2343 3233 2344 23
переведу, на всякий случай:
простите, но мне почему-то кажется, что ты что-то не то спорол. Или, когда читаешь текст программы, у тебя в голове цифирки возникают?
Здравствуйте, mefrill, Вы писали:
VD>>А вот как раз LL(1) тут ни на что не влияет. M>А с этим не согласен. Ограничение на грамматику означает ограничение на сложность структуры языка, что в свою очередь, означает ограничение на его сложность при понимании. Поэтому, я бы сказал так: простота и сложность восприятия человеком языка определяется множеством факторов, и в том числе, ограничением на структуру порождающей грамматики языка.
Если уж на то пошло то ни C++, ни C#, ни даже Oberon не порождаются контекстно свободными грамматиками из-за требования одного определения, предварительного объявления итп...
Но тем не мение человек легко расправляется с языками порожденными контекстно зависимыми грамматиками.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Если уж на то пошло то ни C++, ни C#, ни даже Oberon не порождаются контекстно свободными грамматиками из-за требования одного определения, предварительного объявления итп... WH>Но тем не мение человек легко расправляется с языками порожденными контекстно зависимыми грамматиками.
страшно даже представить, если кто-то вдруг захочет перевести язык на true LL
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>В прошлый раз, вроде, сошлись на том, что есть т.н. "полная" грамматика языка, и есть подходы к реализации компиляторов, которые разбивают процесс распознавания предложений языка на несколько этапов, каждый из которых оперирует упрощенными правилами и результатами предыдущих этапов.
VD>Ты может и сходился. Я как считал, что есть грамматика и все остальное, так и считаю. Все же понятие определенное и довольно однозначное.
Какая именно грамматика есть? Уточни, плз.
Полная грамматика большинства современных ЯП высокого уровня является контекстно-зависимой. Поэтому, распознаватель-автомат (даже с бесконечной магазинной памятью) построить практически нереально. Поэтому распознавание в компиляторах бьют на этапы. Ты, очевидно, имеешь в виду этап синтаксического разбора?
Здравствуйте, eao197, Вы писали:
E>Или взять очень близкое нам программирование. Тем же C++ масса людей пользуется. Только у одних почему-то все получается и не глючит, а другим руки отрывать нужно.
Врут черти.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Или взять очень близкое нам программирование. Тем же C++ масса людей пользуется. Только у одних почему-то все получается и не глючит
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, VladD2, Вы писали:
E>>>Или взять очень близкое нам программирование. Тем же C++ масса людей пользуется. Только у одних почему-то все получается и не глючит
Д>Все о них слышали, но никто не видел лично
Можешь на меня посмотреть.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Privalov, Вы писали:
СГ>> Более того, языки программирования компьютеров — это инструменты. Инструменты могут быть простыми или сложными, маленькими или большими, но они всегда рациональны, стало быть обозримы, понятны, формализуемы и т. п..
P>Дак ведь инструменты художника: кисть, краски, холст, палитра, добавьте, что я пропустил, тоже рациональны.
Ровно об этом я и сказал, так что не понятно о чем Вы собрались затеять спор.
Здравствуйте, Дарней, Вы писали:
VD>>Он чистый LL(1).
Д>Думаешь? А как быть с этим, например? Д>
Д>abc|def|ghi
Д>
И что здесь не так?
Это соотвествует грмматике:
Expr = Term { '|' Term }.
Term = char { char }.
Единственная проблема возникает с посфиксными выражениями вроде итерации (*). Но она обходится за счет выделения вложенного выражения в отдельное правило:
Здравствуйте, VladD2, Вы писали:
VD>И что здесь не так? VD>Это соотвествует грмматике: VD>
VD>Expr = Term { '|' Term }.
VD>Term = char { char }.
VD>
VD>Единственная проблема возникает с посфиксными выражениями вроде итерации (*). Но она обходится за счет выделения вложенного выражения в отдельное правило: VD>
Попробую изобразить синтаксическое дерево для этого выражения.
<AlternativeStatement>
------------- | -------------
| | |
<Alternative1> <Alternative2> <Alternative3>
При этом, чтобы понять, что данный паттерн состоит из одного AlternativeStatement, парсеру нужно разбирать его, пока он не встретит первый символ "|"
Я не прав?
Здравствуйте, Дарней, Вы писали:
Д>При этом, чтобы понять, что данный паттерн состоит из одного AlternativeStatement, парсеру нужно разбирать его, пока он не встретит первый символ "|" Д>Я не прав?
Не прав. Парсер рекурсивно вычислит вложенные правила и свернет их в Expr. Далее любые конструкции распознаются с заглядываением на один терминал вперед.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>вычислит вложенные правила и свернет их в Expr. Далее любые конструкции распознаются с заглядываением на один терминал вперед.
Если это "свернутое выражение", то это уже не терминал, ИМХО.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, VladD2, Вы писали:
VD>> LL(*) так вообще может описать почти все что нужно для ЯП.
СГ>LL(1) тоже, так "зачем платить больше"?
Выразительности ради. Давайте не поменять цели и задачи ЯП. ЯП пишется не для компилятора, а для человека. Сложность реализации компилятора конкретного ЯП никого не интересует, кроме производителей этих компиляторов.
И уже упоминалось тут, что восприятие человеком информации весьма контекстно-зависимое.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, VladD2, Вы писали:
VD>>> LL(*) так вообще может описать почти все что нужно для ЯП.
СГ>>LL(1) тоже, так "зачем платить больше"?
V> Выразительности ради.
А почему Вы думаете, что использование более сложной грамматики чем LL(1) добавит выразительности?
По моему, выразительности это ни сколько не добавит, но вот легкость восприятия поубавит.
V>Сложность реализации компилятора конкретного ЯП никого не интересует, кроме производителей этих компиляторов.
На основании этого опыта я даже вывел для себя следующее правило:
Не торопись менять компилятор Си++!
100% корректных среди них не бывает, а ошибки в старом компиляторе ты уже знаешь.
Я следую этому правилу до сих пор. Сейчас я использую в работе компиляторы примерно пятилетней давности.
Еще есть история про программистов Ada (вообще-то, очень сложный язык если судить по объему синтаксиса, сложнее него только C#), которые лет через десять после ее появления хвастались, что наконец-то появился компилятор, который почти что правильно компилирует.
V>И уже упоминалось тут, что восприятие человеком информации весьма контекстно-зависимое.
И что? В языках программирования и так достаточно много вещей зависящих от контекста, так зачем же еще и грамматику используемую при синтаксическом разборе усложнять больше чем это реально необходимо (а реально необходимо всего лишь LL(1)).
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Еще есть история про программистов Ada (вообще-то, очень сложный язык если судить по объему синтаксиса, сложнее него только C#), которые лет через десять после ее появления хвастались, что наконец-то появился компилятор, который почти что правильно компилирует.
Прыкольно. Наверное для такого сложного C# (который сложнее Ada) ещё лет 5-10 не смогут написать правильного коипилятора ?
Сергей,
> А почему Вы думаете, что использование более сложной грамматики чем LL(1) добавит выразительности?
Потому что впихнуть в прокрустово ложе LL(1) ряд возможностей, добавляющих языку выразительности, не так уж легко. Например, попробуй добавить в Оберон удобные для использования шаблоны (или хотя бы generics), оставив грамматику LL(1)...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Sergey J. A., Вы писали:
SJA>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Еще есть история про программистов Ada (вообще-то, очень сложный язык если судить по объему синтаксиса, сложнее него только C#), которые лет через десять после ее появления хвастались, что наконец-то появился компилятор, который почти что правильно компилирует.
SJA>Прыкольно. Наверное для такого сложного C# (который сложнее Ada) ещё лет 5-10 не смогут написать правильного коипилятора ?
Это ещё вопрос — что было первее, синтаксис додиеза или его компилятор.
Потому что с Адой сперва родили спецификацию, а потом задумались над воплощением. А микрософт имел возможность выдавать действительное за желаемое
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Сергей,
>> А почему Вы думаете, что использование более сложной грамматики чем LL(1) добавит выразительности?
ПК>Потому что впихнуть в прокрустово ложе LL(1) ряд возможностей, добавляющих языку выразительности, не так уж легко. Например, попробуй добавить в Оберон удобные для использования шаблоны (или хотя бы generics), оставив грамматику LL(1)...
В С++ проблема возникла из-за
1) неоднозначного синтаксиса (правило "если это выглядит как объявление функции...")
2) дурацкого выбора скобок
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>В языке "эскимосов" просто нет соответсвующих терминов. То есть нет соответсвующих терминалов. Сложность же не зависит от количества терминалов, а зависит только от класса по Хомскому. От количества терминалов зависит объем.
Д>Не только терминов, но и конструкций, с помощью которых их можно объединять. К примеру, если в языке нет будущего времени, то становится намного сложнее выражать некоторые мысли.
Некоторые современные английские языковеды полагают, что в английской грамматике нет будущего времени.
Например, Geoffrey Broughton:
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.
("Penguin English grammar")
Глаголы shall и will грамматически принадлежат к present tense и — ничего, справляемся мы с этим как-то...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Кодт,
> ПК>Потому что впихнуть в прокрустово ложе LL(1) ряд возможностей, добавляющих языку выразительности, не так уж легко. Например, попробуй добавить в Оберон удобные для использования шаблоны (или хотя бы generics), оставив грамматику LL(1)... > > В С++ проблема возникла из-за > 1) неоднозначного синтаксиса (правило "если это выглядит как объявление функции...") > 2) дурацкого выбора скобок
Безусловно. Я это к тому, что если шаблоны впихнуть получится, я еще чего-нибудь предложу. И так мы дойдем до предела, где без переделки существующего синтаксиса или без ущерба для удобства использования добавляемых возможностей, LL(1) вряд ли получится сохранить.
> Кстати, а Эйфель — LL(1) или нет?
Он даже не LR(1).
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Кодт, Вы писали:
SJA>>Прыкольно. Наверное для такого сложного C# (который сложнее Ada) ещё лет 5-10 не смогут написать правильного коипилятора ?
К>Это ещё вопрос — что было первее, синтаксис додиеза или его компилятор. К>Потому что с Адой сперва родили спецификацию, а потом задумались над воплощением. А микрософт имел возможность выдавать действительное за желаемое
Да я просто подколоть Серёгу решил. А потом подумал — неужели если кто-то решит написать компилятор C# с нуля, ему придётся мучатся лет 10, как с Ada ? Аду не видел, сравнивать не с чем, но на первый взгляд C# вполне прост для понимания. Мне казалось он и для компилятора должен быть не слишком сложен. Вот С++ другое дело....
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Privalov, Вы писали:
СГ>>> Более того, языки программирования компьютеров — это инструменты. Инструменты могут быть простыми или сложными, маленькими или большими, но они всегда рациональны, стало быть обозримы, понятны, формализуемы и т. п..
P>>Дак ведь инструменты художника: кисть, краски, холст, палитра, добавьте, что я пропустил, тоже рациональны.
СГ>Ровно об этом я и сказал, так что не понятно о чем Вы собрались затеять спор.
А чего ещё ты ожидал, если сам заявил "у меня есть цель, но я о ней никому не скажу"? Откуда мы можем знать — подходящий ли инструмент кисточки для гуаши, если мы не знаем, что ты собираешься ими делать — картину рисовать или дом снаружи Ореолом красить?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, VladD2, Вы писали:
VD>>вычислит вложенные правила и свернет их в Expr. Далее любые конструкции распознаются с заглядываением на один терминал вперед.
Д>Если это "свернутое выражение", то это уже не терминал, ИМХО.
А почему "это" должно терминалом? Это нетерминал, т.е. правило.
LL(1) тем и отличается от регулярных грамматик тем, что поддерживает рекурсивные определения. Например, рекурсивной грамматикой (ну, регепспом) нельзя описать вложенные ксобки. А для LL(1)-грамматики это не вопрос:
Здравствуйте, Кодт, Вы писали:
К>В С++ проблема возникла из-за К>1) неоднозначного синтаксиса (правило "если это выглядит как объявление функции...") К>2) дурацкого выбора скобок
Скобки тут не причем. В том же Шарпе проблема с ними решается.
А вот разобрать некоторые конструкции LL(1)-парсером не удается.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> К>В С++ проблема возникла из-за > К>1) неоднозначного синтаксиса (правило "если это выглядит как объявление функции...") > К>2) дурацкого выбора скобок
> Скобки тут не причем. В том же Шарпе проблема с ними решается.
Там она решается способом, недоступным LL(1) парсеру, так что скобки очень даже причем.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Сергей Губанов, Вы писали:
P>>Дак ведь инструменты художника: кисть, краски, холст, палитра, добавьте, что я пропустил, тоже рациональны.
СГ>Ровно об этом я и сказал, так что не понятно о чем Вы собрались затеять спор.
Сдается мне, здесь что-то не то.
Я думаю, что программирование — это не искуство, а смесь науки и технологии.
я подумал, что это — основной тезис. То, что далее говорилось об инструментах — мне показалось, что это аргумент в пользу этого тезиса. Однако, сейчас Вы утверждаете, что говорили только об инструментах, которые вполне рациональны как у худажника, так и у программиста. А о том высказывании, которое я процитировал, Вы забыли. Теперь мне непонятно, к чему же оно было?
Здравствуйте, 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 и — ничего, справляемся мы с этим как-то...
Я подозреваю, что некоторым современным английским языковедам заняться больше нечем. Хорошо хоть, оверхед считать не начали
Здравствуйте, VladD2, Вы писали:
VD>Скобки тут не причем. В том же Шарпе проблема с ними решается.
VD>А вот разобрать некоторые конструкции LL(1)-парсером не удается.
Интересно, а какие именно конструкции создают проблемы?
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Сергей,
>> А почему Вы думаете, что использование более сложной грамматики чем LL(1) добавит выразительности?
ПК>Потому что впихнуть в прокрустово ложе LL(1) ряд возможностей, добавляющих языку выразительности, не так уж легко. Например, попробуй добавить в Оберон удобные для использования шаблоны (или хотя бы generics), оставив грамматику LL(1)...
Здравствуйте, Павел Кузнецов, Вы писали:
>> Другое дело, что есть неоднозначность в: >>
>> A<B, C>(В)
>> A < B, C > (В)
>>
>> Которая в шарпе решается введением эвристики.
ПК>Именно о подобных неоднозначностях и идет речь. Они в Шарпе разрешаются способом, недоступным LL(1) парсеру.
Угловые скобки требуют знания контекста. Если перед '<' имя шаблона, то это скобка (и нужно искать ей пару), а если что-либо другое, то это двухместный оператор. А для этого нужно либо делать контекстную зависимость, либо явно писать кейворд template.
Кстати о синтаксисе шаблонов...
Пусть у нас есть скобочные выражения
— { РазныеСтейтменты }
— ( ВыражениеВСкобках )
— Функтор ( СписокАргументов ), причём доступ к массиву синтаксически такой же, как функтор (аналогично VB и Fortran'у)
— Шаблон [ СписокПараметров ]
Казалось бы, получаем LL(1).
Или там ещё есть подводные камни?
TYPE
ArrayList*(E: Object.Object) = POINTER TO ArrayListDesc(E);
ArrayListDesc*(E: Object.Object) = RECORD
...
END;
...
VAR myList: ArrayList(MyElementType);
На мой взгляд ни в выразительности, ни в прозрачности врядли чем то превосходит C++ или C#, скорее даже уступает.
То есть получается, что и бороться особо не за что...
Здравствуйте, AndreyFedotov, Вы писали:
AF> На мой взгляд...
Дело вкуса и предпочтений — форматирование текста. В остальном же — нельзя полагаться на абстрактные нравится/не нравится, а надо использовать то что наиболее подходит для формального описания/определения/вывода/заключений.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Дело вкуса и предпочтений — форматирование текста. В остальном же — нельзя полагаться на абстрактные нравится/не нравится, а надо использовать то что наиболее подходит для формального описания/определения/вывода/заключений.
Для формального контроля алгоритмов надо использовать объектную модель кода, для которой величина k абсолютно монопенисуальна.
А вот при выборе текстового представления кода надо ориентироваться именно на "нравится/не нравится" в первую очередь.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, 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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Почему грамматика Оберона-2 не является LL(1)?
ПК>Фактически, это синтаксическая неразличимость между type guard (*) и вызовом процедуры. Это некоторым образом аналогично неоднозначности с угловыми скобками в C++ (аргументы шаблона vs. операции < и >), требующей знания контекста (значения идентификаторов в разбираемом выражении).
Мне кажется, что грамматика принадлежит классу LL(1),
если парсер "забегает" вперед не более, чем на одну лексему.
Именно так и поступает компилятор Оберона. Он нигде не просматривает
входной поток более чем на одну лексему вперед.
Если это не LL(1), то к какому классу отнести такую грамматику?
Она определенно не является ни LR(k), ни LL(2), ни LL(3) etc.
Действительно, две ветки синтаксического разбора в следующем определении
начинаются с левой круглой скобки, но это не приводит к просмотру вперед
более, чем на один символ (т.е. для определения ветки следующая за скобкой
лексема не требуется).
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC,
> Мне кажется, что грамматика принадлежит классу LL(1), если парсер "забегает" вперед не более, чем на одну лексему.
...для определения того, по какой из альтернативных веток разбора пойти; в случае наличия неоднозначности разбора, неустранимой путем заглядывания на k лексем вперед, грамматика LL(k) не является. Т.е. ни одна неоднозначная грамматика не является LL(k).
> Именно так и поступает компилятор Оберона. Он нигде не просматривает входной поток более чем на одну лексему вперед.
Значит он:
a) или не является LL(1) автоматом, а построен по другим принципам, и, соответственно, грамматика LL(1) не является;
b) или разбирает надмножество Оберона-2.
(см. ниже)
> Если это не LL(1), то к какому классу отнести такую грамматику? Она определенно не является ни LR(k), ни LL(2), ни LL(3) etc.
Если пытаться устранить указанную неоднозначность средствами грамматики мы вообще придем к КЗ. Соответственно, на практике выделяют некоторую грамматику, порождающую надмножество Оберона-2, и устраняют неоднозначности и недопустимые конструкции на этапе "семантичесокого" анализа, или же делают это с помощью "ручного" разрешения конфликтов, например, "подглядыванием" в таблицу символов по ходу разбора, как это делается для подобных неоднозначностей в C++.
Так или иначе, говоря о том, что грамматика Оберона-2 является LL(1), нужно уточнять, о какой именно грамматике идет речь. "Официальная" LL(k) не является.
> Действительно, две ветки синтаксического разбора в следующем определении >
> начинаются с левой круглой скобки, но это не приводит к просмотру вперед более, чем на один символ (т.е. для определения ветки следующая за скобкой лексема не требуется).
В данном случае это приводит к принципиальной неразрешимости того, по какой из веток пойти; вне зависимости от дальности заглядывания вперед. Т.е. это вообще не LL(k).
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AVC, Вы писали:
AVC>Точно. Уволить их всех. AVC>Но смысл был в том, что future time вполне можно выразить и без future tense. AVC>Например: AVC>
AVC>I am leaving tomorrow.
согласен. Просто это усложняет понимание — чтобы понять, о каком времени идет речь, надо знать смысл слова tomorrow (которое к тому же стоит в конце предложения).
Теоретически, можно вообще обойтись без специальных конструкций для разных времен — но это еще больше усложнит понимание.
Здравствуйте, AVC, Вы писали:
AVC>Но смысл был в том, что future time вполне можно выразить и без future tense.
Нет. Cмысл в том, что грамматически future tense вообще отсутствует. Кстати, в русском языке глаголы несовершенного вида тоже не имеют будущего времени.
...Ремесло
Поставил я подножием искусству;
Я сделался ремесленник: перстам
Придал послушную, сухую беглость
И верность уху. Звуки умертвив,
Музыку я разъял, как труп. Поверил
Я алгеброй гармонию. Тогда
Уже дерзнул, в науке искушенный,
Предаться неге творческой мечты.
...
Не! не могу противиться я доле
Судьбе моей: я избран, чтоб его
Остановить -- не то мы все погибли,
Мы все, жрецы, служители музыки,
Не я один с моей глухою славой...
Что пользы, если Моцарт будет жив
И новой высоты еще достигнет?
Подымет ли он тем искусство? Нет;
Оно падет опять, как он исчезнет...
Человек не машина, не математическая модель и не парсер, ему удобно то, что он считает удобным, ни больше ни меньше. А Вирт как обычно подменяет понятия.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Где здесь неоднозначность? Скобки вокруг выражения versus вокруг списка аргументов?
ПК>Доступ к элементу массива vs. вызов функции. Можно, правда, попробовать "отбиться", если не вводить в грамматику оба нетерминала "вызов-функции" и "доступ-к-элементу-массива", а ограничиться одним "функтор" (может, ты об этом и говорил?). В этом случае тоже будут вопросы, но они уже будут зависеть от конкретики языка: в каких выражениях могут встречаться типы, функции и массивы; что из этого может быть шаблонами; где могут встречаться объявления, и где -- выражения, и всегда ли их можно будет отличить друг от друга и т.п.
Да, именно: не различать массивы и функции. В конце концов, васик с фортраном обходятся.
Опять же, удобно будет многомерные индексы делать; сейчас в С++ для этого приходится извращаться вокруг адаптеров оператора[].
Применимость и арность оператора() в любом случае требует контекстной зависимости — но уже после синтаксического разбора. Так что нет проблем с применимостью и арностью шаблонного метаоператора[] (или <>, если продолжить традиции С++).
А различать объявления, определения и выражения — вообще говоря, было бы полезно. Ради такого дела можно и ключевые слова ввести.
>> Эта же задача возникает в парсере мат.выражений...
ПК>Там такой неоднозначности нет, т.к. скобка после идентификатора может и должна присутствовать только в случае вызова функции. Т.е. просмотра на одну лексему вперед достаточно, чтобы понять, что перед нами -- вызов функции.
Вот именно. А контроль за арностью — это уже задача следующего уровня.
То есть, LL(немного)-язык с шаблонами — вполне достижим. Хотя, возможно, уже неактуален?
Здравствуйте, Трурль, Вы писали:
Т>...Кстати, в русском языке глаголы несовершенного вида тоже не имеют будущего времени.
Это куда она пропала? В русском языке есть две формы будущего времени: простая и составная. Для глаголов несовершенного вида используется составная форма: будет делать. У совершенного вида — сделает. Другое дело, что у глаголов совершенного вида в русском языке нет настоящего времени.
Здравствуйте, Пацак, Вы писали:
П>Человек не машина, не математическая модель и не парсер, ему удобно то, что он считает удобным, ни больше ни меньше.
// make c readable#define O printf
#define R return
#define Z static
#define P(x,y) {if(x)R(y);}
#define U(x) P(!(x),0)
#define SW switch
#define CS(n,x)case n:x;break;
#define CD default
#define DO(n,x){I i=0,_i=(n);for(;i<_i;++i){x;}}
Здравствуйте, Дарней, Вы писали:
Т>>Нет. Cмысл в том, что грамматически future tense вообще отсутствует.
Д>Тем не менее, будущее время в языке есть, хотя и выражается только с помощью вспомогательного глагола.
Фразу "есть в языке" можно понимать как "выразимо средствами языка" или "отражено грамматикой языка". В первом случае класс того, что "есть в языке" гораздо шире. Например, в русском нет давнопрошедшего времени, но выразить его вполне возможно.
ПК> Фактически, это синтаксическая неразличимость между type guard (*) и вызовом процедуры.
Вот фрагмент парсера Component Pascal:
...
ELSIF sym = lparen THEN
IF (x.obj # NIL) & (x.obj.mode IN{XProc, LProc, CProc, TProc}) THEN typ := x.obj.typ
ELSIF x.typ.form = ProcTyp THEN typ := x.typ.BaseTyp
ELSIF x.class = Nproc THEN EXIT (* standard procedure *)ELSE typ := NIL
END;
IF typ # DevCPT.notyp THEN
DevCPS.Get(sym);
IF typ = NIL THEN(* type guard *)IF sym = ident THEN
qualident(obj);
IF obj.mode = Typ THEN DevCPB.TypTest(x, obj, TRUE)
ELSE err(52)
END
ELSE err(ident)
END
ELSE(* function call *)
pre := NIL; lastp := NIL;
DevCPB.PrepCall(x, fpar);
IF (x.obj # NIL) & (x.obj.mode = TProc) THEN DevCPB.CheckBuffering(x.left, NIL, x.obj.link, pre, lastp)
END;
ActualParameters(apar, fpar, pre, lastp);
DevCPB.Call(x, apar, fpar);
IF pre # NIL THEN DevCPB.Construct(Ncomp, pre, x); pre.typ := x.typ; x := pre END;
IF level > 0 THEN DevCPT.topScope.link.leaf := FALSE END
END;
CheckSym(rparen)
ELSE EXIT
END
ELSE EXIT
END
работа всегда идет не более чем с одним единственным словом sym.
DevCPS — сканер
DevCPS.Get(sym); — считывание следующего слова.
Сергей,
> ПК> Фактически, это синтаксическая неразличимость между type guard (*) и вызовом процедуры.
> Вот фрагмент парсера Component Pascal: >
> ...
> IF typ = NIL THEN(* type guard *)
> <...>
> ELSE(* function call *)
> <...>
> END;
>
> работа всегда идет не более чем с одним единственным словом sym.
На этом основании эта грамматика LL(1) не становится, т.к. процитированное выше обращение к таблице символов во время разбора выходит за рамки операций, доступных LL-автомату. Не всякий парсер, разбирающий синтаксис, оперируя по одной лексеме за раз, является LL-парсером/автоматом.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Трурль, Вы писали:
Т>Просто этот самый "кто-то" считает, что именно в таком виде С становится читаемым.
И кто же этот коварный "кто-то"? Покажи пальчико плз. Ладно пальцем некультурно, лучше ссылкой. Насколько я знаю define стали вчерашним днем с момента появления C++. Не говоря уж про C#, в котором (Vlad2 меня поправит если что) их вообще нет. Может хватит бегать со страшилками двадцатилетней дваности?
Здравствуйте, Пацак, Вы писали:
П>И кто же этот коварный "кто-то"? Покажи пальчико плз. Ладно пальцем некультурно, лучше ссылкой. Насколько я знаю define стали вчерашним днем с момента появления C++. Не говоря уж про C#, в котором (Vlad2 меня поправит если что) их вообще нет. Может хватит бегать со страшилками двадцатилетней дваности?
Вот насчет двадцатилетней давности — это похоже на правду. В те времена набрать с клавиатуры текст программы было довольно-таки напряжно: удаленный доступ, скорость 1200 б/с счастьем считалась. Ошибки в наборе исправлять — тоже целое дело. Поэтому в данном конкретном случае такой подход можно понять. Единственный раз в жизни попробовал. Причем на гораздо более высокой скорости.
Кстати, программа, которую я вводил, писалась на Паскале. Кажется, с тех пор я его стараюсь избегать. Наверное, Паскаль и не виноват, но ассоциация осталась.
Здравствуйте, Трурль, Вы писали:
Т>Фразу "есть в языке" можно понимать как "выразимо средствами языка" или "отражено грамматикой языка". В первом случае класс того, что "есть в языке" гораздо шире. Например, в русском нет давнопрошедшего времени, но выразить его вполне возможно.
Здравствуйте, Павел Кузнецов, Вы писали:
> работа всегда идет не более чем с одним единственным словом sym.
ПК>На этом основании эта грамматика LL(1) не становится, т.к. процитированное выше обращение к таблице символов во время разбора выходит за рамки операций, доступных LL-автомату. Не всякий парсер, разбирающий синтаксис, оперируя по одной лексеме за раз, является LL-парсером/автоматом.
Спорить не буду. Наверное Вам виднее если Вы так утверждаете. Просто я всегда думал что если текст парсится методом рекурсивного спуска с чтением только одного слова, то грамматика — LL(1). Ну нет так нет... Кстати, а название у таких грамматик есть? Если нет, то давайте такие грамматики условно назвать RDP(1), где RDP происходит от Recursive Descend Parsing.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Павел Кузнецов, Вы писали:
>> работа всегда идет не более чем с одним единственным словом sym.
ПК>>На этом основании эта грамматика LL(1) не становится, т.к. процитированное выше обращение к таблице символов во время разбора выходит за рамки операций, доступных LL-автомату. Не всякий парсер, разбирающий синтаксис, оперируя по одной лексеме за раз, является LL-парсером/автоматом.
СГ>Спорить не буду. Наверное Вам виднее если Вы так утверждаете. Просто я всегда думал что если текст парсится методом рекурсивного спуска с чтением только одного слова, то грамматика — LL(1). Ну нет так нет... Кстати, а название у таких грамматик есть? Если нет, то давайте такие грамматики условно назвать RDP(1), где RDP происходит от Recursive Descend Parsing.
Несколько неверный термин, правильнее видимо Recursive descent parser
(descend в английском не есть существительное... )
Здравствуйте, Пацак, Вы писали:
Т>>Просто этот самый "кто-то" считает, что именно в таком виде С становится читаемым.
П>И кто же этот коварный "кто-то"? Первый в списке
П>Может хватит бегать со страшилками двадцатилетней дваности?
Сергей,
> ПК> На этом основании эта грамматика LL(1) не становится, т.к. процитированное выше обращение к таблице символов во время разбора выходит за рамки операций, доступных LL-автомату. Не всякий парсер, разбирающий синтаксис, оперируя по одной лексеме за раз, является LL-парсером/автоматом.
> Спорить не буду. Наверное Вам виднее если Вы так утверждаете. Просто я всегда думал что если текст парсится методом рекурсивного спуска с чтением только одного слова, то грамматика — LL(1). Ну нет так нет...
Можно найти где-нибудь описание того, как строится LL-автомат; там нет ничего сложного. Возможность построения LL(1)-автомата для данной грамматики является способом определения, что она относится к LL(1). На практике заключение обычно строят в обратную сторону: если грамматика LL(1), то можно гарантированно построить recursive descent parser. Если же есть какой-то произвольный recursive descent parser, то LL(1) соответствующая грамматика будет только если этот парсер является LL(1)-автоматом, т.к. парсер может содержать, например, backtracking и "ручное" разрешение конфликтов, даже выбирая лексемы по одной.
> Кстати, а название у таких грамматик есть? Если нет, то давайте такие грамматики условно назвать RDP(1), где RDP происходит от Recursive Descend Parsing.
Это мало что даст для данного обсуждения. Скажем, тот же "монстрик" C++ разрабатывался с тем, чтобы для него было относительно легко писать рекурсивный спуск вручную. Проблемы во front-end С++ не в структуре парсера, а в массе нюансов с перегрузкой, разрешением имен и т.п. Backtraking, правда, действительно осложняет жизнь по сравнию с разбором Оберона, в котором это, судя по всему не нужно.
Так или иначе, это все слабо относится к первоначальному тезису об улучшении читабельности при упрощении класса (и объема?) грамматики.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Трурль, Вы писали:
Т>>Нет. Cмысл в том, что грамматически future tense вообще отсутствует.
Д>Тем не менее, будущее время в языке есть, хотя и выражается только с помощью вспомогательного глагола.
Это неполноценное будущее время, в отличие от будущего времени в романских языках. will означает лишь намерение, у английских глаголов нет формы будущего времени.
Кодт,
> Да, именно: не различать массивы и функции. В конце концов, васик с фортраном обходятся.
В смысле? Речь идет о впихивании этого хозяйства в LL(1). Ты уверен, что грамматики Basic и Fortran LL(1)?
> Опять же, удобно будет многомерные индексы делать; сейчас в С++ для этого приходится извращаться вокруг адаптеров оператора[].
Это не из-за ограничений LL(1).
> Применимость и арность оператора() в любом случае требует контекстной зависимости — но уже после синтаксического разбора. Так что нет проблем с применимостью и арностью шаблонного метаоператора[] (или <>, если продолжить традиции С++).
Это все зависит от полной грамматики. Если из-за того, что не различаются массивы и функции появятся более серьезные неоднозначности, то это работать не будет.
> ПК>Там такой неоднозначности нет, т.к. скобка после идентификатора может и должна присутствовать только в случае вызова функции. Т.е. просмотра на одну лексему вперед достаточно, чтобы понять, что перед нами -- вызов функции. > > Вот именно. А контроль за арностью — это уже задача следующего уровня.
Арность здесь, также как и контроль типизации, значения не имеет. Главное, чтобы разобрать до нужного уровня можно было.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Курилка, Вы писали:
К>>Теперь очень сложный вопрос — смысл читаемого это грамматика или семантика?
СГ>1) Понять что написано — это одно. СГ>2) Понять, что написанная программа будет делать, как будет делать и почему — это другое.
СГ>Моя фраза относится к пункту (1).
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Кодт,
>> Да, именно: не различать массивы и функции. В конце концов, васик с фортраном обходятся.
ПК>В смысле? Речь идет о впихивании этого хозяйства в LL(1). Ты уверен, что грамматики Basic и Fortran LL(1)?
В смысле, что читаемость это не сильно ухудшает, зато выражения становятся LL(1).
А то, что фортран — не LL(1) — это стопудово. Там какая-то несложная контекстно-зависимая грамматика.
>> Опять же, удобно будет многомерные индексы делать; сейчас в С++ для этого приходится извращаться вокруг адаптеров оператора[].
ПК>Это не из-за ограничений LL(1).
Это понятно. Просто, если мы вообще забиваем на различение сабскрипта и вызова функции, то внешний вид встроенных и рукодельных матриц совпадёт.
int plain_matrix(2,3);
int* jagged_matrix(2);
CMatrix matrix_look_n_feel;
int v = plain_matrix(1,1) + jagged_matrix(1,1) + matrix_look_n_feel(1,1);
>> Применимость и арность оператора() в любом случае требует контекстной зависимости — но уже после синтаксического разбора. Так что нет проблем с применимостью и арностью шаблонного метаоператора[] (или <>, если продолжить традиции С++).
ПК>Это все зависит от полной грамматики. Если из-за того, что не различаются массивы и функции появятся более серьезные неоднозначности, то это работать не будет.
С чего бы им взяться?
В вычислимых выражениях всё однозначно. Синтаксис унифицирован, а семантика вот такая.
Если слева от оператора() — выражение типа, то это конструктор. Если слева объект, то это субскрипт-или-вызов.
Если тип объекта — встроенный массив (или приравненный к нему указатель — кстати, тоже вопрос, есть ли в этом смысл), то оператор() — это сабскрипт. Если Иначе — это вызов функции.
В случае k-мерных массивов, можно принять решение:
— допустимы только k-арные формы (доступ к элементам, но не к срезам массивов)
— допустимы только 1..k-арные формы (доступ к срезам)
— первые k аргументов n-арной формы — доступ к элементу, оставшиеся n-k применяются как n-k-арный оператор() этого элемента.
Тем самым мы получаем "карринг наоборот", создавая
— иерархические многомерности
— замена эллипсису в вызовах функций. Не далее как в августовском CUJ Александреску предложил вариант printf'а на карринге: printf(format)(arg1)(arg2)итд. А так синтаксически будет корректно printf(format,arg1,arg2,итд).
А в случае неоднозначностей сигнатур — пусть юзер сам правильно расставит скобки, иначе пошлём или пойдём по наиболее симпатичному направлению. Эту задачу семантический анализатор С++ решать умеет.
В выражения типов — тут да, есть много интересного. Но если не требовать, чтобы выражение типа выглядело так же, как соответствующий вызов конструктора, то какие проблемы. Нечто в паскалевском стиле, например.
>> ПК>Там такой неоднозначности нет, т.к. скобка после идентификатора может и должна присутствовать только в случае вызова функции. Т.е. просмотра на одну лексему вперед достаточно, чтобы понять, что перед нами -- вызов функции. >> >> Вот именно. А контроль за арностью — это уже задача следующего уровня.
ПК>Арность здесь, также как и контроль типизации, значения не имеет. Главное, чтобы разобрать до нужного уровня можно было.
Пофигу. Построим AST, в котором присутствуют и операторы(), и метаоператоры[] — а уже потом будем смотреть, можно ли применять их.
Поскольку оба этих оператора — постфиксные, у них одинаковый приоритет (самый высокий). Конфликтовать между собой они не будут.
А путаница между ( как префиксным оператором самого низкого приоритета и как постфиксным самого высокого — разрешается в LL(1)-грамматике с лёгкостью.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Так или иначе, говоря о том, что грамматика Оберона-2 является LL(1), нужно уточнять, о какой именно грамматике идет речь. "Официальная" LL(k) не является.
>> Действительно, две ветки синтаксического разбора в следующем определении >>
>> начинаются с левой круглой скобки, но это не приводит к просмотру вперед более, чем на один символ (т.е. для определения ветки следующая за скобкой лексема не требуется).
ПК>В данном случае это приводит к принципиальной неразрешимости того, по какой из веток пойти; вне зависимости от дальности заглядывания вперед. Т.е. это вообще не LL(k).
Насколько я понял, LL(1) — обязательно контекстно-свободная грамматика.
В таком случае, грамматика Оберона — не LL(1).
Меня заинтересовало, сколько еще в грамматике Оберона "отступлений" от LL(1).
Кроме уже указанной ситуации, я нашел еще одно-единственное место:
Qualident = [ ident "." ] ident .
вызывает неоднозначность разбора в начале Designator.
Других "отступлений" вроде бы нет.
Не знаю, почему Вирт оставил эти два исключения, ведь их легко было устранить (всего два).
Возможно, это исправление "утяжелило" бы язык.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC,
> ПК>В данном случае это приводит к принципиальной неразрешимости того, по какой из веток пойти; вне зависимости от дальности заглядывания вперед. Т.е. это вообще не LL(k).
> Насколько я понял, LL(1) — обязательно контекстно-свободная грамматика.
И непременно однозначная (контекстно-свободная может содержать неоднозначности), плюс еще некоторые требования, которые проще всего формулируются и верифицируются тем, что для грамматики строится LL(1)-автомат.
> В таком случае, грамматика Оберона — не LL(1).
Согласен.
> Меня заинтересовало, сколько еще в грамматике Оберона "отступлений" от LL(1). > Кроме уже указанной ситуации, я нашел еще одно-единственное место: >
> Qualident = [ ident "." ] ident .
> вызывает неоднозначность разбора в начале Designator. > Других "отступлений" вроде бы нет.
Мне попалась статейка человека, делавшего для Oberon-2 парсер. Там, кроме уже упомянутых нами, описана еще такая неоднозначность:
Здравствуйте, Кодт, Вы писали:
К>Затейливо. Получается, что неоднозначность вида f<g>(h) — то ли сравнение (f<g)>(h) то ли шаблон (f<g>)(h) — трактуется в пользу шаблона. К>Головнячок для программистов
(f<g>)(h)
просто не корректный синтаксис. В прочем как и:
(f<g)>(h)
В первом случа будет расценен как приведение типов, в котором имя фнкции будет вспрнято как ошибка.
Во втором "(f<g)" однозначно воспринимается как сравнение, но сравнение возвращает bool который нельзя сравнивать на больше-меньше. Короче получишь два внятных сообщения об ошибке.
Так что "f<g>(h)" любым человеком трактуется как вызов метода. И не как подругому.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Пацак, Вы писали:
П>И кто же этот коварный "кто-то"? Покажи пальчико плз. Ладно пальцем некультурно, лучше ссылкой. Насколько я знаю define стали вчерашним днем с момента появления C++. Не говоря уж про C#, в котором (Vlad2 меня поправит если что) их вообще нет. Может хватит бегать со страшилками двадцатилетней дваности?
Поправит. Они таки есть, но ими можно объявлять только значения препроцессора:
#define X
Но нельзя:
#define X(y) y
#define Z 1
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
СГ>>...Recursive Descend Parsing.
К>Несколько неверный термин, правильнее видимо Recursive descent parser К>(descend в английском не есть существительное... )
Да по-русски будет как-то вроде "убийство при рекурсивных разборках".
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AVC, Вы писали:
AVC>Других "отступлений" вроде бы нет. AVC>Не знаю, почему Вирт оставил эти два исключения, ведь их легко было устранить (всего два). AVC>Возможно, это исправление "утяжелило" бы язык.
Мораль истории в том, что иногда исправление 1% ошибок занимает 500% усилий. Это присуще не только программированию, что я могу сказать после того как я занимался всеми этими строительными работами. На прошлой неделе, наконец, наши рабочие наконец-то сделали последние штрихи к нашему новому офису Fog Creek. Это состояло из установки на входные двери блестящего синего акрила, окантованного алюминиевой рамкой, привинченной шурупами через каждые 20 см. Если вы посмотрите внимательно на фотографию, алюминиевые рамки обрамляют со всех сторон каждую дверь. Когда двери сходятся, то две рамки оказываются прилегающими друг к другу. Вы не увидите это на фотографии, но винты в серединных секциях почти, но не совсем совпадают. Они, может быть, на 2 миллиметра, но расходятся. Плотник, сделавший их, отмерял аккуратно, но он устанавливал рамки когда двери были на полу, то есть ещё не установлены, но "опс!", вдруг стало очевидно, что они не совпадают.
Возможно, это и не так уж необычно -- в нашем офисе много шурупов, которые не винчены точно по линейке. Проблема в том, что исправление этого уже после того, как отверстия просверлены -- необычайно дорого. Несмотря на то, что правильное положение шурупов всего в паре миллиметров от того как есть сейчас, вы не можете просто просверлить новые отверстия -- скорее всего вам придётся заменить всю дверь. Это не стоит того. Это как раз тот случай, когда исправление 1% ошибок займёт 500% усилий и объясняет почему в нашем мире столько много вещей хороших на 99%, а не на все 100%. (Наш архитектор не прекращает говорить об одном очень, очень дорогом доме в Аризоне, где каждый шуруп точно выверен.)
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Мне попалась статейка человека, делавшего для Oberon-2 парсер. Там, кроме уже упомянутых нами, описана еще такая неоднозначность: ПК>
ПК>Но в отличие от неоднозначности type guard vs. вызов процедуры эти устраняются простым переупорядочиванием грамматики.
В принципе, неоднозначность type guard vs function может быть отложена на стадию семантического разбора.
Если мы заявим, что у любого типа есть встроенная унарная функция с аргументом "тип" (которая выполняет приведение),
то любые конструкции вида any_expression(any_expression) становятся легальными (до тех пор, пока мы не начнём более тщательно их изучать).
Главное, что эта неоднозначность локальна: от её правильности/неправильности не меняется смысл даже остальной части выражения, не говоря уже о последующих стейтментах.
В отличие от С++, где семантическая информация влияет на синтаксис:
a & b; // неоднозначность номер раз: объявление ссылки или бинарная операция
.....
b . c < d > ( e ); // влияет на неоднозначность два: шаблонный член или цепочка сравнений
b . c < d ; // ошибка или нет?
Здравствуйте, AVC, Вы писали:
AVC>Кроме уже указанной ситуации, я нашел еще одно-единственное место: AVC>
AVC>Qualident = [ ident "." ] ident .
AVC>вызывает неоднозначность разбора в начале Designator.
Кстати, это полная дурь. Квалифицированный идентификатор по идее должен содержать более двух секций. Обычно его объявляют так:
Qualident = ident {"." ident }.
И даже если нужно именно только дно повторение, то можно было бы описать его так:
Qualident = ident ["." ident ].
Так что это просто кривая грамматика.
AVC>Других "отступлений" вроде бы нет. AVC>Не знаю, почему Вирт оставил эти два исключения, ведь их легко было устранить (всего два). AVC>Возможно, это исправление "утяжелило" бы язык.
А как же теория Губанова о том что LL(1)-грамматика проще не LL(1)?
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVC>>Кроме уже указанной ситуации, я нашел еще одно-единственное место: AVC>>
AVC>>Qualident = [ ident "." ] ident .
AVC>>вызывает неоднозначность разбора в начале Designator.
VD>Кстати, это полная дурь. Квалифицированный идентификатор по идее должен содержать более двух секций. Обычно его объявляют так: VD>
VD>Qualident = ident {"." ident }.
VD>
VD>И даже если нужно именно только дно повторение, то можно было бы описать его так: VD>
VD>Qualident = ident ["." ident ].
VD>
VD>Так что это просто кривая грамматика.
Это не совсем полная дурь. Дело в том что "многоточечные" идентификаторы могут обозначать только переменную, но не тип. Тип всегда либо просто ident либо "одноточечный" ident.ident, причем первый из них есть имя модуля (или синоним имени модуля). То есть в тех местах где парсер ожидает появление типа, он может искать "ident" или "ident.ident", т.е. Qualident. Таким образом Qualident объявленный как
[ ident "." ] ident
специально ориентирован на разбор объявления типа "ModuleName.TypeName".
Сейчас посмотрел на BlackBox-овский парсер Component Pascal, там процедуры отвечающей за разбор Designator нету вообще. То есть, например, внутри процедур отвечающих за разбор Statement и Factor разбор того что в грамматике описано как Designator делается как бы "непосредственно на месте", в этом смысле нетерминал Designator можно было бы в описании грамматики "сократить" — путем непосредственной подстановки в нужные места.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Таким образом Qualident объявленный как СГ>[ ident "." ] ident СГ>специально ориентирован на разбор объявления типа "ModuleName.TypeName".
И что мешат написать
ident [ ident "." ]
?
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Таким образом Qualident объявленный как СГ>>[ ident "." ] ident СГ>>специально ориентирован на разбор объявления типа "ModuleName.TypeName".
VD>И что мешат написать VD>
VD>ident [ ident "." ]
VD>
VD>?
Наверное, то, что изначально в грамматике было
IdentChain ::= QualIdent { '.' Ident }
QualIdent ::= [ ModuleIdent '.' ] Ident
ModuleIdent ::= ident
Ident ::= ident
# где ModuleIdent - семантически, имя модуля,
# а Ident - идентификатор в scope модуля и ниже
# в случае с типами можно было даже тщательнЕе написать
TypeIdent ::= ident
QualTypeIdent ::= [ ModuleIdent '.' ] TypeIdent
TypeGuard ::= QualIdent '(' QualTypeIdent ')'
Designator ::= TypeGuard | etc...
а потом какая-то добрая душа сделала premature optimization.
Конечно, получаем КЗ, но по крайней мере, осмысленную. Более того, если подружить лексер с семантическим анализатором, то классифицировать идентификаторы можно будет на ранней стадии, и тогда вообще получается, что ModuleIdent, TypeIdent, Ident — это разные терминальные символы.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Регулярные выражения описываются регулярной грамматикой. Еще проще чем LL(1). Читаются очень нелегко, если нет соответствующего навыка.
А почему вы спрашиваете,
> ПК> Регулярные выражения описываются регулярной грамматикой. Еще проще чем LL(1). Читаются очень нелегко, если нет соответствующего навыка.
> Да ну? А скобки куда девать будем?
Ага, совершенно верно. Неправильно написал. Достаточно было указать, что они сами описываются LL(1).
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, xBlackCat, Вы писали:
BC>Здравствуйте, eao197, Вы писали:
E>>За точность цитаты не ручаюсь, но все же: E>>
E>>Однажды на светском приеме к Бернарду Шоу, у которого была страшноватая внешность, подошла знаменитая светская красавица и сказала: "О, мистер Шоу, я много о вас слышала и знаю, что вы очень умный. Представляете себе, какие у нас были бы дети? Они обладали бы моей внешностью и вашим умом". Бернард Шоу сказал: "Это очень хорошо, но представьте, что будет, если наши дети будут обладать моей внешностью и вашим умом?"
BC>На сколько я помню, наследование происходит чаще всего так, как говорит Бернард Шоу. Хорошо, что он отказал
Это надо в эпиграф к курсу по ООП.
. Если хочешь совета, их есть у меня 
Италик убери нафиг, лучше всё одним шрифтом, ну в крайнем случае — что-нибудь болдом выделять, хотя, имхо, и это от лукавого, а выделять надо только цветом. 
Ты хоть на оценки то поглядел? Всем просто смешно это читать.
Если верить статье
Перекуём баги на фичи!
