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

WR>осталось дело за малым — как получать синтаксически компактные представления логики программы для конкретных паттернов.

Метапрограммирование решает эту задачу. Так что и решение есть. Осталось дело за мылым. В мэйнстрим должен войти язык хорошо поддерживающий метапрограммирование.

VladD2 wrote:

> kan>паттерн Visitor, можно это обозвать signal/slots и некоторые
> алгоритмамы обозвать таким паттерном, что вообще говоря не совсем точно.
> Ага. Совсем не точно. Но тем неменее Visitor не только легко запихиваетя
> в библиоетеку если в языке есть метапрограммирование (МП), но и вообще
> может быть бессмысленным если в языке есть сопоставление с образцом
> (паттерн-матчинг).
Даже в таком языке реализация тех же банальных сингал-слотов вполне может быть оправданной в некоторых ситуациях.

> kan> Но вот как можно библиотекой представлять те же структурные
> паттерны. Возьмём какой-нибудь Facade — что можно библиотекой оргаризовать?
> Ага. Это как раз замечательный кандидат на автоматизацию. Достаточно
> продумать как отображать один интерфейс на другой (например, в виде
> атрибутов) и написать код который породит весь код Фасада по этому
> простому описанию.
Фасад как простая выборка/переименование некоторых методов — обычно не нужен, нужен тоненький слой кода, а значит уже не
простым отображением ифейса не обойтись.
Вот и тут получилось как обычно в таких ситуациях: "Совсем не точно".

> kan> Или даже какой язык может предоставить специальную конструкцию для
> этого паттерна?
> Nemerle! Что за несуразные вопросы, право.
А я думал 42.

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

> так никто не говорит, что реализация должна быть одна и она не может
> быть гибкой (настраивамемой). Реализаций может быть море. Как у тех же
> алгоритмов сортировки. А особенности так же можно описывать
> декларативно, а метакод будет их читать и учитывать.
Алгоритмы сортировки — алгоритмы, а не паттерны.

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

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

WR>>осталось дело за малым — как получать синтаксически компактные представления логики программы для конкретных паттернов.

VD>Метапрограммирование решает эту задачу. Так что и решение есть. Осталось дело за мылым. В мэйнстрим должен войти язык хорошо поддерживающий метапрограммирование.


Влад. Вот в этом утверждении я неуверен. чисто интуитивно.

Вот логика моих размышлений: (очень приближённая схема)

любая программа — это граф. (разрешите опустить детализацию, что это за граф такой).

подняли за одну вершину — получили дерево, потянули за другую — другое дерево.

всё что я знаю о метапрограммировании говорит мне о том, что оно позволяет наиболее эффективно создавать такие деревья.

но тут задача состоит в другом — как из одного дерева получить граф, а по нему построить другое дерево.
эта задача, насколько мне известно, немного шире метапрограммирования.

если неубедил, то попробую подыскать подходящий пример. Хотя что это я. Далеко ходить ненадо — вот к примеру задачка про двойную диспетчеризацию, она же паттерн Visitor, она же мультиметоды.

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

kan>Фасад как простая выборка/переименование некоторых методов — обычно не нужен, нужен тоненький слой кода, а значит уже не
kan>простым отображением ифейса не обойтись.
kan>Вот и тут получилось как обычно в таких ситуациях: "Совсем не точно".

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

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

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


WR>если неубедил, то попробую подыскать подходящий пример. Хотя что это я. Далеко ходить ненадо — вот к примеру задачка про двойную диспетчеризацию, она же паттерн Visitor, она же мультиметоды.

И что этот пример должен показать?

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

WR>Влад. Вот в этом утверждении я неуверен. чисто интуитивно.

Зачем в таких вопросах интуиция?

WR>всё что я знаю о метапрограммировании говорит мне о том, что оно позволяет наиболее эффективно создавать такие деревья.

Вряд ли это можно назвать знанием о МП.

МП — это (если кратко) возможность написать программу которая создаст другую программу по некому алгоритму и входным данным.

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

Да и что тут обсуждать, когда есть реальные примеры реализации?
Например, вот Прокси с делегированием:
http://nemerle.org/svn/nemerle/trunk/macros/DesignPatterns.n

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

WR>>если неубедил, то попробую подыскать подходящий пример. Хотя что это я. Далеко ходить ненадо — вот к примеру задачка про двойную диспетчеризацию, она же паттерн Visitor, она же мультиметоды.

К>И что этот пример должен показать?

Видимо, то что это легко решается средствами МП.
http://rsdn.ru/projects/rsharp/article/rsharp_mag.xml#ERH
далее ищем по слову Visitor.

VladD2 wrote:

> kan>Фасад как простая выборка/переименование некоторых методов — обычно
> не нужен, нужен тоненький слой кода, а значит уже не
> kan>простым отображением ифейса не обойтись.
> kan>Вот и тут получилось как обычно в таких ситуациях: "Совсем не точно".
>
> Как показывает практика, чем более грамоно проектирование, и чем больше
> используются те самые праттерны, тем меньше нужны ручные прослойки. Так
> что очень дажа можено обойтись и без них.
А что тогда такое Facade, как не ручная прослойка?
Похоже что твой идеал — программист должен выбрать язык (ну понятно, что nemerle), а программа сама напишется; писать
код — для ламеров, настоящие программисты должны знать только единственно правильный язык, этого достаточно.

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

VD>Он позволяет написать внешнюю метапрограмму. Это позволяет любой универсальный язык. Когда люди говорят о метапрограммировании в ЯП, то речь идет о средствах самого языка. Таких средств в Эрлэнг нет.

Ну так нечестно

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

FR>>Там я спорю потому что ты по моему слишком широко трактуешь понятие "синтаксический сахар"

VD>Такое ощущение, что ты только по этому поводу споришь.

В общем да
Ну кроме того я и с твоим опонентом вполне согласен в том что ФВП это сила

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

kan>А что тогда такое Facade, как не ручная прослойка?

Автоматическая прослойка созданная по некоторому правилу.

kan>Похоже что твой идеал — программист должен выбрать язык (ну понятно, что nemerle), а программа сама напишется; писать код — для ламеров, настоящие программисты должны знать только единственно правильный язык, этого достаточно.

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

kan>Вот пример кода, что там можно сделать встроенным в язык?

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

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

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


WR>>если неубедил, то попробую подыскать подходящий пример. Хотя что это я. Далеко ходить ненадо — вот к примеру задачка про двойную диспетчеризацию, она же паттерн Visitor, она же мультиметоды.

К>И что этот пример должен показать?

Этот пример показывает. как меняется решение (и даже формулировка) одной и той же задачи в зависимости от точки зрения. А исторически сформировавшихся точек зрения (языки) уже очень много.
В сложившейся ситуации очень наивно полагать, что некоторый язык программирования займёт верх и заткнёт все остальные куда следует. (слишком много людей придётся переучивать).
Можно ожидать появления такой технологии работы с кодом, которая будет обходить эти различия, равно как и точки зрения на задачу.

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

WR>>всё что я знаю о метапрограммировании говорит мне о том, что оно позволяет наиболее эффективно создавать такие деревья.

VD>Вряд ли это можно назвать знанием о МП.

[поскипано]

Хорошо. У меня есть любимый пример. Классика MFC! Подключаем тулбар в майнфрейму.

Есть следующие точки касания тулбара:

1. декларация объекта тулбара как члена класса.
2. загрузка объекта из ресурса при создании майнфрейма.
3. обработка CmdUI для показа/скрытия тулбара. метод + регистрация обработчика в карте сообщений.
4. кнопка/менюшка для показа/скрытия тулбара. метод + регистрация обработчика в карте сообщений

Влад, может я отстал, чем тут поможет МП?

VladD2 wrote:

> kan>А что тогда такое Facade, как не ручная прослойка?
> Автоматическая прослойка созданная по некоторому правилу.
Не получится ли это в большинстве случаев сложнее ручной?

> kan>Похоже что твой идеал — программист должен выбрать язык (ну понятно,
> что nemerle), а программа сама напишется; писать код — для ламеров,
> настоящие программисты должны знать только единственно правильный язык,
> этого достаточно.
> Умные люди не пишут код который можно сгенерировать. Точнее делают это
> один раз, задалбываются и в следующий раз ищут средства автоматизации.
> МП это как раз такое средство.
На такие разовые случаи обычно продвинутого текстового редактора хватит, или, в конце концов, что-то типа awk или perl —
по вкусу.

> kan>Вот пример кода <http://en.wikipedia.org/wiki/Fa%C3%A7ade_pattern&gt;,
> что там можно сделать встроенным в язык?
> Там описан примитивный случай. Тут и автоматизировать нечего. А бывает,
> так что ты долбишь море похожего кода вместо того чтобы описать одир наз
> то как он должен создаваться сам.
Ок, но мне всё-таки хочется понять, что же в данном (или подобном) случае можно придумать "встроенное в язык"?

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

kan>VladD2 wrote:

>> kan>А что тогда такое Facade, как не ручная прослойка?
>> Автоматическая прослойка созданная по некоторому правилу.
kan>Не получится ли это в большинстве случаев сложнее ручной?

