Здравствуйте, Кодт, Вы писали:
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 абсолютно монопенисуальна.
А вот при выборе текстового представления кода надо ориентироваться именно на "нравится/не нравится" в первую очередь.
Перекуём баги на фичи!
