Здравствуйте, 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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Перекуём баги на фичи!
