Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.12.26;
Скачать: CL | DM;

Вниз

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

 
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;
Скачать: CL | DM;

Наверх




Память: 0.5 MB
Время: 0.025 c
1-1103043162
denis24
2004-12-14 19:52
2004.12.26
form.oncreate


1-1102484762
ORMADA
2004-12-08 08:46
2004.12.26
Icon на WinApi


6-1097731224
Дмитрий Ботвин
2004-10-14 09:20
2004.12.26
FTP-клиент


1-1102483981
antonn
2004-12-08 08:33
2004.12.26
Форма поверх всех других окон


1-1102800010
Geo
2004-12-12 00:20
2004.12.26
проблема с RichEdit