Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, prVovik, Вы писали:

V>>>синтаксических ошибок нет,
V>>что означает фраза "синтаксических ошибок нет"?

V>Собственно, во мнениях на теорию языков уже сошлись, просто поимей ввиду теперь прикладной раздел — построение компиляторов. Именно из-за их многоуровневой схемы различают синтаксические и семантические ошибки.

Вот если бы ты поимел ввиду его тоже, и заодно поглядел стандарты языков, то тоже не спорил бы о том является ли граматика из стандартов (или применяемая при построении компиляторов) КС. Так граматике C# четно написано, что get — это токен, а раз так граматика 100%-но имеет КС-двусмысленности, а значит является КЗ.

Постраение парсеров языков подобных C++ и C# просто не мыслемо без лексеров, и составители граматик для этих языков принципиально закладываются на лексеры и строят грамматику на базе абстрактных токенов, а не отдельных символов.

VladD2,

> Ш> Учи матчасть, двоешник. В частности, разбери на досуге, что такое терминал и нетерминал.

> Переходить на оскорбления, значит расписываться в собстенной несостоятельности и не правоте. А раз так, разговаривать не очем.

> 2ПК: Ставить плюсы на сообщениях содержащих откровенные оскорбления, значит присоеденяться к ним.

В данном случае я согласен со вторым предложением сообщения Шахтера.

<off>
Тем не менее, пользуясь случаем, полагаю уместным обратить твое внимание на то, что я не воспринимаю факт называния кого-то "двоешнком" в сочетании с указанием на ошибки в неправильном употреблении базовых терминов большим оскорблением, чем неаргументированное "уличение" оппонента в "поверхносном знании принципов постоения компиляторов", в третьем лице, в сообщении, адресованном другому человеку, который к тому же напрямую обратился к тому, кого ты "уличаешь" за соответствующими разъяснениями, каковые последовали. И все это вместо реакции на прямое объяснение

Автор: Павел Кузнецов
Дата: 20.11.04

"уличаемым" своей позиции.

Не удивляйся, если обжигает, если сам принимаешь участие в подогревании атмосферы

Извини, но на любую попытку развития дискуссии в сторону обсуждения сравнительных характеристик оскорбительности данных приемов, равно как и объяснения, почему именно с твоей точки зрения кто-то недостаточно хорошо разбирается в той или иной области, отвечать не собираюсь: и без того уже не первый раз отвечаю на сообщения того типа, который обычно предпочитаю игнорировать. А именно, сообщения, в которых происходит переход к обсуждению личных качеств оппонента вместо обсуждения предмета дискуссии.

Реагировать буду только на сообщения по существу дискуссии.
</off>

Здравствуйте, VladD2, Вы писали:

VD>Переходить на оскорбления, значит расписываться в собстенной несостоятельности и не правоте. А раз так, разговаривать не очем.

VD>2ПК: Ставить плюсы на сообщениях содержащих откровенные оскорбления, значит присоеденяться к ним.

Здравствуйте, VladD2, Вы писали:

VD>Вот если бы ты поимел ввиду его тоже, и заодно поглядел стандарты языков, то тоже не спорил бы о том является ли граматика из стандартов (или применяемая при построении компиляторов) КС. Так граматике C# четно написано, что get — это токен, а раз так граматика 100%-но имеет КС-двусмысленности, а значит является КЗ.

VD>Постраение парсеров языков подобных C++ и C# просто не мыслемо без лексеров, и составители граматик для этих языков принципиально закладываются на лексеры и строят грамматику на базе абстрактных токенов, а не отдельных символов.

Я вот чего-то не понял смысла твоих высказываний. Это появилась какая-то новая наука о токенах, которую я благополучно проспал?

Вообще-то, в ходе своих рассуждений я использовал тот принцип, что грамматика относится к наименьшему классу, в терминах которого представима. Т.е. я лишь доказывал факт представимости твоей конструкции в КС, что доказывало целевой постулат.

