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

S> ключевое слово event, и оно мгновенно вполне конкретизирует нашу абстракцию, позволяя нам избегать примитивных ошибок при реализации подписки/отписки.

пример, пары таких ошибок можно узнать?

Здравствуйте, Кодёнок, Вы писали:

Кё>

New features in Visual C++ 2025:
Кё>...
Кё>- Now you can copy-and-paste your code thus reusing good solution rather than reinventing it!
Кё>...

Лучше не зларадствовал бы, а помог нам донести человеческие технологии до людей. Без интеграции со студией, рефакторинга, дружественного и удобного интерфейса никто не будет смотреть ни на один супер-пупер язык. Вот мы занимаемя разаботкой Интеграции для Немела. Чем смеяться помог бы.

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

Блин, ну, и делать же вам нечего.

Что тут спорить то? Конечно паскалевские и обероновские функции отчасти замыкания. Но с очень большим списком ограничений. И вот как раз от то и не дает использовать их так же красиво как аналоги их ФЯ. Отсуствие лямб так же усугубляет кратину. Так что по жизни пользоваться ими неудобно. В прочем тоже можно сказать и об Обероне как таковом.

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

FR>Возьми clisp м запусти вот эту простейшую программу на схеме:

У Лиспа не только диалекты не совместимы, но и даже разные реализации компиляторов. Так это не о чем не говорит. Главно, что "просто лиспа" нет. Есть море клонов. CL, Схема, Автокад Лисп, Емакс...

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

LCR>Плиз. Эрланг содержит средства для манипуляции своим же АСТ. Всякие субатомные различия о том, насколько подходы к подобной манипуляции различаются по сравнению с другими языками можно оставить за бортом.

Поддерживать средства и иметь языковые возможности несколько разные задачи. Вот для C# есть туча движков для метапрограмирования и что?

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

WR>Короче. Представь себе что это текст который можно править.
WR>

WR>А это текст который нельзя править.
WR>Это тоже нельзя ни удалять ни править.
WR>

А здесь снова можно править.

Небольшой отчет о сделанной работе

Автор: VladD2
Дата: 14.08.06

Подсказки:
...для макроса "while" (сначала приводится код использующий макрос)

(а это уже подсказка) первый варинт нужен чтобы было понятно что ображуем "тело" передавющееся макросу.


Обратите внимание, что код макроса "раскрыт".

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

FR>Просто нужно реализовать нормальное замыкание, Вирт сказал А но не сказал B. Реально для такого примитивного (извини ) языка как оберон просто нормальные замыкания и фвп (включая лямбду) дало бы очень много. Хотя конечно еще нужна полиморфность функций. Притом синтаксическм Оберон практически при этом не усложнится (можно сравнить с тем же питоном, сложность грамматик вполне сопоставима, а мощность нет).

Я кажется знаю в чем дело! Во всем виноват МС! Они доплачивают Вирту чтобы он не портил репутацию С++ как языку "не хуже Оберона".

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

VD>Так что по жизни пользоваться ими неудобно. В прочем тоже можно сказать и об Обероне как таковом.

Был опыт?

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

VD>У Лиспа не только диалекты не совместимы, но и даже разные реализации компиляторов. Так это не о чем не говорит. Главно, что "просто лиспа" нет. Есть море клонов. CL, Схема, Автокад Лисп, Емакс...

Уже давно есть, Common Lisp. Остальные как и схему можно считать лисп подобными языками

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

AVC>>Следовательно, передача в качестве параметра вложенной процедуры/функции не могло привести к ошибке, подобной ошибке в твоем примере (для конструирования такой ошибки тебе потребовалась процедурная переменная).

FR>может и так, но мне это малоинтересно

Ну и не будем об этом говорить.
Меня, например, интересуют различия между Си и Паскалем (например): из этих различий вышло много последствий (и эти различия по-прежнему разделяют некоторые новые языки).
Тебе же, с точки зрения приемов и языков ФП, эти различия не интересны.
Это нормально.

FR>>>Но в том же обероне вместе с GC появилась и возможность сохранять контекст.

AVC>>Разве что ценой значительной потери эффективности.
AVC>>А ведь Оберон все-таки эффективный язык.

