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

Вниз

; not allowed before ELSE   Найти похожие ветки 

 
Dmitriy O.   (2003-12-26 08:09) [0]

А собственно почему незя ставить ";" перед else ?
Чем вызванна такая фишка ?


 
MBo   (2003-12-26 08:13) [1]

Тебе знакомо понятие "оператор"?


 
mfender   (2003-12-26 08:14) [2]

Полагаю, это все виноваты капиталисты, которые придумали вязанку if...then...else;


 
Sergey13   (2003-12-26 08:26) [3]

2Dmitriy O. © (26.12.03 08:09)
Подозреваю, что с помощью этого хитрого финта ты хотел бы увеличить количество ежедневно пишущихся строк кода. Не выйдет. 8-)


 
Style   (2003-12-26 08:29) [4]

Почему нельзя, можно:

case I of

1..5: Caption := "Low";
6..9: Caption := "High";
0, 10..99: Caption := "Out of range";
else
Caption := "";
end;

:)


 
blackman   (2003-12-26 09:24) [5]

Положим и точка с запятой - архаизм :)
Пробелы и концы строк все решают :)
Попробуйте не поставить ; в нужном месте и компилятор скажет, что это ошибка. Если он ошибку нашел, то логично было бы ее и исправить. :)


 
Юрий Зотов   (2003-12-26 09:26) [6]

> Dmitriy O. © (26.12.03 08:09)
> Чем вызванна такая фишка?

Тем, что точка ставится в КОНЦЕ предложения, а не в его СЕРЕДИНЕ (да и то не всегда).


 
Alex Konshin   (2003-12-26 09:56) [7]

>Юрий Зотов © (26.12.03 09:26) [6]
>> Dmitriy O. © (26.12.03 08:09)
>> Чем вызванна такая фишка?

>Тем, что точка ставится в КОНЦЕ предложения, а не в его СЕРЕДИНЕ (да и то не всегда).
А сишники и джавовцы с вами не согласятся. Хотя я согласен, что не ставить точку с запятой внутри statement более логично.

Расмотрим такой пример:

case i of
1: if a>b then DoSomething
else
DoSomethingElse;
end;

Как мы видим, точка с запятой после DoSomething имеет примерно такой же смысл, как и в фразе "казнить, нельзя помиловать". Синтаксически обе конструкции верны, потому компилятор не сможет догадаться как было задумано.

Мое мнение может прозвучать ересью на этом форуме: синтаксис Pascal был проработан плохо.
Вот другой пример: конструкция case в record явно выглядит исскуственно, плохо читается и, вдобавок ко всему имеет другой синтаксис, чем statement case (нет завершающего end).


 
Romkin   (2003-12-26 10:05) [8]

А у сишников предложения короче. И вообще другие. Поэтому :)


 
blackman   (2003-12-26 10:16) [9]

>синтаксис Pascal был проработан плохо.
Согласен, коряво.
>DoSomethingElse;
А здесь ; можно и не ставить D6 схавает :)


 
Dmitriy O.   (2003-12-26 10:20) [10]

Синтаксис плохой. Я вообще не понимаю назначение -> ;
В VB такого нет и все работает нормально.


 
Юрий Зотов   (2003-12-26 10:22) [11]

> Alex Konshin © (26.12.03 09:56) [7]

> потому компилятор не сможет догадаться как было задумано

Вот именно поэтому semicolon внутри statement и не нужен.

> синтаксис Pascal был проработан плохо.

Мне доводилось писать парсеры с Паскаля. Вот когда начинаешь понимать, насколько же велик Вирт. Уверяю Вас, синтаксис классического Паскаля не то что хорош - он просто великолепен. В нем математическая краткость, логичность, строгость и однозначность замечательно сочетаются с необычайной близостью к естественному языку и поистине неограниченными возможностями творить произвольно сложные конструкции из чрезвычайно малого количества чрезвычайно простых кирпичиков. Это красиво.

Конечно, современные Паскалеобразные языки несколько другие - практика берет свое. Даже Turbo Pascal уже не был строго классическим Паскалем, не говоря уже о языке Delphi. Но главные черты сохранились. А главное, я считаю, в том, что синтаксис языка и компилятор не мешают Вам делать все, что Вам только захочется - но при этом очень надежно страхуют от ошибок.