------
Но приколы с тобой на этом еще не заканчиваются. Весь комизм ситуации в том, что, даже используя технику лексер-парсер это тоже можно решить. (я утверждал что решить трудно, но не говорил, что невозможно).

1. Пусть лексический анализатор при выделении токена "get" выдает как нетерминал Keyword_get (а не IDentificator, аналогично для других ключевых слов)
2. Пусть все остальные идентификаторы обзначаются неким промежуточным символом: CommonIdentificator.

Тогда в правилах синтаксического анализатора напишем следующее:

Identificator ::= CommonIdentificator | Keyword_get | Keyword_add и т.д.

Теперь везде используй введенный символ Identificator.
а целевую конструкцию опиши так:

GetPropBody ::= Keyword_get '{' Expressions '}'.
SetPropBody ::= Keyword_set '{' Expressions '}'.
GetSetPropBody ::= (GetPropBody SetPropBody) | (SetPropBody GetPropBody).
Property ::= Modifiers TypeIdentificator Identificator '{' (GetPropBody | SetPropBody | GetSetPropBody) '}'.

И все будет чудесно работать даже с лексером и парсером.
т.е. такая конструкция разбереться на "ура":

public class Class1 {
    public class set {}
    public set get { get { return new set(); } }
}

определение св-ва с именем get типа set.

Здравствуйте, VladD2, Вы писали:


VD>Ты же предлагаешь строить парсер как тот изумительный Фортнан 77, т.е. из терминалов размером в симвовл и с учетом всех возможных поялений проблеов. Другими словами на другой лексической базе. Но и так построить корретный парсер будет неимоверно сложно, так как те же пробельные символы начнут быть зависимыми от контекста.
Тот изумительный Фортран работает в 2-х режимах, я просто об этом не упомянул. Во втором режиме он ждет пробелы.


VD>Например, в следующем коде:
VD>

VD>returnget; // ошибка! Но фортрано-подобный сканер ее не заметит!

чем фортрано-подобный сканер отличается от не-фортрано-подобного? может быть только правилами? тогда может и заметить ;)

VD>return(get);
VD>

VD>В первом примере примере пробельные символы обязательно обязаны учитываться, так как иначе он как Фортране распознается правильно, а во втором не как необязательные. Ну, и как записать такую граматику?

упрощенно так:

DelimiterChar ::= ' ' | '\t' | '\n' | ... и т.д.
Delimiter ::= DelimiterChar | (DelimiterChar Delimiter).

Expression ::= сложные правила для выражений.
Expression ::= [Delimiter] Expression [Delimiter].
Expression ::= '(' Expression ')'.

Identificator ::= Alpha | (Identificator (Alpha | Digit)).
ReturnExpression ::= Keyword_return | (Keyword_return Expression) ';'

вот и все.
returnget будет распознан как Identificator,
return(get) как (Keyword_return Expression => ReturnExpression).



и т.д.

Здравствуйте, vdimas, Вы писали:

последняя строка должна быть так:

V>ReturnExpression ::= Keyword_return | (Keyword_return Expression) [Delimiter] ';'
V>

Здравствуйте, vdimas, Вы писали:

V>запись 'g' 'e' 't' — это непрерывная цепочка терминалов "get", откуда тебе приснилось g_e_t?

Попробую объяснить. Я отталкивался от спцификации в котрой дана граматика языка. Причем дана четко:

9.2.1 Lexical grammar The lexical grammar of C# is presented in §9.2.3, §9.4, and §9.5. The terminal symbols of the lexical grammar are the characters of the Unicode character set, and the lexical grammar specifies how characters are combined to form tokens (§9.4), white space (§9.3.3), comments (§9.3.2), and pre-processing directives (§9.5).

9.4 Tokens There are several kinds of tokens: identifiers, keywords, literals, operators, and punctuators. White space and comments are not tokens, though they act as separators for tokens.

token:: 
  identifier 
  keyword 
  integer-literal 
  real-literal 
  character-literal 
  string-literal
  operator-or-punctuator

17.6.2 Accessors
The accessor-declarations of a property specify the executable statements associated with reading and writing that property.

