Здравствуйте, Сергей Губанов, Вы писали:

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

VD>> Нда. Т.е. процедура возвращающая значение?

СГ>Процедура возвращающая значение называется процедурой-функцией:
СГ>

СГ>PROCEDURE f(x: REAL): REAL;
СГ>

СГ>Специальное ключевое слово function используемое для процедур-функций было в старом Паскале 70-го года, в Оберонах обычные процедуры и процедуры-функции обозначаются одним и тем же ключевым словом PROCEDURE.

Очень попахивает войной Вирта за := вместо =
Такое ощущение, что делать человеку нечего и находит проблемы на ровном месте (хотя в присваивании своя логика своя есть некоторая...)

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

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

K>>Мне например больше подходит:

K>>[ccode]
K>>double public static inline
K>> procedure()
K>>{
K>> // понеслась
K>>}

VD>Нда. Т.е. процедура возвращающая значение?
procedure — это не ключевое слово а идентификатор. Имя метода тобишь.

З.Ы. Мог бы и догадатся. Или уже слабо?

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

VD>Парсеры делаются сложными не ради самоцели. Они делаются сложными, чтобы упростить восприятие кода человеком. Другими словами делается язык удобный для человека, а уже под него делается парсер. То что сложно для парсера зачастую оказывается простым для человека, и наоборот.
Давно замечено: то, что сложно парсить, как правило трудно и читать (обратное неверно).

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

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

VD>>Парсеры делаются сложными не ради самоцели. Они делаются сложными, чтобы упростить восприятие кода человеком. Другими словами делается язык удобный для человека, а уже под него делается парсер. То что сложно для парсера зачастую оказывается простым для человека, и наоборот.
Т>Давно замечено: то, что сложно парсить, как правило трудно и читать (обратное неверно).
Странное наблюдение. Мне вот как раз показалось, что человек матчит паттерны по очень хитрому алгоритму. Поэтому совершенно очевидные для него вещи могут забодать любой парсер. Ну вот к примеру: русский человек мгновенно и правильно отпарсит мои ФИО в любом общепринятом варианте порядка: ФО, ОФ, ФИО, ИОФ, ИО. А теперь попробуй запрограммировать парсер, который бы сделал то же самое? (Для ФИО типа У Сунь Ю позволим ему ошибаться, как и человеку).

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

S>Здравствуйте, Трурль, Вы писали:

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

VD>>>Парсеры делаются сложными не ради самоцели. Они делаются сложными, чтобы упростить восприятие кода человеком. Другими словами делается язык удобный для человека, а уже под него делается парсер. То что сложно для парсера зачастую оказывается простым для человека, и наоборот.
Т>>Давно замечено: то, что сложно парсить, как правило трудно и читать (обратное неверно).
S>Странное наблюдение. Мне вот как раз показалось, что человек матчит паттерны по очень хитрому алгоритму. Поэтому совершенно очевидные для него вещи могут забодать любой парсер. Ну вот к примеру: русский человек мгновенно и правильно отпарсит мои ФИО в любом общепринятом варианте порядка: ФО, ОФ, ФИО, ИОФ, ИО. А теперь попробуй запрограммировать парсер, который бы сделал то же самое? (Для ФИО типа У Сунь Ю позволим ему ошибаться, как и человеку).

А вот это, думается мне, как раз и совсем несложно. Первым распознаем имя — по готовому набору, затем — отчество: корень, состоящий из известного имени + одно из окончаний (-вич, -вна, ...), то, что останется — фамилия. Конечно, это очень упрощенная схема, для реальной задачи ее еще надо настраивать (учет ударений и проч.), но она вполне работоспособна. А варианты типа, ИванОвич Иван ИвАнович — здесь и человек не сможет правильно понять, если ударения не указать.

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

K_O>А вот это, думается мне, как раз и совсем несложно.
Не, на пальцах практически все алгоритмы выглядят несложными... Вопрос только в том, что:
K_O>Первым распознаем имя — по готовому набору
И что, встреваем для имен, которых в наборе не было? Не запаримся Болеславов и Владиленов в список забивать?
K_O>, затем — отчество: корень, состоящий из известного имени + одно из окончаний (-вич, -вна, ...)
Опять же с неизвестным именем мы пролетаем что ли? Окончаний может тоже быть очень много.
K_O>, то, что останется — фамилия.
Замечательно.
K_O>Конечно, это очень упрощенная схема, для реальной задачи ее еще надо настраивать (учет ударений и проч.), но она вполне работоспособна.
Я подозреваю, что эту схему придется не то чтобы настраивать, а скорее банально доделывать. Потому что она не справится даже с простейшими случаями.
K_O>А варианты типа, ИванОвич Иван ИвАнович — здесь и человек не сможет правильно понять, если ударения не указать.

