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

L>>Насколько я понимаю строками Потом даём компилеру. Ну или байткод генерить.

VD>И чем это оличается от вызова компилятора во вроемя исполнения?

VD>Понимаешь, ли в чем дело. Основная проблема метапрограммирования не в том, том чтобы скопилировать и выполнить код врантайме.

Да я понимаю. Я то всего лишь разницу показывал между С и ST, отвечая на сообщение.

IT>Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции.

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

Полагаю, всё упирается в удобство. По мне, так и в ST это тоже делается неудобно

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

IT>>>А как быть с декомпозицией кода?

L>>Прости, не понял. Что имеется в виду?

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

В ST конструкции, подобной твоей быть не может. Язык не тот. Я пытаюсь придумать для чего там могут быть макры, кроме как кодогенерилок и не могу придумать. А для кодогенерации вполне хватает и того, что есть — там ПМ не нужен.

Хотя можно ли это тогда называть макросами, я не знаю

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

ANS>>Так это фича языка лиспа такая, что там абсолютно всё реализовано на макросах.

VD>if, car, cdr тоже?

if — в схеме да car/cdr разумеется примитивы.
А если по существу, то цепляться к тому на чём реализовано — это придирки. В чём недостатки реализации ПМ на макрах?

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

IT>Лучший практический пример — сам Немерле. Базовые средства языка нестолько бедны, что вряд ли их было бы достаточно, чтобы писать простой и лаконичный код.

С Лиспом то же самое, кроме повсеместного использования ПМ.

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

L>if — в схеме да car/cdr разумеется примитивы.
L>А если по существу, то цепляться к тому на чём реализовано — это придирки. В чём недостатки реализации ПМ на макрах?

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

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


E>Игроделанье оказалось ужасно неблагодарным занятием

можно подробнее осветить причину? очень надо

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

E>>Игроделанье оказалось ужасно неблагодарным занятием

I>можно подробнее осветить причину? очень надо

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

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

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

E>>>Игроделанье оказалось ужасно неблагодарным занятием

I>>можно подробнее осветить причину? очень надо

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

понятно. спасибо Агромаднейшее

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



Q>Паттерн-матчинг нужен всегда, когда надо извлекать значения из сложных структур данных (более сложных чем int). Хотя бы с той точки зрения, что не надо писать горы if'ов. В том же Лиспе постоянно можно видеть ступенчатые проверки типов и извлечения значений:
Q>

Q>(if (my-super-struct? p) (my-super-f (my-super-struct->mega-field p))
Q>   (if (my-super-struct2? p) ....))
Q>

а вы не могли бы привести пример как выглядел бы код при паттерн-матчинге?

P.S.
вообще в этом ничего не понимаю. пытаюсь понять.

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

Q>>

Q>>(if (my-super-struct? p) (my-super-f (my-super-struct->mega-field p))
Q>>   (if (my-super-struct2? p) ....))
Q>>

I>а вы не могли бы привести пример как выглядел бы код при паттерн-матчинге?

Ну, как-то так, если переводить на лисповские скобки:

((match p)
  ((my-super-struct (my-super-struct2 x)) ...))

Или как-то так, если использовать более традиционный синтаксис:

match (p)
  | MySuperStruct(MySuperStruct2 as x) => ... // используем x

То есть образец описывающий структуру объекта, а не набор проверок.