accessor-declarations:
    get-accessor-declaration set-accessor-declarationopt
    set-accessor-declaration get-accessor-declarationopt
get-accessor-declaration:
    attributesopt accessor-modifieropt get accessor-body
set-accessor-declaration:
    attributesopt accessor-modifieropt set accessor-body
    accessor-modifier: 
    protected 
    internal 
    private 
    protected internal 
    internal protected 
accessor-body: 
    block 
;

The accessor declarations consist of a get-accessor-declaration, a set-accessor-declaration, or both. Each accessor declaration consists of the token get or set followed by an accessor-body. For abstract and extern properties, the accessor-body for each accessor specified is simply a semicolon. For the accessors of any non-abstract, non-extern property, the accessor-body is a block which specifies the statements to be executed when the corresponding accessor is invoked.

Для тех, кому тяжело читать по-английски, вкратце объясню суть. Грамматика языка сразу описывает принцип разбиения на токены и в дальнейшем, при описании синтаксического анализатора, грамматика строится исходя из того, что токенами (терминалами) являются отдельные ключевые слова, идентификаторы и т.п. Другими словами минимальными словами грамматики являются токены из числа которых принципиально исключены пробельные символы.

Приведенная тобой грамматика:
1. Не будет соответствовать стандарту.
2. Неверна если у парсера не будет в качестве токенов пробельных токенов. Рри наличии пробельных токенов будет очень сложно удержать в соотвествии со стандартом (если вообще возможно), так как пробельные токены придется засовывать всюду, причем во многих случаях они начнут зависеть от контекста.

V>работать можно заставить что угодно, была бы настойчивость.

Красивая и одновременно неверная фраза. Попробуй, например, заставить работать любой механизм противоречащий законам физики. Пусть даже эти законы верны только на одной планете, но заставить работать механизм нужно именно на ней.

Точно так же если скормить свою грамматику EBNF-совместимому построителю пасреров вроде CocoR, то ничего хорошего не выйдет. Все известные мне EBNF-парсеры рассчитаны на работу по двухфазной схеме и обычно уже включают в себя лексер.

V>КС грамматики разбираются КЗ-распознавателями,

Естественно, но ты как раз говоришь об обратном.

V>аналогично РГ разбираются КС-распознавателями.

РГ — это регулярные грамматики типа регулярных выражения? Тоже вполне естественно, так как это частный случай КС-грамматики.

V>Тебе говорят о том, что конкретное правило приводимо к КС.

Так. Давай определимся. Есть грамматика. У нее есть свои терминалы. В грамматику C++ и C# заложены в качестве нетерминалов токены среди которых есть идентификатор и ключевые слова.

Ответь без лишней философии можно ли отталкиваясь от этих предпосылок считать грамматику C#-а полностью удовлетворяющей требованиям КСГ?

V>То, что ты не стал приводить я понял еще много постов назад.

То что ты предлагаешь называетя не "привести", если называть вещи своими именами называется "переписать граматиу изменив набор ее терминалов". То есть написать другую граматику способную распознаовать конструкции того же языка. Я и не думал переписывать ее по той причине, что в условиях реального мира это сделать практически невозможно. Выкинуть лексер и отказаться от отфильтровывания пробельных симловол и комментариев означает заранее завалить проект. Ведь ни построители парсеров на это не рассчитаны (не писать же свой ради такой улупости?), ни имеющаяся грамматика. Подобный шаг, на практике, можно осуществить если создать некий механизм позволяющий преобразовать некую КЗГ в более общую КСГ. Но о подобных я даже и не слышал.

Попробуй переписать граматику сам... То что ты привел в посте выше — был полностью нерабочий вариант, так как он не учитывал пробельных символов и т.п. А ведь это был очень маленький фрагмент граматики. Меньше одного процента.

V> — в твоем R# участвует лексический анализатор, он бъет на лексемы. Выход лексического анализатора — суть его нетерминалы ,

Да. И это соответствует стандарту (п. 9.2.1. приведенный выше).

V> являются терминальными символами для твоего синтаксического анализатора.

Именно!

V> Лексичесике анализаторы применяются только лишь:
V>- с целью "разгрузить" грамматику синтаксического анализатора

Это теория очень далекая от жизни. Реально языки уже проектируются в терминах нетерминалов. Ни одни проектировщик языка на сегодня не работает на уровне букв и цифр. Ты же заявляешь о том, что некая граматика является КС если ее можно переписать в КС. Но это не логическая ошибка. Вот если ее преписать, то она и станет КСГ, а до тех пор она КЗГ. А так как переписать ее подобным образом не представляется возможным, то о чем разговор я не понимаю.

V>- с целью повышения эффективности, ибо регулярные грамматики очень шустро разбираются по простым алгоритмам (тот же ДКА).

Плохой аргумент, так как те же LALR(1)-парсеры строят алгоритм распознавания на базе того же ДКА. Так что эффективность тут не причем. В конце концов дополнительный проход эффективности точно не прибавляет.

Реально при парсинге лексическая стадия вводится для того, чтобы абстрагироваться от символов (в смысле char-ов) и мыслить понятиями нетерминалов целевого языка. Так что лексер это всего лишь средство повышения абстракции, без которого создание и реализация грамматики будет схоже с проектированием и реализацией ПО на уровне машинных кодов.

V>Твой лексер так же "съедает" разделители, ты написал его так, что они не попадают на вход синтаксического анализатора (может поэтому тебе почудился 'g_e_t' ?)

Естественно. Именно потому, что разделители съедаются еще лексером твоя грамматика никак не может быть верной. Да если бы не съедались все равно не могла бы быть верной, так как их пришлось бы указывать между всеми другими терминалами языка. К моту же еще и каким-то загадочным образом определять где они обязательны, а где нет.

Я, для построения пасрера R#, пользуюсь генератором парсеров CocoR который использует в качестве языка описания грамматики EBNF. Так что я в этой области ничего не писал.

В формальной грамматике C#/R#/C++ и им подобных нет разделителей, по этому они обязательно съедаются лексером. Парсер принципиально оперирует с терминалами в числе которых пробельные символы и комментарии отсутствуют. Ну, да я уже устал это повторять.

V>Я же говорил тебе о том, чтобы записать синтаксис языка в одной системе правил.

Что-то до сего сообщения я этого не слышал.

V>И в этой системе правил случай с твоим несчатным get более чем элементарно представим в терминах КС.

Возможно. Но это будет другая грамматика. Сформулированная на базе другого набора терминальных символов. Причем делать это не просто нецелесообразно, а проста такие невозможно. Будет столько проблем, что неоднозначности текущей грамматики покажутся просто цветочками.

V>-------
V>следующим шагом мне останеться только убить час времени и накатать эту систему, если ты еще не понял ход рассуждений и предыдущие посты.

О! Изумительное предложение.

Итак, чтобы подтвердить свои слова создай, плиз, грамматику которую можно будет скормить EBNF-построителю парсеров и скорми ее ему.

Например, я использую собственную модификацию CocoR которую можно взять здесь. Скачай его и попытайся создать грамматику для парсинга отдельно взятого свойства. Только обязательно проверь ее на следующей конструкции:

Xxx Yyy
{
  get
  {
    return get;
  }
}

Xxx Yyy
{
  get
  {
    return g;
  }
}

Xxx Yyy
{get{
    returnget; // тут должна быть ошибка!
  }
}

Причем выделенные жирным конструкции get и g должно распознаваться как идентификатор, а не выделенные get как ключевые слова. Ну, и не должно быть контекстно-зависимых описаний пробельных симвлов.

Чтобы облегчить тебе задачу, я уже написал неверную граматику:

COMPILER Property

    protected Token ProcessPragma(Token curr) { return curr; }
    void BeforeInitTokens() { }


CHARACTERS
    letter  = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".

TOKENS
    ident   = letter { letter }.

    space   = " " | "\t" | "\r" | "\n".

PRODUCTIONS