FR>Практика показывает что ты не прав, компиляторы Ocaml'а почти не уступают хорошим си компиляторам. Реально потеря эффективности вполне сравнима с потерями от использования классов, то есть часто равна нулю.

Ты меня (пока!) не убедил.
Хотя бы потому, что потеря эффективности от использования классов не равна нулю.

AVC>>Давай посмотрим на это с немного более абстрактной точки зрения.

FR>Это точка быстро скатывается до уровня машиного кода

Хм... машинный код столь абстрактен?

AVC>>Действительно ли цель в том, чтобы имитировать в императивном языке "замыкания", или же важно передавать функцию вместе с данными?

FR>Цель ввести в язык мощное средство позволяющее создавать более сложные абстракции и писать более понятный и компактный код. При том не требующее так не любимого Виртом усложнения синтаксиса. Я не спорю что любые высокоуровневые средства можно эмулировать более низкоуровневыми, но это всегда криво и куча лишней ненужной писанины, ничего ни дающей а только скрывающей смысл.

Этой фразы я пока не понял.
Все программирование можно свести к "эмулированию высокоуровневых средств низкоуровневыми".
ИМХО, это нормально.
Больше трудностей вызывает обратный подход.

AVC>>С такой общей задачей объекты вполне справляются и без "замыканий".

FR>В лиспе и схеме объекты реализуются через замыкания.

У меня всегда были проблемы с пониманием отдельных приемов ФП.
Именно потому, ИМХО, что какая-нибудь простая (с императивной точки зрения) сущность зачастую реализуется в них слишком сложно.

AVC>>А как говорил Эйнштейн, "два мыла — это слишком сложно".

FR>А мыло и стиральный порошок?

Пачкаться меньше надо!

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

VD>Лучше не зларадствовал бы, а помог нам донести человеческие технологии до людей. Без интеграции со студией, рефакторинга, дружественного и удобного интерфейса никто не будет смотреть ни на один супер-пупер язык. Вот мы занимаемя разаботкой Интеграции для Немела
Это, мягко говоря, преувеличение...
В моем текущем проекте нет ни интеграции со студией, ни рефакторинга ни для одного из используемых языков. Дружественный интерфейс представлен на выбор FAR или SCITE. Как ни странно, никто не жалуется !
В предыдущей конторе, где я работал, за 8 лет IDE использовалось 1 ( адын ) раз для одного небольшого проекта. И это не была студия.
Весь рефакторинг делался ручками — и только ручками.
Более того, когда я попытался внедрить IDE для тикля ( KOMODO ), это не нашло понимания среди сотрудников.
Так что — окошечки, конечно, хорошо и красиво, но надобность в них не шибео велика

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

AVC>Ну и не будем об этом говорить.
AVC>Меня, например, интересуют различия между Си и Паскалем (например): из этих различий вышло много последствий (и эти различия по-прежнему разделяют некоторые новые языки).

Ну поведение (и существование) вложенных функций мало зависит от того чей потомок язык, например:

int test(int x)
{
int z = 11;

int f(int y)
 {
 return x + y + z;
 }

return f(1);
}

Вполне нормальный код для D.

AVC>Тебе же, с точки зрения приемов и языков ФП, эти различия не интересны.
AVC>Это нормально.

В рамках этого разговоро малоинтересно, а вообще интерсно


FR>>Практика показывает что ты не прав, компиляторы Ocaml'а почти не уступают хорошим си компиляторам. Реально потеря эффективности вполне сравнима с потерями от использования классов, то есть часто равна нулю.

AVC>Ты меня (пока!) не убедил.
AVC>Хотя бы потому, что потеря эффективности от использования классов не равна нулю.

От классов в C++ равна нулю, от виртуальных функций ненулевая, но обычно близкая к нулю. Ты говорил о

Разве что ценой значительной потери эффективности.
А ведь Оберон все-таки эффективный язык

этого и рядом нет.

AVC>>>Давай посмотрим на это с немного более абстрактной точки зрения.

FR>>Это точка быстро скатывается до уровня машиного кода

AVC>Хм... машинный код столь абстрактен?

Так я же не виноват что твоя абстрактная точка зрения катится именно в эту сторону

AVC>>>Действительно ли цель в том, чтобы имитировать в императивном языке "замыкания", или же важно передавать функцию вместе с данными?

