На пятой странице приведен рисунок из которого следует, что следующим шагом после современных Java и C#, будут языки Active Java и Active C# (названия, разумеется, условные). Так вот Zonnon принадлежит этой "активной" серии...
Здравствуйте, bkat, Вы писали:
M>>Боюсь, что не туда, но я не понял на 13-ой странице: M>>
PROCEDURE {PUBLIC} Next( ): REAL;
M>>Ну что за все с головы на ноги. Чем хуже M>>
PUBLIC PROCEDURE Next( ): REAL;
M>>я не понимаю, хоть убейте. B>Скажи спосибо, что не B>
B>;LAER : ) (txeN ERUDECORP CILBUP
B>При определенной снаровке и опыте, который приобретается, можно работать и с таким
Девиз флеймера: ни одного поста без ответа?
А по существу нечего сказать?
Насчет модификаторов — мне фигурные скобки тоже не очень нравятся, но существенных проблем при программировании не возникает.
Может быть потому что, когда ключевое слово procedure идет первым, упрощается структура анализатора.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, bkat, Вы писали:
M>>>Боюсь, что не туда, но я не понял на 13-ой странице: M>>>
PROCEDURE {PUBLIC} Next( ): REAL;
M>>>Ну что за все с головы на ноги. Чем хуже M>>>
PUBLIC PROCEDURE Next( ): REAL;
M>>>я не понимаю, хоть убейте. B>>Скажи спосибо, что не B>>
B>>;LAER : ) (txeN ERUDECORP CILBUP
B>>При определенной снаровке и опыте, который приобретается, можно работать и с таким K_O>Девиз флеймера: ни одного поста без ответа?
K_O>А по существу нечего сказать?
По существу уже много чего сказано.
K_O>Насчет модификаторов — мне фигурные скобки тоже не очень нравятся, но существенных проблем при программировании не возникает. K_O>Может быть потому что, когда ключевое слово procedure идет первым, упрощается структура анализатора.
Возможно. Если создатели языка больше думают о проблемах создателей анализатора,
то кое о чем это тоже говорит.
Но на самом деле это всего лишь догадки.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Mamut, Вы писали:
M>>Боюсь, что не туда, но я не понял на 13-ой странице:
M>>
PROCEDURE {PUBLIC} Next( ): REAL;
M>>Ну что за все с головы на ноги. Чем хуже
M>>
PUBLIC PROCEDURE Next( ): REAL;
M>>я не понимаю, хоть убейте.
СГ>{PUBLIC, ...} — это модификаторы, их может быть несколько. Так что, лично я бы предпочел писать их в конце и без скобок: СГ>
K_O>Может быть потому что, когда ключевое слово procedure идет первым, упрощается структура анализатора.
Возможно. Если создатели языка больше думают о проблемах создателей анализатора,
то кое о чем это тоже говорит.
Но на самом деле это всего лишь догадки.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>На пятой странице приведен рисунок из которого следует, что следующим шагом после современных Java и C#, будут языки Active Java и Active C# (названия, разумеется, условные). Так вот Zonnon принадлежит этой "активной" серии...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>{PUBLIC, ...} — это модификаторы, их может быть несколько. Так что, лично я бы предпочел писать их в конце и без скобок: СГ>
На фиг живым людям чиать наизнанку? Ты не не написал бы "процедура сделать1 публичная", а написал бы "публичная процедура сделать1". Так зачем восприятие поганить?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>На фиг живым людям чиать наизнанку? Ты не не написал бы "процедура сделать1 публичная", а написал бы "публичная процедура сделать1". Так зачем восприятие поганить?
Наизнанку это "защищенная публичная сделать1()", а что процедура предлагается догадаться по контексту.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>{PUBLIC, ...} — это модификаторы, их может быть несколько. Так что, лично я бы предпочел писать их в конце и без скобок: СГ>>
VD>Ага. Очень по Виртовски. Так ведь парсить проще.
А что смешного? Только потому, что этот критерий Вирт выдвинул? Или можешь привести преимущества сложных парсеров перед простыми аналогичной фонкциональности?
VD>На фиг живым людям чиать наизнанку? Ты не не написал бы "процедура сделать1 публичная", а написал бы "публичная процедура сделать1". Так зачем восприятие поганить?
Здесь я с Сергеем согласен, мне тоже такой вариант кажется наиболее удачным. Наизнанку никто не пишет. Я вначале определяю объект (т.е. определяю, что у меня будет именно процедура, а не переменная, класс или константа), а потом уточняю описание этого объекта — статический или, например, перегруженный.
Нигде в программировании мне не будет позволено изменять свойства некоторого объекта, предварительно не описав этот объект. Так и с языками программирования.
А в С-подобных языках модификатор стоит перед объявлением языковой конструкции именно из-за стремления сделать ЯП как можно более похожим на английский, где все прилагательные, относящиеся к существительному, пишутся до этого существительного.
В итоге это приводит к усложнению компилятора. Где-то в стандарте С++ встречается фраза: "Если некоторые выражение выглядит, как объявление, значит это объявление, иначе — это оператор." Вот уж точно "Прэлестно!"
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Mamut, Вы писали:
M>>Боюсь, что не туда, но я не понял на 13-ой странице:
M>>
PROCEDURE {PUBLIC} Next( ): REAL;
M>>Ну что за все с головы на ноги. Чем хуже
M>>
PUBLIC PROCEDURE Next( ): REAL;
M>>я не понимаю, хоть убейте.
СГ>{PUBLIC, ...} — это модификаторы, их может быть несколько. Так что, лично я бы предпочел писать их в конце и без скобок: СГ>
Хотя, конечно, после здравого размышления, написание модификаторов сразу же после слова PROCEDURE ведь действительно более правильно. Вот смотрите, компилятор прочитал слово PROCEDURE, ага думает, сейчас значит будет процедура. Но процедуры бывают разные — абстрактные, обычные, виртуальные, пустые или еще какие-нибудь. Вот компилятор и думает: "А как дальше-то эту процедуру разбирать?". А тут бац, ему сразу же подсказочка вроде {ABSTRACT} — компилятор, мгновенно запускает подсистему синтаксического разбора ABSTRACT процедур.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>{PUBLIC, ...} — это модификаторы, их может быть несколько. Так что, лично я бы предпочел писать их в конце и без скобок: СГ>>
VD>Ага. Очень по Виртовски. Так ведь парсить проще.
VD>На фиг живым людям чиать наизнанку? Ты не не написал бы "процедура сделать1 публичная", а написал бы "публичная процедура сделать1". Так зачем восприятие поганить?
ИМХО компилер должен быть умным и позволять разные варианты по вкусу.
Мне например больше подходит:
Здравствуйте, Сергей Губанов, Вы писали:
СГ>На пятой странице приведен рисунок из которого следует, что следующим шагом после современных Java и C#, будут языки Active Java и Active C# (названия, разумеется, условные). Так вот Zonnon принадлежит этой "активной" серии...
Курилка -> Re: Концепции языка Zonnon
К> Здравствуйте, Сергей Губанов, Вы писали:
СГ>>На пятой странице приведен рисунок из которого следует, что следующим СГ>>шагом после современных Java и C#, будут языки Active Java и Active СГ>>C# (названия, разумеется, условные). Так вот Zonnon принадлежит этой СГ>>"активной" серии...
К> Т.е. Active Perl — это начало серии?
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Или можешь привести преимущества сложных парсеров перед простыми аналогичной фонкциональности?
Парсеры делаются сложными не ради самоцели. Они делаются сложными, чтобы упростить восприятие кода человеком. Другими словами делается язык удобный для человека, а уже под него делается парсер. То что сложно для парсера зачастую оказывается простым для человека, и наоборот.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> Нда. Т.е. процедура возвращающая значение?
Процедура возвращающая значение называется процедурой-функцией:
PROCEDURE f(x: REAL): REAL;
Специальное ключевое слово function используемое для процедур-функций было в старом Паскале 70-го года, в Оберонах обычные процедуры и процедуры-функции обозначаются одним и тем же ключевым словом PROCEDURE.