Spaces = { space }.

Property = Spaces ident Spaces ident Spaces 
    "{" Spaces 
        "get" Spaces 
        "{" Spaces 
            "return" Spaces ident Spaces ";" Spaces 
        "}" Spaces 
    "}" Spaces.

END Property.

И даже создал работающий парсер код которого можно взять здесь:
http://gzip.rsdn.ru/File/73/PropertyParser.ZIP
К сожалению, парсер уже переведен на .Net 2.0 по этому скомпилировать проект можно только 2005-ой студией или msbuild из второго фрэймворка.

Ну, а потом ответь на вопрос возможно ли построить таким образом соответствующий стандарту парсер (причем не гипотетически, а рельно).


ЗЫ

Итак, хотелось бы получить ответ на исходный вопрос: Является ли граматика описанная в стандарте и реализуемая парсерами в компиляторах (реальная, а не гипотетическая переписанная на базе других терминалов) КСГ?

И можно ли не переписывая саму граматику и не вставляя семантических "костылей" сделать ее КСГ?

Здравствуйте, Павел Кузнецов, Вы писали:


ПК>я не воспринимаю факт называния кого-то "двоешнком" в сочетании с указанием на ошибки в неправильном употреблении базовых терминов большим оскорблением,

Что значи большим или малым? Оскорбление есть оскорбление. Тебе приятно будет если я начну использовать подбные эпитеты в случаях когда посчитаю, что ты ошибашся?

ПК> чем неаргументированное "уличение" оппонента в "поверхносном знании принципов постоения компиляторов",

"Уличение" очень даже аргументированное, а вот оскорбление явное, наглое и никак не обоснованное (если вообще можно обосновать оскорбление).

ПК> в третьем лице,

В каком третьем лице? Ты о чем?

ПК>вместо реакции на прямое объяснение

Автор: Павел Кузнецов
Дата: 20.11.04

"уличаемым" своей позиции.

Тут тысячи сообщений почему ты считашь, что именно твое да еше не обращенное напрямую ко мне должно требовать немедленного ответа?

ПК>Не удивляйся, если обжигает, если сам принимаешь участие в подогревании атмосферы

Пашь, я никого сдесь не оскорблял и стараюсь давать настолько аргументированные ответы насколько могу.

Из всей команды оппонентов на достойную аргументацию предоставляет vdimas хотя и его позиция исходит из не очень верных предпосылок. Ну, да хотя бы есть аргументы.

ПК>Извини, но на любую попытку развития дискуссии в сторону обсуждения сравнительных характеристик оскорбительности данных приемов, равно как и объяснения, почему именно с твоей точки зрения кто-то недостаточно хорошо разбирается в той или иной области, отвечать не собираюсь: и без того уже не первый раз отвечаю на сообщения того типа, который обычно предпочитаю игнорировать. А именно, сообщения, в которых происходит переход к обсуждению личных качеств оппонента вместо обсуждения предмета дискуссии.

Ну, т.е. поддержка оскорблений для тебе вполне приемлемое решение?

ПК>Реагировать буду только на сообщения по существу дискуссии.

По существу, я уже сказал. Мало-мальски достойная аргументация есть только у vdimas. А реагировать на заявитальные заблуждения по другому просто тяжело.

Здравствуйте, VladD2, Вы писали:


VD>"Уличение" очень даже аргументированное
А вот про это можно по подробнее. Про аргументы.

VladD2,

> Попробую объяснить. Я отталкивался от спцификации в котрой дана граматика языка. Причем дана четко <...>

Это другой вопрос. Как давным-давно заметил Шахтер, важно уточнять, о какой грамматике идет речь. Как видишь, вы втроем говорили о трех разных грамматиках:

VladD2: о грамматике, приведенной в спецификации;

prVоvik: грамматике, полностью описывающей синтаксис языка (она не может быть КС, т.к. требует предварительного обьявления переменных);

vdimas: о грамматике, эквивалентной первой в плане порождаемого языка, но являющейся контекстно-свободной.

Последнюю грамматику легким движением руки