FR>>Цель ввести в язык мощное средство позволяющее создавать более сложные абстракции и писать более понятный и компактный код. При том не требующее так не любимого Виртом усложнения синтаксиса. Я не спорю что любые высокоуровневые средства можно эмулировать более низкоуровневыми, но это всегда криво и куча лишней ненужной писанины, ничего ни дающей а только скрывающей смысл.

AVC>Этой фразы я пока не понял.
AVC>Все программирование можно свести к "эмулированию высокоуровневых средств низкоуровневыми".
AVC>ИМХО, это нормально.

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

AVC>Больше трудностей вызывает обратный подход.

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

AVC>>>С такой общей задачей объекты вполне справляются и без "замыканий".

FR>>В лиспе и схеме объекты реализуются через замыкания.

AVC>У меня всегда были проблемы с пониманием отдельных приемов ФП.
AVC>Именно потому, ИМХО, что какая-нибудь простая (с императивной точки зрения) сущность зачастую реализуется в них слишком сложно.

Замыкания ничем ни сложнее объектов.

AVC>>>А как говорил Эйнштейн, "два мыла — это слишком сложно".

FR>>А мыло и стиральный порошок?

AVC>Пачкаться меньше надо!

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

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

VD>>Лучше не зларадствовал бы, а помог нам донести человеческие технологии до людей. Без интеграции со студией, рефакторинга, дружественного и удобного интерфейса никто не будет смотреть ни на один супер-пупер язык. Вот мы занимаемя разаботкой Интеграции для Немела
G>Это, мягко говоря, преувеличение...

Преувеличение считать, что твое мнение является истиной в последнй инстанции.
Я же говорю о том о чем много раз говорил с другими программистами. В FAR-е сегодня писать решатся еденицы.

G>В моем текущем проекте нет ни интеграции со студией, ни рефакторинга ни для одного из используемых языков. Дружественный интерфейс представлен на выбор FAR или SCITE. Как ни странно, никто не жалуется !

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

G>В предыдущей конторе, где я работал, за 8 лет IDE использовалось 1 ( адын ) раз для одного небольшого проекта. И это не была студия.
G>Весь рефакторинг делался ручками — и только ручками.

Могу только вырзить свои соболезнования. Кстати, можно ссылочку на то что вы делате?

G>Более того, когда я попытался внедрить IDE для тикля ( KOMODO ), это не нашло понимания среди сотрудников.
G>Так что — окошечки, конечно, хорошо и красиво, но надобность в них не шибео велика

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

Я вот, например, не имею машину и не хочу ее иметь. Причем с деньгами у меня все впорядке. Просто она мне не нужна. У меня работа в 10 минутах хотьбы. Спортзал тоже. А если куда-то нужно доехать то проще руку поднять. Ну, и что? Обоснуем этим фактом отсуствие необходимости в автотранспорте вообще? А кому я тогда руку буду поднимать? И ведь в моем случае никакой экзотики.

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

E>Был опыт?

Ага. Хочешь тоже попробовать?

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

S>В старой джаве был такой Enum Pattern — за неимением нормальной поддержки енумов. Казалось бы, совершенно абстрактная вещь: "создайте класс, в нем набор static final полей...". Ан нет, в 1.6 встроили в язык

В 1.5.

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

S>Почему бы не сделать язык, который ...

Потому-что паттернов может быть море. И на все случаи жизни соломку не подложишь. Такие вещи обязаны быть в библиотеке.

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

public mutable MyEvent : array[int -> void] = array(0);

Но не так чтобы это было проблемой.
Далее остается реализовать для массива операторы "+" с "-" и дело будет в шляпе.
Ну, а можно и завести класс "event". Тогда будет вообще крастота:

public MyEvent : Event[int -> void] = Event();

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

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

FR>Ну поведение (и существование) вложенных функций мало зависит от того чей потомок язык <...>

Многие языки, внешне (синтаксически) похожие на Си, по своему действительному устройству (семантически) являются потомками совсем других языков.
Си++, наверное, единственный живой потомок Си.
Основной чертой Си (без которой этого языка просто нет) является адресная арифметика.
И сколько языков ее унаследовали?