Будет свободное время - распишите БНФ какого-нибудь небольшого подмножества Паскаля. Сразу же убедитесь, насколько красив и точен его синтаксис.


 
Sha   (2003-12-26 10:25) [12]

Alex Konshin © (26.12.03 09:56) [7]

Полностью согласен.

Я всегда ставлю точку с запятой после "begin" и после оператора, предшествующего "end".
А тем, кто говорит, что это неправильно, отвечаю, что точка с запятой стоит после пустого оператора :)


 
Ega23   (2003-12-26 10:29) [13]

А у меня начальник всегда такую конструкцию выдаёт:
if A=True then ....
Я его спрашивал почему, говорит - привычка.


 
Sha   (2003-12-26 10:29) [14]

Юрий Зотов © (26.12.03 10:22) [11]

Согласен со всем, кроме точки с запятой.
Кажется, компилятор с Pascal, написанный на Pascal, короче соответствующих компиляторов для других языков.


 
Alex Konshin   (2003-12-26 10:40) [15]

>> потому компилятор не сможет догадаться как было задумано
>Вот именно поэтому semicolon внутри statement и не нужен.
А я о чем? Я о о том, что он непоследователен.
Знаешь, теорию компиляции я тоже знаю не по-наслышке (плавали, знаем).
Ты когда-нибудь описание синтаксиса Algol-68 читал?
Вот по сравнению с ним синтаксисы и паскаля, и C/C++ выглядят очень бледно и некрасиво. Я также соглашусь, что и его синтаксис тоже не идеал.

Кстати, если будет свободное время, все-таки попробуй как-нибудь расписать БНФ для Паскаля по-настоящему, и ты увидишь, что он не просто далек от идеала, но и не может быть через них выражен строго, если не прибегать к описанию словами. Я как-то на это натолкнулся, когда писал компилятор грамматик. Тот синтаксис, что написан в большинстве книжек - липа. Хотя, по правде сказать, я думаю, что подобные проблемы будут с любым широкоиспользуемым языком программирования.


 
Sha   (2003-12-26 10:45) [16]

> Alex Konshin © (26.12.03 10:40) [15]
> ... если не прибегать к описанию словами...

Очень интересно. Это где? Пример необязательно. Просто суть.


 
Юрий Зотов   (2003-12-26 11:06) [17]

> Alex Konshin © (26.12.03 10:40) [15]

> Я о о том, что он непоследователен.

Дык... а в чем же непоследовательность? Как только мы ставим правилом, что semicolon внутри statement не допускается - так тут же все становится вполне однозначно и вполне логично. Очень даже последователен.

Вариант 1:
case i of
1: if a>b then DoSomething
else
DoSomethingElse
end;

Здесь else является ветвью if в силу вложенности конструкций.

Вариант 2:
case i of
1: if a>b then DoSomething;
else
DoSomethingElse
end;

А здесь else является ветвью case в силу semicolon.

Все совершенно понятно и очень логично.

> Ты когда-нибудь описание синтаксиса Algol-68 читал?

68 - не читал, а вот 60 - читал. И нахожу, что синтаксис Паскаля как раз очень похож на синтаксис Алгола (что, в общем-то, и не удивительно, если вспомнить историю этих языков - оба первоначально строились, как некие, скажем так, метаязыки).

> но и не может быть через них выражен строго, если не
> прибегать к описанию словами.

Алекс, ну ты меня убил просто. Это же известнейшая вещь, называется "семантика", и она имеет место быть во ВСЕХ языках. Есть синтаксис (который можно описать формально), а есть семантика, которая формальному описанию (в виде БНФ или синтаксических диаграмм) не поддается и потому ВСЕГДА описывается словами (например, "длина идентификатора не может превышать N символов, а значащими из них являются первые M символов"). Так что Паскаль здесь абсолютно не виноват, уж тогда, скорее, виновата несовершенность известных методов формального описания языков.

> Тот синтаксис, что написан в большинстве книжек - липа. Хотя,
> по правде сказать, я думаю, что подобные проблемы будут с
> любым широкоиспользуемым языком программирования.