Автор: vdimas
Дата: 22.11.04

, даже не меняя архитектуры транслятора, можно получить из описанной в стандарте C#, если, конечно, кроме "контекстно-зависимых" ключевых слов в грамматике из спецификации нет других моментов, действительно, не позволяющих преобразовать ее в КС. Последнего пока продемонстрировано не было.

> Приведенная тобой грамматика:
> 1. Не будет соответствовать стандарту.

Грамматика сама по себе не может соответствовать или не соответствовать стандарту. Стандарту может соответствовать или не соответствовать некоторая реализация языка C#. Критерии соответствия реализаций описаны в пункте 2 стандарта C#. Вот полная цитата:

A conforming implementation of C# must accept any strictly conforming program.

A conforming implementation of C# must provide and support all the types, values, objects, properties, methods, and program syntax and semantics described in the normative (but not the conditionally normative) parts in this International Standard.

A conforming implementation of C# shall interpret characters in conformance with the Unicode Standard, Version 3.0, and ISO/IEC 10646-1. Conforming implementations must accept Unicode source files encoded with the UTF-8 encoding form.

A conforming implementation of C# shall not successfully translate source containing a #error preprocessing directive unless it is part of a group skipped by conditional compilation.

A conforming implementation of C# shall produce at least one diagnostic message if the source program violates any rule of syntax, or any negative requirement (defined as a “shall” or “shall not” or “error” or “warning” requirement), unless that requirement is marked with the words “no diagnostic is required”.

A conforming implementation of C# is permitted to provide additional types, values, objects, properties, and methods beyond those described in this International Standard, provided they do not alter the behavior of any strictly conforming program. Conforming implementations are required to diagnose programs that use extensions that are ill formed according to this International Standard. Having done so, however; they can compile and execute such programs. (The ability to have extensions implies that a conforming implementation reserves no identifiers other than those explicitly reserved in this International Standard.)

A conforming implementation of C# shall be accompanied by a document that defines all implementation-defined characteristics, and all extensions.

A conforming implementation of C# shall support the class library documented in §Annex D. This library is included by reference in this International Standard.

Соответственно, какую грамматику будет использовать реализация — совершенно безразлично.

Posted via RSDN NNTP Server 1.9 gamma

Здравствуйте, vdimas, Вы писали:

Ну ты терпелив! Я хотел написать то же самое, но упорства не хватило. Решение-то очевидное, просто на поверхности лежит. Мне совершенно непонятно, почему его не применили при построении "канонической" грамматики C#. Может быть, есть еще какие-то проблемы, о которых мы не знаем?

Здравствуйте, Sinclair, Вы писали:

S>Решение-то очевидное, просто на поверхности лежит. Мне совершенно непонятно, почему его не применили при построении "канонической" грамматики C#. Может быть, есть еще какие-то проблемы, о которых мы не знаем?

ага, забыли Вирта пригласить, или хотя бы Кнута

Здравствуйте, VladD2, Вы писали:

Здравствуйте, prVovik, Вы писали:

VD>>"Уличение" очень даже аргументированное
V>А вот про это можно по подробнее. Про аргументы.

Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Неудастся. Вообще не удастся расположить в правиле. На то и зависимость от контекста.

ГВ>Удастся. Просто придётся сильно расширить набор правил по отношеню к КЗ-грамматике.

Без изменения граматики ничего не выйдет.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Как давным-давно заметил Шахтер, важно уточнять, о какой грамматике идет речь. Как видишь, вы втроем говорили о трех разных грамматиках:

VladD2: о грамматике, приведенной в спецификации;

О граматике из спецификации прходится говорить хотя бы потому, что совместимость именно с ней нужно обеспечить.

И вообще, изначально прозвучало утверждение, что граматика Шарпа КС. О какой вообще граматике могла идти речь в этом утверждении? Мы с АВК резонно заметили, что граматика шарпа не является КС, так как нарушает ее и даже описывает пути устранения двусмысленностей путем введения семантических проверок. Вы тут все не верили и придумывали различные изощрения чтобы как-то это опровергнуть.

ПК>

prVоvik: грамматике, полностью описывающей синтаксис языка (она не может быть КС, т.к. требует предварительного обьявления переменных);

Ну, да. Типа с философской точки зрения все правы.

ПК>

vdimas: о грамматике, эквивалентной первой в плане порождаемого языка, но являющейся контекстно-свободной.

Он не говорил о эквивалентной. Он это подразумевал, но лично мне было очень тяжело догадаться об этом.

ПК>Последнюю грамматику легким движением руки

Автор: vdimas
Дата: 22.11.04

,

1. Это уже другая граматика. В спецификации четко сказано, что identifier — это токен. 2. Такое решение создает проблем больше чем решает. О том, каких можешь прочесь в опем ответе на то сообщение.

ПК> можно получить из описанной в стандарте C#, если, конечно, кроме "контекстно-зависимых" ключевых слов в грамматике из спецификации нет других моментов, действительно, не позволяющих преобразовать ее в КС.

Мля, граматику нельзя преобразовывать. По крайней мере до той степени до которой ее нужно уфигачить чтобы превратить в КС которую можно без проблем распарсить с помощью имеющихся средств. Ну, и в C# 2.0 достатчно и других КЗ-случаев.

ПК> Последнего пока продемонстрировано не было.

Кто-то просто постоянно фильтрует подобные демонстрации. Я уже показывал ту же ситуацию с неоднозначностью в понимании >> и F(G<,A>(2)).

Решение для >> воспринимать его кка два > и потом проверять для случаев >>, что два > не содержат пробелов между собой (чистая семантика). Или (как сделал я) в пограничных местах делать предварительные проверки и принудительно преобразовывать токен >> в пару >.

Нешение для F(G<,A>(2)) описано в пункте "9.2.3 Grammar ambiguities". Где предлагается считать подбные конструкции вызовами методов если за > идет один из следующих символов "( ) ] : ; , . ? == !=".

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

Здравствуйте, vdimas, Вы писали:

V>Я вот чего-то не понял смысла твоих высказываний. Это появилась какая-то новая наука о токенах, которую я благополучно проспал?

Видимо ты ее проспал еще до рождения. Я еще не видел, чтобы языки проектировали на уровне символов (в смысле char). Вот пожалуй Фортран 77 разве что... Да и о нем я только от тебя узнал.

V>Вообще-то, в ходе своих рассуждений я использовал тот принцип, что грамматика относится к наименьшему классу, в терминах которого представима. Т.е. я лишь доказывал факт представимости твоей конструкции в КС, что доказывало целевой постулат.

Целевое утвреждение было: грамматика C# КЗ

Автор: vdimas
Дата: 19.11.04

. Ты же упорно пыташся переисать граматику чтобы доказать, что исхоная КС. Но это уже будет другая граматика!

V>------
V>Но приколы с тобой на этом еще не заканчиваются. Весь комизм ситуации в том, что, даже используя технику лексер-парсер это тоже можно решить. (я утверждал что решить трудно, но не говорил, что невозможно)...Тогда в правилах синтаксического анализатора напишем следующее...

Периписать граматику подобным образом — была одна из идей когда я дела первые варианты парсера. И тут разница с граматикой стандарта была бы уже не столь велика. Но возникли две трудности.
1. Первые граматики писались на Yacc-е (Jay) и у него просто крышу срывало когда я ему пытася подсунуть подбную граматику. LALR(1)-алгоритм обнаружив соотвествие правилу сразу же пытается по нему свернуться. Это приводит к тому, что увидив, например, get парсер или всегда сворачивается по правилу Identifier или по правилу GetAccasor (в зависимости от того какое из правил встречалось первым). В общем, на LALR(1)-парсерах это в принципе невозможно. А, например, Моно как раз написан на Jay-е.

2. Потом мы выбрали CocoR. Это LL(1)-парсер. А граматика C# не LL(1) (надеюсь хот тут споров не будет...). При этом приходится очень часто анализировать значение идентификатора (обходя LL(1)-несоотвествия), и если его сделать правилом вместо токена, то работа усложняется в разы. Плюс возможно замедление разбора.