AVC>>Ты меня (пока!) не убедил.
AVC>>Хотя бы потому, что потеря эффективности от использования классов не равна нулю.

FR>От классов в C++ равна нулю, от виртуальных функций ненулевая, но обычно близкая к нулю. Ты говорил о
FR>

FR>Разве что ценой значительной потери эффективности.
FR>А ведь Оберон все-таки эффективный язык

FR>этого и рядом нет.

Не будем спорить — искусным кодированием можно добиться многого.
То, что создание эффективного кода на Си++ (раньше просто — Си с классами) требует дополнительных навыков, не я придумал.
Об этом книги написаны (Булка и др.).
И причина в основном в классах (конструкторы и т.д.).

AVC>>>>Давай посмотрим на это с немного более абстрактной точки зрения.
FR>>>Это точка быстро скатывается до уровня машиного кода
AVC>>Хм... машинный код столь абстрактен?
FR>Так я же не виноват что твоя абстрактная точка зрения катится именно в эту сторону

Не замечал, но в принципе — может быть.
Я сейчас действительно продумываю детали оптимизатора, все эти перестановки инструкций, чтобы потрафить конвейеру, и т.п.
Возможно, это как-то "просачивается" наружу.

FR>Нормально если этим занимается компилятор, а не программист ручками. В обероне по моему победил второй вариант.

Боюсь, мы опять можем погрузиться в спор "персонально" об Обероне.
А спорить не хочется,
Поэтому все, что я скажу, — мои программы пишутся на Обероне удивительно легко.
А вокруг народ спорит, на чем же им, наконец, стоит писать.
Уверяют, что без той или иной "фичи" жить нельзя.
Мне эти фичи ни разу не потребовались.
Вероятно, это связано с характером ПО, которым я занимаюсь; допускаю, что моя точка зрения была бы иной, если бы я писал другие программы.

AVC>>У меня всегда были проблемы с пониманием отдельных приемов ФП.
AVC>>Именно потому, ИМХО, что какая-нибудь простая (с императивной точки зрения) сущность зачастую реализуется в них слишком сложно.

FR>Замыкания ничем ни сложнее объектов.

Согласен.
Но, ИМХО, в процедурных языках вроде Оберона они небезопасны.
По крайней мере, я сразу не вижу, как можно объединить "замыкания" с процедурными переменными и ничем при этом не пожертвовать.
Стоит ли овчинка выделки?
В Обероне существуют свои паттерны, приемы и идиомы, иногда довольно специфичные — "программная шина" и т.п.
Я пока не сталкивался на практике с какими-либо существенными ограничениями Оберона (повторюсь, что, возможно, это связано с типом программирования, которым я в последнее время занимаюсь).

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

AVC>Основной чертой Си (без которой этого языка просто нет) является адресная арифметика.

Если обобщить, то вообще — "вольное обращение с указателями" (указатель может указывать на что угодно; массив передается как указатель; нет передачи аргумета по ссылке и т.д.).
Чего изначально и намеренно не было в Паскале и его потомках, где указатели работают только с кучей, есть передача аргументов по ссылке и т.д.

Здравствуйте, VladD2, Вы писали:
VD>Кстати, паттерн "event" можно было бы и не делать если немного подумать.
VD>Если у нас есть функциональный тип, то вместо событий можно заводить свойство или поле типа динамического массива нужного функционального типа.
Нельзя. Будет нарушена инкапсуляция. Обрати внимание, что снаружи невозможно получить список подписчиков на event или отписать кого-то неизвестного. В Delphi так и было — события реализовывались как свойства функционального типа. В дотнете все грабли именно с тем, что для свойства есть риск сделать = вместо +=.

Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Sinclair, Вы писали:
ANS>пример, пары таких ошибок можно узнать?
public class EventPublisher
{
public EventHandler SomethingHappen;
public event EventHandler SomethingElseHappen;
}

public class EventSubscriber
{
public SubscribeTo(EventPublisher p)
{
p.SomethingHappen += HandleEvent; // ok
p.SomethingElseHappen += HandleEvent; // ok
p.SomethingHappen = HandleEvent; // ok!!!
p.SomethingElseHappen = HandleEvent; // compiler error
}
private void HandleEvent(object sender, EventArgs a)
{
}
}