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


FR>>>Если осторожно, то ничего страшного. В той же схеме очень интенсивно используют и ничего
Т>>Что хохлу в радость, то свинье — смерть.

FR>А почему куда потерял?

Это же было "кажется", но шас попробую сформулировать.
Когда в замыкании фиксируются значения, получаются простые и понятные с детства знакомые функции. Но когда в замыкании переменные, получается нечто маловразумительное: разрозненные процедуры, манипулирующие частью глобального состояния программы, для которой даже нет имени. Наверняка, этому можно найти применение. Но "как мудрые программисты, осознающие свои ограничения" мы вряд ли воспользуемся этой свободой. Скорее, следуя учению тт. Абельсона и Сассмана, мы соберем все эти процедуры в некоторую структуру и дадим ей имя. То есть, получим самый обычный объект.

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


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

Я не думаю что это основная черта си.

AVC>И сколько языков ее унаследовали?

Ну например C# и D.


AVC>Не будем спорить — искусным кодированием можно добиться многого.

При чем тут искуссное кодирование? Тут виноваты только разработчики компиляторов

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

Угу только учти что без классов все это чащае всего и выглядет стрешнее и работы тербует больше.

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

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



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

AVC>Боюсь, мы опять можем погрузиться в спор "персонально" об Обероне.
AVC>А спорить не хочется,
AVC>Поэтому все, что я скажу, — мои программы пишутся на Обероне удивительно легко.

На любом нормально освоенном языке программы пишутся удивительно легко

AVC>А вокруг народ спорит, на чем же им, наконец, стоит писать.

Что-то не замечал, вроде большинство здесь довно выбрали на чем писать.

AVC>Уверяют, что без той или иной "фичи" жить нельзя.
AVC>Мне эти фичи ни разу не потребовались.

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

AVC>Вероятно, это связано с характером ПО, которым я занимаюсь; допускаю, что моя точка зрения была бы иной, если бы я писал другие программы.

А какой именно характер у твоего ПО?

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

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

AVC>Согласен.
AVC>Но, ИМХО, в процедурных языках вроде Оберона они небезопасны.

Не опаснее объектов. Если же использовать лексическое статистическое связывание то безопаснее объектов.

AVC>По крайней мере, я сразу не вижу, как можно объединить "замыкания" с процедурными переменными и ничем при этом не пожертвовать.

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

AVC>Стоит ли овчинка выделки?

Стоит

AVC>В Обероне существуют свои паттерны, приемы и идиомы, иногда довольно специфичные — "программная шина" и т.п.

Интересно, что за зверь?

AVC>Я пока не сталкивался на практике с какими-либо существенными ограничениями Оберона (повторюсь, что, возможно, это связано с типом программирования, которым я в последнее время занимаюсь).

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

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

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

А от сборки мусора? Хотя окамловский сборщик мусора очень хорош,но все же на современнных процессорах стек — более подходящее место для локальных переменных, чем куча.

VladD2,

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

Да получается, что C# тоже весь насквозь мета, всё упирается в количество сахара

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


FR>>А почему куда потерял?

Т>Это же было "кажется", но шас попробую сформулировать.
Т>Когда в замыкании фиксируются значения, получаются простые и понятные с детства знакомые функции. Но когда в замыкании переменные, получается нечто маловразумительное: разрозненные процедуры, манипулирующие частью глобального состояния программы, для которой даже нет имени. Наверняка, этому можно найти применение. Но "как мудрые программисты, осознающие свои ограничения" мы вряд ли воспользуемся этой свободой. Скорее, следуя учению тт. Абельсона и Сассмана, мы соберем все эти процедуры в некоторую структуру и дадим ей имя. То есть, получим самый обычный объект.

А ну это понятно, я думал есть другие причины кроме религиозных

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

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

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

Т>А от сборки мусора? Хотя окамловский сборщик мусора очень хорош,но все же на современнных процессорах стек — более подходящее место для локальных переменных, чем куча.

От сборки мусора конечно, но и тут от оптимизатора зависит, тот же окамловский простые случаи вообще до константных чисел раскрывает.

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

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

FR>Я не думаю что это основная черта си.

Ну вот мне после 20 лет интенсивного кодирования на Си подумалось, что основная.
(Еще можно отметитть краткость синтаксиса, слабую типизацию и наличие битовых операций, но специфическая связь между массивами и указателями, ИМХО, наиболее яркая черта.)
До появления нормальных оптимизаторов адресная арифметика позволяла оптимизировать код "вручную".
Например:

{
    register struct xxx *p;
    struct xxx *stop = &a[n];

    for (p = &a[0]; p < stop; ++p)
    {
         p->...
    }
}

AVC>>И сколько языков ее унаследовали?

FR>Ну например C# и D.

Я в C# не силен (из Си-подобных языков мне по характеру работы наиболее подходит как раз Си ), поэтому верю каждому печатному слову.
Например:
http://www.intuit.ru/department/pl/csharp/11/

В языке C# снято существенное ограничение языка C++ на статичность массивов. Массивы в языке C# являются настоящими динамическими массивами. Как следствие этого, напомню, массивы относятся к ссылочным типам, память им отводится динамически в "куче". К сожалению, не снято ограничение 0-базируемости, хотя, на мой взгляд, в таком ограничении уже нет логики из-за отсутствия в C# адресной арифметики. Было бы гораздо удобнее во многих задачах иметь возможность работать с массивами, у которых нижняя граница не равна нулю.

AVC>>Не будем спорить — искусным кодированием можно добиться многого.

FR>При чем тут искуссное кодирование? Тут виноваты только разработчики компиляторов

Ну и не без этого (хотя я имел в виду, что кодировать на Си++ надо весьма вдумчиво, а то полезут всякие временные объекты, да еще со своими конструкторами).
Только вот "у нас" в Обероне жалоб на них (разработчиков компиляторов) меньше.
Просто написать хороший компилятор Си++ намного труднее, чем хороший же компилятор Оберона.

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

FR>Угу только учти что без классов все это чащае всего и выглядет стрешнее и работы тербует больше.

Это другой вопрос.
Я только отметил, что накладные расходы на классы все-таки есть.
Догадываюсь, что и сборка мусора в Ocaml не совсем бесплатная.

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

AVC>>А вокруг народ спорит, на чем же им, наконец, стоит писать.

FR>Что-то не замечал, вроде большинство здесь довно выбрали на чем писать.

Давно пишут, да.
Но до сих пор выбирают.
Споры о языках у нас порой самые жуткие.

AVC>>Уверяют, что без той или иной "фичи" жить нельзя.
AVC>>Мне эти фичи ни разу не потребовались.

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

AVC>>Вероятно, это связано с характером ПО, которым я занимаюсь; допускаю, что моя точка зрения была бы иной, если бы я писал другие программы.

FR>А какой именно характер у твоего ПО?

В основном — системное (компиляторы, отладчики и т.п.).

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

AVC>>Согласен.
AVC>>Но, ИМХО, в процедурных языках вроде Оберона они небезопасны.

FR>Не опаснее объектов. Если же использовать лексическое статистическое связывание то безопаснее объектов.

В Обероне (в отличие от ФЯ) опаснее.
Система типов в Обероне герметичная, доступ в память полностью под контролем.
А если использовать "замыкание" со стековыми локальными переменными и наличии в языке процедурных переменных (а в Обероне это так), то можно получить "замыкательный" аналог "dangling pointer".

AVC>>По крайней мере, я сразу не вижу, как можно объединить "замыкания" с процедурными переменными и ничем при этом не пожертвовать.

FR>Я вот не пойму чем именно придется пожертвовать?
FR>Старый код это не затронет, синтаксис не изменится, те кому это не нужно могут просто игнорировать. Например я видел код на питоне, в стиле java все в сплошных мелких классах, его можно переписать на замыканиях сократив раза в два и сделав намного понятнее, но и так как написано работает и то что в языке есть замыкания не мешает писать и по старому.

AVC>>Стоит ли овчинка выделки?

FR>Стоит

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

AVC>>В Обероне существуют свои паттерны, приемы и идиомы, иногда довольно специфичные — "программная шина" и т.п.

FR>Интересно, что за зверь?

Отдаленно похоже на обработку оконных сообщений в Windows, но при полном контроле типов.
Сообщение передается как запись (структура).
Обработчик сообщений обрабатывает сообщение в соответствии с его динамическим типом. (Благодаря специфическому устройству дескриптора типа в Обероне динамическая проверка типа сводится к одному сравнению (в машинном коде).)
Главное назначение — возможность расшения набора сообщений без перекомпиляции других модулей.
Используется в основном для визуальных объектов, в сочетании с принипом "родительского контроля" позволяет делать рассылки без "актов подписки/отписки" и связанных с ними возможных ошибок.
Ну и т.д.

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

S> public EventHandler SomethingHappen;
S> public event EventHandler SomethingElseHappen;
S> p.SomethingHappen = HandleEvent; // ok!!!
S> p.SomethingElseHappen = HandleEvent; // compiler error

Ради этого вводить сущность event? А не проще было сделать интерфейс addEvent, removeEvent. А прямой доступ вообще закрыть. Или сдесь еще есть что-то?

AVC>>>И сколько языков ее унаследовали?

FR>>Ну например C# и D.

Ага, кажется понял, что ты имел в виду.
http://www.bytemag.ru/?ID=600814

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

Т.е. в unsafe блоках все-таки использовать адресную арифметику можно.
Ясно. Наверное, меня тут Java немного с толку сбила: думал, после нее уже вообще не станут использовать адресную арифметику.

VladD2 wrote:

> public MyEvent : Event[int -> void] = Event();
> Причем так как не надо описывать делегаты, то получается еще короче. Так
> что иногда паттерны можно не встраивать в язык, а* полностью устранять
> необходимость в них*. Думаю, что Курилка в том числе говори и об этом в
> своеей теме.
А это точно всё? Ты уверен, что банальный массив указателей на методы удовлетворит жаждущего паттерн Visitor? Ведь если
взять те же boost::signals и посмотреть что там есть:
Ordering slot call groups
Passing values from slots
Disconnecting Slots
Blocking Slots
Scoped connections

Или это уже не паттерн?

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

VD>Преувеличение считать, что твое мнение является истиной в последнй инстанции.
VD>Я же говорю о том о чем много раз говорил с другими программистами. В FAR-е сегодня писать решатся еденицы.
Кто говорит про незыблемую истину ? Я всего лишь ОБОСНОВАННО опроверг твое утверждение, что студия нужна всем. И ФАР был как пример, поскольку люди используют и Сцинтиллу, и Анжуту, которые не более чем редакторы с тем или иным сервисом. Кроме того, не будем забывать про существование Эклипса ( который тяжел и кривоват ) и Емакса /ВИМа

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

VD>Могу только вырзить свои соболезнования. Кстати, можно ссылочку на то что вы делате?
На предыдущей работе или сейчас ?
Ссылка бесполезна, ибо информационный сайт давно не обновлялся
Раньше писал всякую телеметрию / телеуправление, удаленную обработку приборных данных и т.п. Все многоплатформенное, и Вынь никак не основная платформа. Стоит и используется на ядерных и прочих критических производствах. Языки : С, С++, Тикль, Ерланг
Сейчас делаем сервер обработки муниципальных данных. Это всяческие паспортные столы, товарищества собственников жилья и прочее. Движок гибкий : позволяет использовать как скрипты, так и наборы правил для реализации конкретного приложения. Сервер целиком на ерланге + на ерланге же в нем реализован DSL. Клиент на тикле + около 200 строк на плоском С

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

VD>Это твое мнение которое не разделяет большинство программистов. Если вам нравится экзотика, то никто вам мешать не будет. Но не надо обосновывать воей экзотичностью отсуствие нобходимости в чем-то для окружающий.
Они сами — не жаждут. Им никто не запрещает использовать то, что больше понравится. Даже более того, я это поощряю ( в робкой надежде, что производительность труда возрастет ). Они и пробуют периодически то одно, то другое. Заметного выигрыша как-то не обнаружено.
Почему экзотика ? Или ты про выбор языков ?

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

Здравствуйте, FR, Вы писали:
FR>А ну это понятно, я думал есть другие причины кроме религиозных

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

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


AVC>Ну вот мне после 20 лет интенсивного кодирования на Си подумалось, что основная.

Не знаю, по моему основное в си максимальная близость к железу, все остальное следствия.


FR>>Ну например C# и D.

AVC>Я в C# не силен (из Си-подобных языков мне по характеру работы наиболее подходит как раз Си ), поэтому верю каждому печатному слову.

В unsafe доступна работа с указателями и индексной арифметикой.


FR>>При чем тут искуссное кодирование? Тут виноваты только разработчики компиляторов

