Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 2004.12.26;
Скачать: [xml.tar.bz2];

Вниз

Интерестная штука в Паскале.   Найти похожие ветки 

 
SergP ©   (2004-12-03 23:04) [0]


if <условие1> then
  if <условие2> then <оператор1>
                else <оператор2>;


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

1)if <условие1> then
  begin
  if <условие2> then <оператор1>
                else <оператор2>;
  end;


2)if <условие1> then
  begin
  if <условие2> then <оператор1>
  end
                else <оператор2>;


Просто интерестно как такую или подобную конструкцию понимает компилятор?
Т.е.именно с этим вариантом - проверить нетрудно. Но если попадется что-нить другое с подобными кажущимися "неоднозначностями"?
Может есть для таких случаев какие-нить правила?


 
Игорь Шевченко ©   (2004-12-03 23:10) [1]


> как такую или подобную конструкцию понимает компилятор?


Как первый вариант. else относится к последнему then


 
palva ©   (2004-12-03 23:11) [2]

... к последнему then, не имеющему своего else.


 
iZEN ©   (2004-12-03 23:54) [3]

Классическая проблема разрешения конфликта ветвления на уровне компилятора.

Ещё раньше разрешена в ALGOL60, а потом и в FORTRAN77/90, Modula-2 и ADA. Pascal в этом плане от них не так далеко ушёл.


 
DiamondShark ©   (2004-12-04 09:38) [4]


> Может есть для таких случаев какие-нить правила?

Есть.
Из правил грамматики выбирать самое длинное.


 
Igorek ©   (2004-12-04 11:06) [5]

> DiamondShark ©   (04.12.04 09:38) [4]
> > Может есть для таких случаев какие-нить правила?
> Есть.
> Из правил грамматики выбирать самое длинное.

Это правило для компилятора или для кодера?
Если для компилятора, то имхо ты не прав. Компилятор не может выбирать правила просто по длине а не по синтаксису. А если код это позволяет, то это неоднозначность и ошибка грамматики. Впрочем с неоднозначностями он имеет дело, но не с синтаксическими - напр. неявные приведения типов.
Также бывают неоднозначности при разборе данной лексемы в данный момент. Но для этого есть упреждающий анализ - напр. на одну лексему вперед.

Если для кодера, то смотрим Help->Object Pascal grammar:
IfStmt -> IF Expression THEN Statement [ELSE Statement]

Statement -> [LabelId ":"] [SimpleStatement | StructStmt]

StructStmt -> CompoundStmt
          -> ConditionalStmt
          -> LoopStmt
          -> WithStmt

ConditionalStmt -> IfStmt
               -> CaseStmt


Я к тому, что эти правила довольно сложны, что-бы держать их в памяти и при кодировании применять. Кроме того выбор не просто делается между несколькими правилами - в данном случае выбор глубже (надо оценить уже цепочки правил).

А для данного случая, тут тот же нюанс, про который я уже писал "без begin-end в теле процедур можно обойтись". То есть правила
CompoundStmt -> BEGIN StmtList END
StmtList -> Statement/";"...
можно было бы изменить.
Но с другой стороны Паскаль задумывался как язык и для обучения, а потому ясность кода заложена во многом в грамматике.

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


 
olookin ©   (2004-12-05 02:32) [6]

[2] palva ©   (03.12.04 23:11)

Т.е.?


 
Maxim_S~~   (2004-12-06 03:31) [7]

if <условие1> then
 begin
 if <условие2> then <оператор1>
 end
              else <оператор2>;

else конечно же к первому then относится, это очевидно,
какие тут могут быть разговоры?


 
SergP ©   (2004-12-06 06:37) [8]


>  [7] Maxim_S~~   (06.12.04 03:31)


Вы читать умеете?


 
имя   (2004-12-06 06:50) [9]

Удалено модератором


 
SergP ©   (2004-12-06 07:15) [10]


>  [9] Maxim_S~~   (06.12.04 06:50)


С тобой все ясно...


 
Maxim_S~~   (2004-12-06 18:04) [11]

Удалено модератором


 
DiamondShark ©   (2004-12-06 19:01) [12]


> Igorek ©   (04.12.04 11:06) [5]

Нету никаких неоднозначностей.

Берём продукцию

IfStmt -> IF Expression THEN Statement [ELSE Statement]

идём последовательно по коду

if Exp1 then if Exp2 then Stmt2 else Stmt2

видим, что внутренний IF будет полностью разобран при сопоставлении с нетерминалом Statement.

Парсер не помнит окружения, ему по-барабану в каком контексте разворачивается продукция, его задача развернуть её как можно полнее.

Где тут неоднозначности мерещатся?..


 
Igorek ©   (2004-12-07 23:58) [13]


> Где тут неоднозначности мерещатся?..

Кому?



Страницы: 1 вся ветка

Форум: "Потрепаться";
Текущий архив: 2004.12.26;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.48 MB
Время: 0.035 c
4-1100252261
Cosinus
2004-11-12 12:37
2004.12.26
Как получить Handle окна, находящегося под курсором?


1-1103014668
korvin
2004-12-14 11:57
2004.12.26
Вроде число не 13-е, а с датой глюки???


14-1101983506
Ega23
2004-12-02 13:31
2004.12.26
Сахарный диабет


14-1102448705
Hypercube
2004-12-07 22:45
2004.12.26
Печедача "Теория невероятностей"


4-1100528405
Maxuz
2004-11-15 17:20
2004.12.26
Запуск внешнего приложения через CreateProcess





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский