Oberon space
General Category => Общий раздел => Тема начата: Rifat от Апрель 22, 2011, 02:26:38 pm
-
Сейчас в языке Oberon-07 последнее поле в записи не должно заканчиваться символом ";".
Например, RECORD a: INTEGER; b: INTEGER END - можно, а RECORD a: INTEGER; b: INTEGER; END - нельзя.
Это следует из синтаксиса языка:
RecordType = "RECORD" ["(" BaseType ")"] [FieldListSequence] "END".
BaseType = qualident.
FieldListSequence = FieldList {";" FieldList}.
FieldList = IdentList ":" type.
IdentList = identdef {"," identdef}.
Мне кажется, что это не всегда удобно, так как если, например, в структуре 10 полей, то последовательно добавляя поля, нужно всегда иметь в виду, что последнее поле не должно заканчиваться символом ";". Если случайно добавить этот символ, то будет ошибка компиляции. А если изначально было все правильно, а затем пришлось добавить еще несколько полей, то можно забыть поставить символ ";" после десятого поля.
В Компонентном Паскале точка с запятой после последнего поля не вызывает ошибку, это следует из синтаксиса.
Type = Qualident
| ARRAY [ConstExpr {"," ConstExpr}] OF Type
| [ABSTRACT | EXTENSIBLE | LIMITED]
RECORD ["("Qualident")"] FieldList {";" FieldList} END
| POINTER TO Type
| PROCEDURE [FormalPars].
FieldList = [IdentList ":" Type].
Кто как думает, почему в Oberon-07 нельзя ставить точку запятой после последнего поля, есть ли здесь какое-то скрытое рациональное зерно?
Нужно ли изменять синтаксис языка Oberon-07M чтобы можно была ставить точку с запятой после последнего поля?
-
Кто как думает, почему в Oberon-07 нельзя ставить точку запятой после последнего поля, есть ли здесь какое-то скрытое рациональное зерно?
Да просто чтобы уменьшить вариативность. Меньше вариантов формы - меньше заморочек. Больше повода поговорить о важных вещах :)
-
Сейчас подумал, что может быть для однопроходного компилятора, который сразу код генерирует, немного проще если после последнего поля нет точки с запятой.
-
О компиляторах думают, а о людЯх - нет :)
-
Сейчас в языке Oberon-07 последнее поле в записи не должно заканчиваться символом ";".
...
Мне кажется, что это не всегда удобно, так как если, например, в структуре 10 полей, то последовательно добавляя поля, нужно всегда иметь в виду, что последнее поле не должно заканчиваться символом ";". Если случайно добавить этот символ, то будет ошибка компиляции. А если изначально было все правильно, а затем пришлось добавить еще несколько полей, то можно забыть поставить символ ";" после десятого поля.
В Хаскелле последнее поле записи тоже не должно иметь разделителя, синтаксис:
record = identifier "{" fielddecl [{ , fielddecl }] "}"
В принципе, можно столкнуться с таким же неудобством, однако в распространённых руководствах по стилю программирования на Хаскелле предлагается такое правило:
data Person = Person
{ firstName :: String -- ^ First name
, lastName :: String -- ^ Last name
, age :: Int -- ^ Age
} deriving (Eq, Show)
С непривычки может показаться не очень, но если систематически следовать таким правилам, то код выглядит аккуратно и всё удобно.
http://snapframework.com/docs/style-guide
Пример для Оберона:
TYPE Person = RECORD
firstName : String (** First name *)
; lastName : String (** Last name *)
; age : Int (** Age *)
END;
-
Вот давно хотел спросить - зачем там крышка (^)? -- ^ First name
-
Не замечал раньше, что в Компонентном Паскале ";" можно ставить подряд сколько угодно.
-
Вот давно хотел спросить - зачем там крышка (^)? -- ^ First name
-- | и -- ^ -- это указание для таких программ, как Haddoc, которые по исходнику автоматически строят документацию по программе, что эти комментарии нужно включить в соответствующих местах в сгенерированной документации.
Теоретически, если кто-то удосужится сделать нормальное IDE для Хаскелла, там эти комментарии будут отображаться во всплывающей подскащке при наведении на курсора мышки на идентификатор...
-
Не замечал раньше, что в Компонентном Паскале ";" можно ставить подряд сколько угодно.
Если в языке есть понятие "пустой оператор", то можно. А такое понятие обычно вводится. Например, чтобы можно было писать цикл с пустым телом.
-
Если в языке есть понятие "пустой оператор", то можно. А такое понятие обычно вводится. Например, чтобы можно было писать цикл с пустым телом.
Кто о чем, а оберонщики о циклах ;)
P.S. В питоне есть специальное ключевое слово для этого - "pass". При этом к точкам с запятой и лишним запятым никто тоже не придирается... Человеческий подход без синтаксического догматизма ;)
-
Сведение к минимуму возможных внешних форм выражения способствует концентрации внимания на существенном. Очевидный факт (известный и художникам, и дизайнерам, и др.). Что тут ещё мусолить. Радоваться надо, если что-то стало можно записать вместо 2-х идентичных ("копьеломательных") способов одним.
Посмотрите, сколько геморроя при попадании на чужой комп от наличия в системе нескольких вариантов смены раскладки. Надо было разработчикам ОС с самого начала подумать хорошенько и понять, что раз эти варианты равноценны, "яйцеконечны", то нужно было "заварить" намертво только один, чтобы он был всегда и везде.
-
По-моему, немного нелогично, что точку с запятой нельзя ставить после последнего поля при описании записей, но можно ставить, например, после последнего опрератора внутри цикла.
Как мне кажется надо сделать, чтобы и после последнего поля в записи можно было ставить точку с запятой или же наоборот запретить точку с запятой после последнего оператора внутри блоков WHILE, IF, FOR ...
-
Сведение к минимуму возможных внешних форм выражения способствует концентрации внимания на существенном.
Здесь речь не о формах, а о технологичности. То, о чем пишет Грабин ;) Запрещать лишние точки с запятой в угоду чистоте формальной записи синтаксиса - нетехнологично. Потому что создает ненужные проблемы на производстве (при написании кода в текстовом редакторе).
-
Для любителей принципа Калашникова: автомат должен работать в дождь, снег и грязь. А в данном случае поставил лишнюю (с т.з. компилятора!) точку с запятой, и автомат отказал.
-
Во-первых, аналогия какая-то очень дальняя. Разрешать грязь в исходных текстах? :) Это грязь не от условий применения (от обстоятельств задач), а грязь на производстве :)
Во-вторых, это будет прыжок далеко усиливающий обсуждаемый вопрос, но по Вашей мысли.
Что получается из подхода "работать в грязь, и в дождь" применительно ко входным исходным текстам, хорошо известно на примере HTML. Представьте на секунду, что было бы, если бы изначально HTML был бы определён так же строго, как XHTML. Написание анализатора и рендеринга было бы темой хорошей курсовой-диплома. Не то, что сейчас - героический труд по борьбе с полной... ж... которая идёт на вход и которую движок должен быть готов обработать (вместо того, чтобы послать написавшего это).
-
Если у оператора REPEAT ввести обязательный END, то возможно символ ";" можно было бы вообще убрать из языка (?). Мне кажется этот символ в чём-то является анахронизмом, также как и обязательность скобок у функций без параметров. Или нет?
-
Во-первых, аналогия какая-то очень дальняя. Разрешать грязь в исходных текстах? :) Это грязь не от условий применения (от обстоятельств задач), а грязь на производстве :)
Во-вторых, это будет прыжок далеко усиливающий обсуждаемый вопрос, но по Вашей мысли.
Что получается из подхода "работать в грязь, и в дождь" применительно ко входным исходным текстам, хорошо известно на примере HTML. Представьте на секунду, что было бы, если бы изначально HTML был бы определён так же строго, как XHTML. Написание анализатора и рендеринга было бы темой хорошей курсовой-диплома. Не то, что сейчас - героический труд по борьбе с полной... ж... которая идёт на вход и которую движок должен быть готов обработать (вместо того, чтобы послать написавшего это).
Про грязь на производстве вопрос неоднозначный. Если грязь допускается без снижения качества готового продукта, то это безусловный плюс в технологии - она будет более дешевой.
А в данном случае я просто не вижу грязи. С точки зрения человека, это точно не грязь. Не вижу также, в чем грязь с точки зрения определения языка в КП.
-
Технологичность, кроме всего прочего, это еще и число операций, телодвижений, которые необходимо соврешить для достижения желаемого результата. Чем нужно меньше операций, тем технологичность выше. Так вот, в данном случае мы имеем неоправданные дополнительные операции правки исходного текста для добавления/удаления поля записи.
-
Еще в Oberon-07 нельзя ставить точку с запятой после оператора RETURN и его значения. Кто как считает, нужно ли здесь разрешать точку с запятой или я просто неправильно код форматирую? Сейчас я пишу:
RETURN m
END Proc;
А надо допустим:
RETURN m END Proc;
И тогда понятно, что точка запятая здесь не требуется.
-
RETURN в Oberon-07 не является statement'ом, он является составляющей составной конструкции. То есть по идее, неплохо бы его и отступами как-то выделять, то есть соглашения о форатировании кода тут должны быть иными нежели в КП например.
Но таки код
PROCEDURE Foo : INTEGER;
VAR
j : INTEGER;
BEGIN
INC(j);
RETURN j END Foo;
Все еще смотрится диковинно. Хотя-я… У этого есть свои плюсы — мы явно видим места где у нас функция завершает выполнение.
-
C другой стороны сам Вирт придерживается стиля обычного, будто RETURN это все еще не часть синтаксиса процедуры-функции, а обычный statement (взято из language report'a):
PROCEDURE log2(x: INTEGER): INTEGER;
VAR y: INTEGER; (*assume x>0*)
BEGIN y := 0;
WHILE x > 1 DO x := x DIV 2; INC(y) END ;
RETURN y
END log
-
А в данном случае я просто не вижу грязи. С точки зрения человека, это точно не грязь. Не вижу также, в чем грязь с точки зрения определения языка в КП.
Да сама по себе точка с запятой - не грязь, но вот если можно ставить, а можно нет, то уже как бы и грязь..
Надо кому-то что-то объяснять - а почему в текущем коллективе или проекте или где ещё принято не ставить (или ставить).
Вместо того, чтобы иметь "вмороженный" в компилятор единственный вариант.
-
Ставить всегда вне зависимости от позиции поля.
-
Да сама по себе точка с запятой - не грязь, но вот если можно ставить, а можно нет, то уже как бы и грязь..
Надо кому-то что-то объяснять - а почему в текущем коллективе или проекте или где ещё принято не ставить (или ставить).
Вместо того, чтобы иметь "вмороженный" в компилятор единственный вариант.
А Вам и Вашим сотрудникам это реально мешает в работе на КП/ББ?
И, кстати, почему так и не распространился какой-то единый coding style guide для оберонов? Каждый пишет как попало...
-
Дас, разброд и шатания примерно как в плюсах.
Видимо потому, что нет общеупотребимых библиотек, стиль которых задавал бы стиль всего остального.
-
Если у оператора REPEAT ввести обязательный END, то возможно символ ";" можно было бы вообще убрать из языка (?). Мне кажется этот символ в чём-то является анахронизмом, также как и обязательность скобок у функций без параметров. Или нет?
Конечно убрать! В питоне его нет ;) По поводу скобок - однозначно нет. Скобки снимают непоределенность между вызовом и взятием ссылки. Единообразность записи. Кроме того, не хочу, чтобы простое выражение "a + b" могло быть на самом деле вызовом двух функций (как в плюсах ;).
-
Да сама по себе точка с запятой - не грязь, но вот если можно ставить, а можно нет, то уже как бы и грязь..
Надо кому-то что-то объяснять - а почему в текущем коллективе или проекте или где ещё принято не ставить (или ставить).
Вместо того, чтобы иметь "вмороженный" в компилятор единственный вариант.
А Вам и Вашим сотрудникам это реально мешает в работе на КП/ББ?
И, кстати, почему так и не распространился какой-то единый coding style guide для оберонов? Каждый пишет как попало...
Ну, кое-какие указания по стилю имеются в документе Oberon for LPC2000 Microcontrollers (http://www.astrobe.com/Oberon.LPC2000.pdf), в разделе 10 Programming Conventions and Guidelines. Потом, есть ещё "бьютифаеры", которые автоматически задают стиль.
-
Как вариант в языке можно все оставить как есть, а проверку таких часто встречаемых ошибок как точка с запятой после последнего поля в записи или после RETURN возложить на IDE, чтобы IDE бил по рукам (подсвечивал красным), если встретилась такая ситуация, тогда она будет исправлена еще до момента компиляции.
-
Мне кажется этот символ в чём-то является анахронизмом, также как и обязательность скобок у функций без параметров. Или нет?
По поводу скобок - однозначно нет.
Да, наверное Вы правы.
-
Как вариант в языке можно все оставить как есть, а проверку таких часто встречаемых ошибок как точка с запятой после последнего поля в записи или после RETURN возложить на IDE, чтобы IDE бил по рукам (подсвечивал красным), если встретилась такая ситуация, тогда она будет исправлена еще до момента компиляции.
Для того чтобы возложить что-то на IDE оную IDE нужно иметь :-) Хорошая IDE по сути, является надмножеством компилятора, то есть она понимает синтаксис и семантику кода. То есть весь компилятор кроме кодогенерации разве что. Поэтому IDE будет либо повторять 80 процентов компилятора, либо компилятор должен уметь предоставлять нужную информацию IDE. А про это я уже говорил когда предлагал воткнуть в компилятор возможность вывода AST'a. Это часть того, что от компилятора IDE может потребоваться.
-
Для того чтобы возложить что-то на IDE оную IDE нужно иметь :-)
Я все-таки дал курсовику задание сделать IDE для XDS - если дело пойдет то впаяем и 07(но необходимо время для разгона.. 3 курс , хм, толком то и программировать не умеет....).
-
Для того чтобы возложить что-то на IDE оную IDE нужно иметь :-)
Я все-таки дал курсовику задание сделать IDE для XDS - если дело пойдет то впаяем и 07(но необходимо время для разгона.. 3 курс , хм, толком то и программировать не умеет....).
О! Интересно! А какова свобода выбора у студента на базе чего и как это писать? Скажем он может взять какой-нибудь netbeans или eclipse, или notepad++ и на базе этого уже что-то сваять?
Ну и интересны ограничения/предпочтения по языкам разработки и используемым библиотекам.
PS. А xds ведь и под линукс есть :-) Таким образом IDE должна и там работать.
-
О! Интересно! А какова свобода выбора у студента на базе чего и как это писать? Скажем он может взять какой-нибудь netbeans или eclipse, или notepad++ и на базе этого уже что-то сваять?
Ну и интересны ограничения/предпочтения по языкам разработки и используемым библиотекам.
PS. А xds ведь и под линукс есть :-) Таким образом IDE должна и там работать.
Свобода? у третьекурсника не умеющего толком программировать (и тем более проектировать МАСШТАБНЫЕ приложения)? ;) Я пока еще не впал в полный маразм... :D
PS. А xds ведь и под линукс есть :-) Таким образом IDE должна и там работать.
Как говорит один мой знакомый - "есть и на заднице шерсть - но из этого не следует, что она там должна быть..."
-
Хорошо, а какая у него несвобода выбора? ::)
На каком языке с использованием каких библиотек сказано сделать?
-
Хорошо, а какая у него несвобода выбора? ::)
На каком языке с использованием каких библиотек сказано сделать?
Экий вы любопытный... но вот вам .. скрин преальфы ;)
http://dl.dropbox.com/u/22395934/Voyger/screen.png (http://dl.dropbox.com/u/22395934/Voyger/screen.png)
-
Ага. Похоже что Pascal ABC.NET.
-
На .NET похоже (лента выдает).
-
На .NET похоже (лента выдает).
Что только лента не выдает (а почему не офис2010 или 8 винда....?) :D :D :D :D
-
Ну, собственно выбор не большой: либо VS (любой из языков, от С++ до VB.NET), либо Delphi (либо иное борландовское современное поделие, точнее не борланды, а эти, как их, эмбаркокодеро что-ли), либо Pascal ABS.NET.
-
Ну, собственно выбор не большой: либо VS (любой из языков, от С++ до VB.NET), либо Delphi (либо иное борландовское современное поделие, точнее не борланды, а эти, как их, эмбаркокодеро что-ли), либо Pascal ABS.NET.
Да , совершенно верно... Если вдуматься , то выбор небольшой (если речь идет о БЫСТРОМ создании КАЧЕСТВЕННЫХ EUA)... что бы не говорило нац. прог. меньшинство :)
ЗЫ Я бы только PABC из этого списка убрал... :D
-
Грустно, что труд, как всегда, окажется не расширяемым.
Элементарную примочку написать на самом Обероне - хрен.
Говорю без недоброжелательства, просто, объективно невесело, когда в тысячный раз воспроизводится то же самое, что кто-то делал уже в других приложениях. Просто потому, что некоторые корпорации не потрудились ввести какую-то расширяемую документную абстракцию уже на уровне ОС или IDE.
-
Я не помню где и когда в последний раз видел не расширяемую IDE. Но даже если она не расширяема совсем, что мешает взять исходник и кому надо поправить/дописать что надо?
-
Кстати, справедливости ради, в том же ББ элементарную примочку на Обероне тоже не написать, по крайней мере без плясок с бубном. Можно написать только на КП.
-
Для того чтобы возложить что-то на IDE оную IDE нужно иметь :-)
Я все-таки дал курсовику задание сделать IDE для XDS - если дело пойдет то впаяем и 07(но необходимо время для разгона.. 3 курс , хм, толком то и программировать не умеет....).
В рамках этого задания может озадачите студента сделать биндинг к Qt и пусть делает только на связке Qt/Oberon?
-
Для того чтобы возложить что-то на IDE оную IDE нужно иметь :-)
Я все-таки дал курсовику задание сделать IDE для XDS - если дело пойдет то впаяем и 07(но необходимо время для разгона.. 3 курс , хм, толком то и программировать не умеет....).
В рамках этого задания может озадачите студента сделать биндинг к Qt и пусть делает только на связке Qt/Oberon?
Озадачить я его могу и закатыванием солнца в ручную, это даже не смешно..
-
Я не пытался рассмешить.
Qt позволяет сделать качественный интерфейс, кроссплатформенно. Через библиотеку smoke можно сделать генератор для Oberon (как сделано, например, в Ruby и Perl), а можно допилить QtPas (у меня возникли проблемы с передачей строк). И пользоваться. Могу немного помочь, если кто возмется. Сам сейчас не могу, к сожалению.
-
Мне кажется, что не стоит смешивать эти два задания, уж слишком они различны.