Ну, человек-то справится, понимая, что никто не станет писать отчество перед именем, особенно при такой неопределенности.

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

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

K_O>>Или можешь привести преимущества сложных парсеров перед простыми аналогичной фонкциональности?

VD>Парсеры делаются сложными не ради самоцели. Они делаются сложными, чтобы упростить восприятие кода человеком. Другими словами делается язык удобный для человека, а уже под него делается парсер. То что сложно для парсера зачастую оказывается простым для человека, и наоборот.

А Вы точно знаете что удобно для человека? Можете дать строгое определение удобности для человека?

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

N. W.

Римские цифры вполне удобны для человека, но неприемлемы для осуществления арифметических расчетов, то есть для формальных умозаключений. Я думаю, что тоже самое справедливо и для синтаксиса языка программирования. Синтаксис должен быть максимально прост: везде где только возможено — регулярная грамматика, если не возможно описать регулярной, переходим на ступеньку выше — используем самую простую контекстно свободну грамматику (LL(1)) и т.д. Но никогда не используем более сложную грамматику если вместо нее можно использовать более простую.

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

K_O>>А варианты типа, ИванОвич Иван ИвАнович — здесь и человек не сможет правильно понять, если ударения не указать.
S>Ну, человек-то справится, понимая, что никто не станет писать отчество перед именем, особенно при такой неопределенности.
Один из журналистов "Компьютерры" — Владимир Николаевич (так он статьи подписывает) Я вот до сих пор не уверен, фамилиё это или отчество

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

K_O>>А вот это, думается мне, как раз и совсем несложно.
S>Не, на пальцах практически все алгоритмы выглядят несложными... Вопрос только в том, что:
K_O>>Первым распознаем имя — по готовому набору
S>И что, встреваем для имен, которых в наборе не было?
Эта задача похожа на задачу распознавания (тескта, картинок, неважно чего). Во-первых, такие алгоритмы всегда выдают результат с той или иной степенью достоверности. И бессмысленно от них требовать 100% точности. А во вторых, они способны распознавать данные только из заранее предопределенного набора допустимых значений.

S>Не запаримся Болеславов и Владиленов в список забивать?
Есть еще Даздраперма...
Нет, не запаримся. Кстати об "У Сунь Ю". Мы (русскоговорящие) его не можем разобрать именно потому, что не владеем набором допустимых имен китайского (или какого там) языка.

K_O>>, затем — отчество: корень, состоящий из известного имени + одно из окончаний (-вич, -вна, ...)
S>Опять же с неизвестным именем мы пролетаем что ли? Окончаний может тоже быть очень много.
Окончаний не может быть много. Язак такой. Подозреваю, что дело этими двумя не ограничивается, но прямо сейчас больше ничего не приходит в голову.

Здравствуйте, Сергей Губанов, Вы писали:

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

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

K_O>>>Или можешь привести преимущества сложных парсеров перед простыми аналогичной фонкциональности?

VD>>Парсеры делаются сложными не ради самоцели. Они делаются сложными, чтобы упростить восприятие кода человеком. Другими словами делается язык удобный для человека, а уже под него делается парсер. То что сложно для парсера зачастую оказывается простым для человека, и наоборот.

СГ>А Вы точно знаете что удобно для человека? Можете дать строгое определение удобности для человека?

Ты хочешь формальное определение удобства?
Удобство — это сугубо субъективное понятие.
И если публика в массе говорит, что нечто не удобно, то так оно и есть.
Если для меня синтаксис оберонов не удобен и ничего
кроме отрицательных эмоций не вызывает, то мне не важно, что за этим стоит.

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

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

B>Ты хочешь формальное определение удобства?
B>Удобство — это сугубо субъективное понятие.
B>И если публика в массе говорит, что нечто не удобно, то так оно и есть.
Если бы всегда слово оставалось за "публикой в массе", то Земля бы до сих пор была на трех китах.

B>Если для меня синтаксис оберонов не удобен и ничего
B>кроме отрицательных эмоций не вызывает, то мне не важно, что за этим стоит.
Может для тебя и не удобен, но не исключено, что он не столько неудобен, сколько непривычен.
Мне после Zonnona кое в чем синтаксис С# не нравится. Но это повод говорить, С# никуда не годится.

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

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

B>>Ты хочешь формальное определение удобства?
B>>Удобство — это сугубо субъективное понятие.
B>>И если публика в массе говорит, что нечто не удобно, то так оно и есть.
K_O>Если бы всегда слово оставалось за "публикой в массе", то Земля бы до сих пор была на трех китах.

OK, поправлюсь. Это компромисс.
Но кстати не всегда. Если говорить о продуктах на продажу,
то тот, кто лучше прислушивается к субъективному мнению своих клиентов,
тот имеет больше шансов на успех.
Да, да... Клиентов надо ублажать и им потакать