Естественно. Так и должно быть - как раз из-за семантики.


 
ИдиотЪ   (2003-12-26 11:10) [18]

в бейсике ввели end if и тому подобное и порядок, а здесь решили сократить на этом, вот отсюда все беды


 
Darts   (2003-12-26 11:11) [19]

А как насчет синтаксиса Modula-2, Oberon-2? Что скажет народ?


 
Alex Konshin   (2003-12-26 11:14) [20]

>> Alex Konshin © (26.12.03 10:40) [15]
>> ... если не прибегать к описанию словами...

>Очень интересно. Это где? Пример необязательно. Просто суть.
На вскидку сразу вспоминается проблема с неявным приведением типов, например, integer -> float. Описать с помощью БНФ это вроде как можно, только при компиляции грамматики вскрываются неодназначности: без контекста не ясно какого же типа выражение.
С другой стороны, в определенных statement требуется знать тип выражения (хотя бы тот же case). В конце-концов я вводил понимание неявного преобразования типов в сам компилятор грамматики. Кстати, эта же пробелема будет практически у всех современных языков. Возможно, разве что, Ada с ее явными преобразованиями типов это не каснется (может, это и было причиной ввода обязательных явных преобразований?).

Попробую еще повспоминать.

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

Вот это немного не относится к вопросу, но всегда мне приходит на ум как кривость синтаксиса Паскаля: почему case заканчивается на end? Как результат, синтаксис case отличается от синтаксиса if then else, особенно в части else. Нелогично.
Второе: почему в некоторых местах точку с запятой можно ставить, а можно и опускать? Это, кстати, может приводить к трудноуловимым ошибкам, как в том примере, что я привел ранее.


 
SergP   (2003-12-26 11:17) [21]

Кстати вопрос (правда это не про if then else):
Почему компилятору в данном примере пофиг стоит точка с запятой или нет?:
...
private
{ Private declarations }
public
datb:array[1..5] of record
rajon:string[30];
data:array[1..12] of integer
end; // вот эта точка с запятой ему пофиг.....
{ Public declarations }
end;
...


 
ИдиотЪ   (2003-12-26 11:20) [22]

Alex Konshin ©
а ты ставь везде точки с запятыми, кроме else )
а какие еще ошибки ?
ну только разве с кучей вложенных if и else, тут уж язык не причем

ПС
Не вини монитор, коли рука крива


 
Alex Konshin   (2003-12-26 11:23) [23]

Семантика - это смысл программы. А длина идентификатора это все-таки чистый синтаксис. И как раз-таки здесь большой проблемы для отображения в БНФ нет.


 
Sha   (2003-12-26 11:26) [24]

> Alex Konshin © (26.12.03 11:14) [20]

Приведение типов и не должно описываться БНФ.
То, синтаксис case отличается от синтаксиса if then else, мне тоже не нравится, но это не является неоднозачностью.

SergP © (26.12.03 11:17) [21]

Вирт почему-то решил, что begin и end не являются операторами, и значит, перед end и после begin точки с запятой необязательны.


 
Alex Konshin   (2003-12-26 11:30) [25]

> Почему компилятору в данном примере пофиг стоит точка с запятой или нет?
Перед end ее можно не ставить.
Тоже бред - нашли на чем экономить. В итоге нельзя сказать, что "statement должен оканчиваться точкой с запятой". Тогда для того же описания в БНФ приходится придумывать какие-то суррогаты для того, чтобы нормально понимались обе конструкции:

begin
end;

и

begin
;
end;

И зачем?


 
Alex Konshin   (2003-12-26 11:42) [26]


Приведение типов и не должно описываться БНФ.
То, синтаксис case отличается от синтаксиса if then else, мне тоже не нравится, но это не является неоднозачностью

Я бы может и согласился бы с вами, но как тогда быть с конструкциями, где требуются определенные типы? Вы загляните в описание синтаксиса Pascal - там же есть термы вроде integer_expression. Вот я и говорю, те грамматики - липа, их нельзя скомпилировать как есть. То есть, не вводя какие-то контекстные зависимости в компилятор я не могу проверить соответствие входной программы синтаксису языка на этапе синтаксического разбора? Бред, не находите?
Только не надо меня агитировать за советскую власть, я все сам понимаю, я просто указываю на недостатки языка, какие присущи не только ему.