AVC>Ну и не без этого (хотя я имел в виду, что кодировать на Си++ надо весьма вдумчиво, а то полезут всякие временные объекты, да еще со своими конструкторами).
AVC>Только вот "у нас" в Обероне жалоб на них (разработчиков компиляторов) меньше.
AVC>Просто написать хороший компилятор Си++ намного труднее, чем хороший же компилятор Оберона.

Это да.

AVC>Это другой вопрос.
AVC>Я только отметил, что накладные расходы на классы все-таки есть.
AVC>Догадываюсь, что и сборка мусора в Ocaml не совсем бесплатная.

конечно.

AVC>Давно пишут, да.
AVC>Но до сих пор выбирают.
AVC>Споры о языках у нас порой самые жуткие.




FR>>А какой именно характер у твоего ПО?

AVC>В основном — системное (компиляторы, отладчики и т.п.).

Такие вещи говорят как раз проще писать ML подобных языках, например на том же Ocaml'е


AVC>В Обероне (в отличие от ФЯ) опаснее.
AVC>Система типов в Обероне герметичная, доступ в память полностью под контролем.
AVC>А если использовать "замыкание" со стековыми локальными переменными и наличии в языке процедурных переменных (а в Обероне это так), то можно получить "замыкательный" аналог "dangling pointer".

Если вводить в оберон замыкание, этой "опаснасти" быть не должно, компилятор должен при создании замыкания копировать переменные в контекст.


FR>>Стоит

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



AVC>>>В Обероне существуют свои паттерны, приемы и идиомы, иногда довольно специфичные — "программная шина" и т.п.

FR>>Интересно, что за зверь?

AVC>Отдаленно похоже на обработку оконных сообщений в Windows, но при полном контроле типов.

То есть аналог dispath (если склероз не подвел) методов из Delphi?

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

FR>>А какой именно характер у твоего ПО?
AVC>В основном — системное (компиляторы, отладчики и т.п.).
Ууу... Тут тебе самая дорога на клоны ML вобще и немерле в чатности.
Я тут пишу парсер простенького языка описаний чтото типа такого:

chanel FileStorageChanel
{
    message Ok();
    message Error(message : string);

    message BeginTransaction();
    message PutFile(name : string, data : stream);
    message DelFile(name : string);
    message EndTransaction();
    message Commit();
    message Rollback();

    state Main
    {
        !BeginTransaction
        (!PutFile | !DelFile)*
        !EndTransaction
        (!Commit | !Rollback)
        (?Ok | ?Error)
        -> Main
    }

    message GetFile(name : string);
    message File(data : stream);

    state Main
    {
        !GetFile
        (?File | ?Error)
        -> Main
    }
}

process FileStorage
{
    Start(key : string, user : string, chanel : FileStorageChanel.Out.Main);
}

Ключевые слова chanel, message, state, process контекстно зависимые те можно написать так

chanel chanel
{
    message message();
}

И мы получим канал с именем chanel в котором есть сообщение с именем message.
Думаю полностью рукописный синтаксический анализатор со всеми проверками и человекочитаемыми сообщениями об ошибках у меня займет 400 — 500 строк.
А все по тому что после лексера который еще и сворачивает по скобкам и имена типа asd.asd.asd также сворачивает в один токен