Автоматизировать нужно только то что можно автоматизирвоать. В прочем принцип разумности он везде будет не лишним.

kan>На такие разовые случаи обычно продвинутого текстового редактора хватит, или, в конце концов, что-то типа awk или perl —
kan> по вкусу.

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

kan>Ок, но мне всё-таки хочется понять, что же в данном (или подобном) случае можно придумать "встроенное в язык"?

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

Я под фасадом все же понимаю преобразование одного интерфейса другим. Вот тут уже можно сделать очень многое.

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

WR>Хорошо. У меня есть любимый пример. Классика MFC! Подключаем тулбар в майнфрейму.

WR>Есть следующие точки касания тулбара:

WR>1. декларация объекта тулбара как члена класса.
WR>2. загрузка объекта из ресурса при создании майнфрейма.
WR>3. обработка CmdUI для показа/скрытия тулбара. метод + регистрация обработчика в карте сообщений.
WR>4. кнопка/менюшка для показа/скрытия тулбара. метод + регистрация обработчика в карте сообщений

WR>Влад, может я отстал, чем тут поможет МП?

В С++ и МФЦ кроме траха ничего. В других языках это можно было бы легко автоматизировать. Но в других языках (в том же C#) перечисленные действия можно было бы устранить сделав добавление новой команды декларируемым в неком XML-файле. Другими словами решить не за счет метапрограммирования, а за счет компонентной парадигмы. Так что это не очень хороший пример.

Хорошим примером является, например, реализация метода почленного сравнения класса или вычисления почленного хэш-значения. Вот такие примеры действительно компонентно не решаются, а с помощью МП решаются на раз. Вот гляди сам:
Макрос анализирующий поля класса и генерирующий стандратный метод вычисления хэш-значения для всех полей класса:

[Nemerle.MacroUsage (Nemerle.MacroPhase.WithTypedMembers,
                     Nemerle.MacroTargets.Class,
                     Inherited = false, AllowMultiple = false)]
macro StructuralHashCode (t : TypeBuilder) {
  def flds = t.GetFields (BindingFlags.Public %| BindingFlags.NonPublic %|          
                          BindingFlags.Instance %| BindingFlags.DeclaredOnly);

  def body = 
    List.FoldLeft (flds, <[ 0 ]>, fun (x : IField, acc) {
      <[ $acc %^ $(x.Name : usesite).GetHashCode () ]>
    });
  t.Define (<[ decl:
    public override GetHashCode () : int {
      $body
    }
  ]>);
}

Макрос добавляющий к классу функцию сравения:

[Nemerle.MacroUsage (Nemerle.MacroPhase.WithTypedMembers,
                     Nemerle.MacroTargets.Class,
                     Inherited = false, AllowMultiple = false)]
macro LexicographicCompareTo (t : TypeBuilder) {
  def tname = t.ParsedName;
  def flds = t.GetFields (BindingFlags.Public %| BindingFlags.NonPublic %|
                          BindingFlags.Instance %| BindingFlags.DeclaredOnly);
  def compareField (fld : IField)
  {
      def nm = Macros.UseSiteSymbol (fld.Name);
      def hasLess = match (fld.GetMemType ()) {
          | MType.Class (ti, _) =>
            def name = ti.FullName;
            match (name) {
                | "Nemerle.Core.string"
                | "System.String"
                | "Nemerle.Core.int"
                | "System.Int32"
                | "System.UInt32"
                | "Nemerle.Core.float"
                | "System.Single"
                | "Nemerle.Core.double"
                | "System.Double"
                | "Nemerle.Core.char"
                | "System.Char" =>
                  true
                | _ =>
                  false
            }
          | _ => 
            false
      }
      if (hasLess)
      {
          <[ 
            if (this.$(nm : name) < other.$(nm : name)) 
            {
                -1
            }
            else if (this.$(nm : name) > other.$(nm : name)) 
            {
                1
            }
            else
            {
                0
            }
         ]>
     }
     else
     {
         <[ this.$(nm : name).CompareTo (other.$(nm : name)); ]>
     }
  }
  def body = 
    List.FoldRight (flds, <[ 0 ]>, fun (x : IField, acc) { 
      <[ 
         def cmp = $(compareField (x));
         if (cmp == 0) 
         {
             $(acc)
         }
         else
         {
             cmp
         }
      ]>
    });
  def full = if (t.IsValueType) 
  {
      body 
  }
  else
  {
      <[ 
         if (object.ReferenceEquals (this, other)) 
         {
             0
         }
         else if (object.ReferenceEquals (other, null))
         {
             1
         }
         else
         {
             $(body)
         }
      ]>
  }

  t.Define (<[ decl:
    public CompareTo (other : $(tname : name)) : int { $full }
  ]>);
  t.Define (<[ decl:
    public CompareTo (Oother : object) : int 
    { 
      try 
      {
        def other = Oother :> $(tname : name);
        this.CompareTo (other)
      } 
      catch 
      {
        | _ is System.InvalidCastException => throw System.ArgumentException ()
      }
    }
  ]>);
}

Далее если нам понадобится добавить к классу функции сравнения или вычисления хэш-значения, то нам останется только пометить класс атрибутами LexicographicCompareTo и StructuralHashCode соотвественно.

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

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

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

DG>Паттерны, это, ИМХО, больше алфавит, достаточно удобный надо признать.

Почти половина паттернов — суть костыли для бинарных подробностей реализации полиморфизма в некоторых языках. Во многих динамических языках они просто не нужны. Так что, тот самый список паттернов из GOF я бы сократил вдвое примерно. Или как минимум разбил список на 2 части.


DG>А что бы каждый раз их не реализовывать — на то есть DSLи и прочие кодогенерации, на которые можно возложить самую рутинную работу.

Кодогенератор — тоже костыль.

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

Минус за сравнение Схемы с Лиспом и заявлением об отсутствии метапрограмирования в Прологе. В прологе сразу несколько способов метапрограммирования... У него программа — как данные, и в классическом виде это интерпретатор На нем довольно легко свои DSL вводить или обогащать семантику стандартного "решателя".

Because it is possible to directly access program code in Prolog, it is easy to write interpreter of Prolog in Prolog. Such interpreter is called a meta-interpreter. Meta-interpreters are usually used to add some extra features to Prolog ...

...Meta-programming is easy and elegant in Prolog because the term syntax is identical with the clause syntax ...

... so we can use terms (data) to name clauses (programs)

“Meta-programming in Prolog”, CIS335: Logic Programming,
Goldsmiths’ College, University of London 2

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

AVC>>Догадываюсь, что ФВП — это "функции высшего порядка".
AVC>>Т.е. речь идет исключительно о средствах языков функционального программирования?

VD>Они как бы просто напрашиваются. Хорошие проработанные идеи. Что делать вид что их нет? Вирт не просто делает вид, что их нет. Он еще пытается их вредность доказать. Что по-моему вообще неразумно.

Видимо, имеются в виду заявления Вирта, вроде тех, что сделаны им в
http://www.rsdn.ru/article/philosophy/virt.xml

Автор(ы): Никлаус Вирт
Дата: 23.05.2006
Уважаемые читатели! Один из наиболее известных, авторитетных и заслуженных деятелей в области программирования профессор Никлаус Вирт опубликовал в январском номере журнал Computer очень интересную, по моему мнению, статью. Я не мог отказать себе в удовольствии пересказать ее, чтобы предложить получившийся текст вашему вниманию.

как по поводу функционального программирования, так и по другим поводам.
Например,

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

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

Вместе с тем, ИМХО, Вирт высказал вполне разумную мысль.
Причем у меня возникает впечатление, что между "современными" методами расширения языков (например, макросами Немерле) и "классическими" ( =упомянутыми Виртом ) есть существенное сходство.

VD>Вот только из ФЯ я бы в первую очередь брал бы паттерн-матчинг, замыкания и локальные функции (которые почти есть в Обероне).

Локальные (вложенные?) процедуры (в т.ч., конечно, процедуры-функции) в Обероне есть (как, кажется, и во всех потомках Паскаля).
Вместе с тем, существует запрет на присвоение локальных процедур процедурным переменным.
Возможная причина — при вызове локальной процедуры должна передаваться некая дополнительная информация (дисплеи и т.п.), корректность которой компилятор может обеспечить только при "правильной" последовательности вызовов.

VD>Но в язык хорош было бы добавить и другие вещи вроде foreach и т.п.

Здесь есть опасность вкусовщины.
К примеру, FR, при принципиальном, как мне кажется, согласии с тобой, foreach все же недолюбливает...
Какой критерий включения/невключения новой конструкции в язык можно было бы предложить?

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

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

V>Минус за сравнение Схемы с Лиспом и заявлением об отсутствии метапрограмирования в Прологе.

С Прологом я правда могу ошибаться, а то что Схема — это клон Лиспа — это 100%. Так что зайди из под анонима и поставь себе минус сам.

V> В прологе сразу несколько способов метапрограммирования... У него программа — как данные, и в классическом виде это интерпретатор На нем довольно легко свои DSL вводить или обогащать семантику стандартного "решателя".

Ну, и как там реализовать скажем встроенную поддержку ХМЛ?