Кстати, с термом case вообще много интересого, например, синтаксис case в record отличается от синтаксиса statement case. Ну это-то нафига?


 
Юрий Зотов   (2003-12-26 11:45) [27]

> Sha © (26.12.03 11:26) [24]

> Вирт почему-то решил, что begin и end не являются
> операторами

И очень логично решил. Оператор - это ИСПОЛНИМАЯ часть программы. А вegin и end - это НЕисполнимая часть. Просто информация для компилятора. Если говорить строго, то это часть СОСТАВНОГО оператора, или операторные скобки, как их еще называют.

<простой оператор> ::= <оператор присваивания>
<оператор if>
<оператор case>
<оператор while>
и т.д.

<список операторов> ::= <оператор>
<оператор> ; <список операторов>

<составной оператор> ::= begin <список операторов> end

<оператор> ::= <простой оператор>
<составной оператор>


Раскрутите это фрагмент систаксиса КЛАССИЧЕСКОГО Паскаля - и Вы сразу увидите ДЕЙСТВИТЕЛЬНЫЙ (а не кажущийся) смысл begin-end и semicolon. А также - где ставится и где НЕ ставится semicolon (кстати, c точки зрения СИНТАКСИСА, semicolon после begin или перед end - это однозначно пустой оператор и ничего полее).


 
Anatoly Podgoretsky   (2003-12-26 11:46) [28]

Alex Konshin © (26.12.03 11:30) [25]
А если ты вспомнишь старые реализации Паскаля, то там нельзя было ставить точку с запятой перед end. Это более позднее послабление.


 
Sha   (2003-12-26 11:51) [29]

Alex Konshin © (26.12.03 11:42) [26]

Мне кажется, что недостатков в грамматике всего 2:
- плохой case, ко всему сказанному выше я бы добавил обязательность begin/end в каждом условии;
- особый статус begin/end в группе операторов и соответствующие чудачества с точкой с запятой.

А термы вроде integer_expression присутствуют в описании любого языка. С этим надо смириться, как с дождем за окном. Это невозможно улучшить ни Вирту, ни вам.


 
Юрий Зотов   (2003-12-26 11:52) [30]

Сорри, неточность допустил. Надо так:

<список операторов> ::= <простой оператор>
<простой оператор> ; <список операторов>


 
Sha   (2003-12-26 11:57) [31]

Юрий Зотов © (26.12.03 11:45) [27]

Знаю я все про операторные скобки и про пустые операторы.
Посмотрите синтаксис Algol - там те же операторные скобки, но с точкой с запятой. Они также прекрасно раскручиваются. Зато в Алголе, как верно заметил Alex Konshin, любой оператор, включая операторные скобки, оканчивается точкой с запятой. Такие аксиомы легче понимаются и легче запоминаются. Плюс снимаются многие неоднозначности.


 
Юрий Зотов   (2003-12-26 12:12) [32]

> Sha © (26.12.03 11:57) [31]

> любой оператор, включая операторные скобки

В том-то все и дело, что в Паскале операторные скобки ОПЕРАТОРАМИ не являются (см. синтаксис выше). Нет такого оператора - begin. И оператора end - тоже нет.

И это очень правильно, потому что оператор - это то, что можно исполнить. Исполнить же можно даже пустой оператор (NOP), а вот begin и end исполнить нельзя. Это всего лишь информация для компилятора, чистейший элемент СИНТАКСИСА. А не кода.

> оканчивается точкой с запятой

Зачем бездумно расставлять точки с запятой, где ни попадя? Тем более, зачем вводить это в СИНТАКСИС? Паскаль задумывался, как язык ОБУЧАЮЩИЙ и одной из ГЛАВНЫХ его задач было привитие хорошего СТИЛЯ. Что и было сделано (я бы сказал - с блеском).

> Такие аксиомы легче понимаются и легче запоминаются.