B>>Если для меня синтаксис оберонов не удобен и ничего
B>>кроме отрицательных эмоций не вызывает, то мне не важно, что за этим стоит.
K_O>Может для тебя и не удобен, но не исключено, что он не столько неудобен, сколько непривычен.
K_O>Мне после Zonnona кое в чем синтаксис С# не нравится. Но это повод говорить, С# никуда не годится.

А разве следование привычкам — это всегда плохо?
Если есть два одинаковых по функционалу продукта, но один из
них выглядит привычно для меня, то я почти наверняка выберу то, что мне привычно.
Но в случае с оберонами разговор о синтаксисе пожалуй вообще излишен.
Я бы пересмотрел свои привычки, если бы видел ради чего. Пока не вижу.
Представленная Сергеем презентация чашу весов на сторону Zonnon не склоняет.
Да и вообще, из нее мало что можно узнать.
Было бы интересно послушать сам доклад и позадавать вопросы.

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


B>Удобство — это сугубо субъективное понятие.
B>И если публика в массе говорит, что нечто не удобно, то так оно и есть.
Это предложение несколько противоречит предыдущему. Ибо здесь уже утверждается что удобство — понятие статитстическое.
И вот с эти согласиться не могу. Никакой миллиард китайцев не убедит меня, что есть рис палочками — это удобно.

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

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


B>>Удобство — это сугубо субъективное понятие.
B>>И если публика в массе говорит, что нечто не удобно, то так оно и есть.
Т>Это предложение несколько противоречит предыдущему. Ибо здесь уже утверждается что удобство — понятие статитстическое.
Т>И вот с эти согласиться не могу. Никакой миллиард китайцев не убедит меня, что есть рис палочками — это удобно.

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

Кстати, лапшу, как еще едят китайцы, удобнее есть все же палочками,
а не вилкой с ложкой
Это даже я, не китаец, готов признать

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

B>Но кстати не всегда. Если говорить о продуктах на продажу,
B>Да, да... Клиентов надо ублажать и им потакать
B>Если есть два одинаковых по функционалу продукта, но один из
B>них выглядит привычно для меня,
B>Представленная Сергеем презентация чашу весов на сторону Zonnon не склоняет.

Ошибка большинства оберононенавистников на этом сайте заключается в том, что они сравнивают
C++/С# и Oberon/Zonnon с точки зрения коммерческого успеха.

Повторяю еще раз: Zonnon — это совместный исследовательский проект Microsoft и ETH с целью:
1. Обкатать технологию CCI.
2. Создать на базе .NET язык нового поколения, который избавил бы программиста от большинства трудемкой работы работы.
См. на activities.

B>Да и вообще, из нее мало что можно узнать.
А на мой взгляд очень интересный документ.

B>Было бы интересно послушать сам доклад и позадавать вопросы.
На сайте Zonnon'a есть координаты разработчика компилятора — задавай вопросы на здоровье.

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

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

B>>Но кстати не всегда. Если говорить о продуктах на продажу,
B>>Да, да... Клиентов надо ублажать и им потакать
B>>Если есть два одинаковых по функционалу продукта, но один из
B>>них выглядит привычно для меня,
B>>Представленная Сергеем презентация чашу весов на сторону Zonnon не склоняет.

K_O>Ошибка большинства оберононенавистников на этом сайте заключается в том, что они сравнивают
K_O>C++/С# и Oberon/Zonnon с точки зрения коммерческого успеха.

Согласен. Если бы Сергей не пытался бы убеждать что обероны — это silver bullet,
то проблем бы не было.
Для меня обероны были всегда исследовательскими проектами
и на сайте ETH об этом вроде явно и пишут.

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

Т>Давно замечено: то, что сложно парсить, как правило трудно и читать (обратное неверно).

Можно узнать имя этого виликого наблюдателя?

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

Далее можно вспомнить один из самых простых в парсинге языков — С. И сравнить легкость чтения искходников на нем с одним самыми сложными для парсинга C++ и C#.

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


VD>Далее можно вспомнить один из самых простых в парсинге языков — С. И сравнить легкость чтения искходников на нем с одним самыми сложными для парсинга C++ и C#.

Да чего уж там.
Легче все читать тексты на естественных языках.
Но вот парсить...

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


B>Для меня обероны были всегда исследовательскими проектами и на сайте ETH об этом вроде явно и пишут.
Так оно и есть. Впрочем, Фортран, Лисп, Си, Си++, Ада тоже были исследовательскими проектами.

B>Если бы Сергей не пытался бы убеждать что обероны — это silver bullet, то проблем бы не было.

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

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

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

B>Да чего уж там.
B>Легче все читать тексты на естественных языках.
Как насчет "Критики чистого разума", желательно в оригинале?