Ну, и опять же по спецификации C# (о граматике которой и идет речь) identifier — это токен. А твое переписывание изменяет это положение. В итоге как не крути, а приходится использовать КЗГ с локальным разрешением конфликтов.

Здравствуйте, prVovik, Вы писали:


VD>>"Уличение" очень даже аргументированное
V>А вот про это можно по подробнее. Про аргументы.

Re[19]: КС и КЗ грамматики

Автор: VladD2
Дата: 22.11.04

Здравствуйте, vdimas, Вы писали:

Попробуй ради хохмы повставлять этих делемиторов в "сложные правила для выражений".

VladD2,

> ПК>Последнюю грамматику легким движением руки

Автор: vdimas
Дата: 22.11.04

,

> 1. Это уже другая граматика. В спецификации четко сказано, что identifier — это токен.

Ну и что, что другая грамматика? Как это противоречит изначальному вопросу

Автор: vdimas
Дата: 19.11.04

?

почему грамматика C# КЗ?
какие выражения не удается представить в КС — форме?

Как видишь, добавление к синтаксису языка свойств на манер C#, со всем "контекстно-зависимыми" ключевыми словами, на возможность представления его контекстно-свободной грамматикой не влияет.

> 2. Такое решение создает проблем больше чем решает. О том, каких можешь прочесь в опем ответе на то сообщение.

Это уже не относится к тому, можно ли представить синтаксис свойств контекстно-свободной грамматикой. Теория формальных языков, к которой относятся вопросы представимости того или иного языка контекстно-свободной грамматикой, yacc'ами, bizon'ами и прочими CocoR не занимается.

Это уже совсем другой вопрос, о возможностях используемых инструментов. Тем более, что подобные инструменты обычно накладывают на грамматику большие ограничения, чем принадлежность к контекстно-свободным (обычно требуется LL(1) или LALR).

> ПК> можно получить из описанной в стандарте C#, если, конечно, кроме "контекстно-зависимых" ключевых слов в грамматике из спецификации нет других моментов, действительно, не позволяющих преобразовать ее в КС.

> Мля, граматику нельзя преобразовывать.

В теории формальных языков, к которой относится вопрос представимости языка контекстно-свободной грамматикой, такого запрета нет. Напротив, вопрос представимости синтаксиса языка грамматикой того или иного класса как раз и заключается в ее поиске.

При работе со всевозможными генераторами парсеров грамматику преобразовывать не только можно, но и нужно, чтобы привести ее к виду, понимаемому соответствующим инструментом (устранение неоднозначностей, левой рекурсии и т.п.).

Предвосхищая твои возражения относительно стандарта C#, отвечаю, что он преобразовывать грамматику тоже не запрещает, т.к., как уже говорилось, на соответствие стандарту реализации используемая грамматика не влияет.

> ПК> Последнего пока продемонстрировано не было.

> Я уже показывал ту же ситуацию с неоднозначностью в понимании >> и F(G<,A>(2)).
> <...>
> Нешение для F(G<,A>(2)) описано в пункте "9.2.3 Grammar ambiguities". Где предлагается считать подбные конструкции вызовами методов если за > идет один из следующих символов "( ) ] : ; , . ? == !=".

Это снова не влияет на представимость синтаксиса контекстно-свободной грамматикой, т.к. разрешение неоднозначности не зависит от значений идентификаторов, а требует только тривиального просмотра вперед.

Это бы влияло на представимость контекстно-свободной грамматикой, если бы, например, правило разрешения данной неоднозначности зависело от того, является ли идентификатор G именем generic класса, или нет.

А вот, скажем, грамматика C++, вопреки утверждению Андрея:

AVK> грамматика C# КЗ, а С++ КС

как раз контекстно-свободной совершенно точно не является, т.к. там подобная неоднозначность разрешается как раз определением того, обозначает ли идентификатор G шаблон, или нет.