В таком случае легче всего понимается и запоминается старый Фортран: 1 строка - один оператор. И никаких проблем, и никаких точек с запятой. Но ведь почему-то этого ушли? Ушли. И вполне понятно, почему.

> Плюс снимаются многие неоднозначности.

Выше я привел элемент синтаксиса Паскаля. Где Вы видите в нем неоднозначности?


 
Sha   (2003-12-26 12:28) [33]

> Юрий Зотов © (26.12.03 12:12) [32]

> Паскаль задумывался, как язык ОБУЧАЮЩИЙ и одной из ГЛАВНЫХ его
> задач было привитие хорошего СТИЛЯ.

А Алгол - не обучающий? Или программы на Алголе прививают плохой стиль? Сам я обучался программированию именно на Алголе. И помню, что вопросов по поводу точки с запятой тогда ни у кого не возникало. А при обучении программированию на Паскале этот вопрос возникает ПОСТОЯННО у КАЖДОГО обучающегося. Это плохо, это отвлекает от ГЛАВНОГО - ПРИВИТЯ ХОРОШЕГО СТИЛЯ.
Языки пишутся для людей, и то, что хорошо и логично для машины не всегда хорошо и логично дя человека. Вместо того, чтобы потратить время с большей пользой, КАЖДЫЙ преподаватель ВЫНУЖДЕН втолковывать КАЖДОМУ обучаемому (с его начальными и неокреншими знаниями) что про красоту и логичность БНФ Паскаля. Язык должен понравиться сразу, тогда обучение идет быстрее. А такие причуды Вирта этому только мешают.

> Где Вы видите в нем неоднозначности?

Неоднозначности в интерпретации БНФ, как я уже говорил, нет. Есть неоднозначность в интерпретации кода, написанного другим программистом, если подобные конструкции языка сам никогда не используешь. На одну из них указал Alex Konshin © (26.12.03 09:56) [7]


 
Иван Шихалев   (2003-12-26 12:34) [34]

В Паскале операторы вообще не оканчиваются точкой с запятой, они ей разделяются.


 
PVOzerski   (2003-12-26 12:36) [35]

IMHO, ничего плохого в этой самой точке с запятой нет. Пример с case ... if .. else - блестящий! Меня лично в Паскале коробит только одна вещь: часть предопределенных процедур сделана не в соответствии с синтаксисом самого же Паскаля. А ну-ка, напишите функцию, которую можно было вызывать с произвольным числом параметров нескольких типов, как write/writeln/read/readln! Не принимаю предложения ни об array of const (поскольку придется квадратные скобки привлекать), ни о default (поскольку число параметров уже не совсем произвольно), ни об overload (по той же причине) :^) 2-я задача: аналогично тем же write/writeln (а у Borland - еще и str), сделать поддержку "форматного двоеточия" с тем же синтаксисом.


 
Sha   (2003-12-26 12:36) [36]

Иван Шихалев © (26.12.03 12:34) [34]

Ну да, а предложения разделяются точками :)


 
Igorek   (2003-12-26 12:40) [37]

пятница - holywars


 
MOA   (2003-12-26 12:46) [38]

Почему же нельзя, запросто. Например (специально без отступов):

if i > 2 then
if j < 3 then
k:=i+j; // < пожалуйста, ; пред else в полный рост
else
k:=i-j;


 
Думкин   (2003-12-26 12:49) [39]

> [37] Igorek © (26.12.03 12:40)

Угу. Предпоследнее HolyWar уходящего года.


 
Sha   (2003-12-26 12:50) [40]

MOA © (26.12.03 12:46) [38]
Не пойдет компияция.



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

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

Наверх




Память: 0.58 MB
Время: 0.011 c
1-63226
KSergey
2004-01-09 13:31
2004.01.20
Назначение обработчиков событий объекту WordApplication


1-63196
Can_kill
2004-01-10 03:11
2004.01.20
Прерывание


4-63448
OlegV
2003-11-13 15:37
2004.01.20
Удаление выполняющегося EXE файла


4-63452
lex
2003-09-11 11:10
2004.01.20
Блокировать отключение монитора


1-63111
Rustamus
2004-01-08 12:20
2004.01.20
Движение окна





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
Английский Французский Немецкий Итальянский Португальский Русский Испанский