[Record]
public variant Token
{
    public begin : Pos;
    public end : Pos;
    
    | Identifier { name : list[string]; }
    | Operator { name : string; }
    | Semicolon                      // ;
    | Colon                          // :
    | Comma                          // ,
    | Brace { tokens : list[Token] } // { }
    | Round { tokens : list[Token] } // ( )
//Дальше идет реализация лексера мение 200 строк

я могу писать так

        def parse(tokens : list[Token])
        {
        | Identifier(["chanel"]) :: Identifier(name) :: Brace(decls) :: tokens =>
            parseChanel(name, decls);
            parse(tokens);

        | Identifier(["process"]) :: Identifier(name) :: Brace(decls) :: tokens =>
            parseProcess(name, decls);
            parse(tokens);

        | token :: _ => 
            throw CompileError(token);
        
        | [] => ()
        }
        and parseChanel(name, decls)
        {
            WriteLine($"chanel : $name");
            def parse(decls : list[Token])
            {
            | Identifier(["message"]) :: Identifier(name) :: Round(decls) :: Semicolon :: tokens =>
                parseMessage(name, decls);
                parse(tokens);

            | Identifier(["state"]) :: Identifier(name) :: Brace(decls) :: tokens =>
                parseState(name, decls);
                parse(tokens);
            
            | token :: _ => 
                throw CompileError(token);
            
            | [] => ()
            }

Причем нет никаких проблем с заглядыванием вперед (хотя тут оно вобщем и не нужно).

Это называется pattern-matching + алгебраические типы(variant).

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

LCR>Да получается, что C# тоже весь насквозь мета, всё упирается в количество сахара

Получается, что кто-то выдает желаемое за действительное и в упор не хочет видеть факты.

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

VD>>Преувеличение считать, что твое мнение является истиной в последнй инстанции.
VD>>Я же говорю о том о чем много раз говорил с другими программистами. В FAR-е сегодня писать решатся еденицы.
G>Кто говорит про незыблемую истину ? Я всего лишь ОБОСНОВАННО опроверг твое утверждение,

Своим частным мнением? Создай голосование, увидишь чего оно стоит.

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

S>Нельзя. Будет нарушена инкапсуляция.

S> Обрати внимание, что снаружи невозможно получить список подписчиков на event или отписать кого-то неизвестного.

Event можно сделать классом и наружу выставить только операторы + и -.
Ключевое слово event в C# банально вводит свойство доступное только для чтения обеспечивая доступ к нему только по операторам + и -. В общем, бессмысленный хардкодинг.

Да и кому такая инкапсуляция нужна. Это что инкапсуляция ради инкапсуляции?

S> В Delphi так и было — события реализовывались как свойства функционального типа.

В Дельфи не было списка.

S> В дотнете все грабли именно с тем, что для свойства есть риск сделать = вместо +=.

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

А вот то что в язык вообще не надо встраивать ничего чтобы получить такой же эффект — это показатель. И таких вещей море.

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

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

kan>VladD2 wrote:

>> public MyEvent : Event[int -> void] = Event();
>> Причем так как не надо описывать делегаты, то получается еще короче. Так
>> что иногда паттерны можно не встраивать в язык, а* полностью устранять
>> необходимость в них*. Думаю, что Курилка в том числе говори и об этом в
>> своеей теме.
kan>А это точно всё?

Ага. Для событий все. Причем не нужно даже ядрёной енергии макросов. Просто более грамотный дизайн языка.

kan> Ты уверен, что банальный массив указателей на методы удовлетворит жаждущего паттерн Visitor?

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

kan> Ведь если взять те же boost::signals и посмотреть что там есть: kan>Ordering slot call groups
kan>Passing values from slots
kan>Disconnecting Slots
kan>Blocking Slots
kan>Scoped connections

kan>Или это уже не паттерн?

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

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

WH>Это называется pattern-matching + алгебраические типы(variant).

Да уж Обероновские структуры с динамическим типом явно отдыхают.

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

FR>>>А какой именно характер у твоего ПО?
AVC>>В основном — системное (компиляторы, отладчики и т.п.).
WH>Ууу... Тут тебе самая дорога на клоны ML вобще и немерле в чатности.

Спасибо за идею.
Я буду посматривать в этом направлении.

При создании компилятора надо решить много разных задач, больших и маленьких.
(Слава Богу, что это давно не целина, а хорошо исследованная область!)
Кроме лексического разбора, синтаксического и семантического анализа есть еще оптимизация и генерация кода, сохранение отладочной информации и т.д.
Есть и свои противоречия: например, трудновато совместить оптимизацию кода и отладку (оптимизированный код далек от исходного).
Собственно, именно, они и занимают все время, лексика и синтаксис обычно вообще не проблема (если это не Си++ ).
Интересно, насколько клоны ML могут помочь мне в этих задачах.
Что же касается синтаксического анализа, то частенько "все сделано до нас" (для известных языков).
Если есть необходимость написать парсер и не хочется писать его методом рекурсивного спуска a-la Wirth (или грамматика не позволяет), то в нашем распоряжении yacc (для LR-грамматик) или CoCo/R(для LL(1)-грамматик; кстати, автор CoCo/R является также автором языков Object Oberon и Оберон-2).

WH> <...>
WH>Причем нет никаких проблем с заглядыванием вперед (хотя тут оно вобщем и не нужно).

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

WH>Это называется pattern-matching + алгебраические типы(variant).

Спасибо, буду знать.