Имеются в виду взрослые макросы a-la Lisp или Nemerle, а не те, что в C.
Или так: нужны ли макросы в таких языках как Haskell?

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

EC>Имеются в виду взрослые макросы a-la Lisp или Nemerle, а не те, что в C.
EC>Или так: нужны ли макросы в таких языках как Haskell?

Не знал, что есть ограничение на длину темы, поэтому продублирую её:
Являются ли макросы свидетельством недостаточной выразительности системы типов?

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

EC>Являются ли макросы свидетельством недостаточной выразительности системы типов?

Ну...
Всёж типы и код вещи немного разные, хотя, конечно, есть изоморфизм Жирарда-Рейнольдса, только вот с практической точки зрения различия в "обычных" языках довольно значительны, поэтому прямая манипуляция с самим кодом проще, имхо

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

К>Всёж типы и код вещи немного разные,
Первое и второе есть инструмент для решения задачи.

К>хотя, конечно, есть изоморфизм Жирарда-Рейнольдса, только вот с практической точки зрения различия в "обычных" языках довольно значительны, поэтому
К>прямая манипуляция с самим кодом проще, имхо
Чем?

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

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

К>>Всёж типы и код вещи немного разные,
EC>Первое и второе есть инструмент для решения задачи.
Только вот использовать надо оба. Конечно, теоретически всякое можно (чуток обсуждалось здесь

Автор: Курилка
Дата: 09.05.07

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

К>>прямая манипуляция с самим кодом проще, имхо
EC>Чем?
Наверное в силу привычки, ведь даже в функциональном программировании есть по сути "императивная" составляющая, когда скажем sin(x) вычисляется в результате некоторых действий. Как вот ты этот самый синус типами выразишь?
Хотя к макросам это отношение имеет слабое, конечно
Тут вот подумал, возможно, ФВП аналогичны макросам по вычислительной мощности, т.к. манипуляции с кодом по сути, наверное, не отличаются от манипуляций с функциями. Но вот момент манипуляции будет разным — в случае ФВП "развёртка" будет в рантайме, тогда как макросы, как правило манипулируют кодом при компиляции.

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

К>>>прямая манипуляция с самим кодом проще, имхо
EC>>Чем?
К>Наверное в силу привычки, ведь даже в функциональном программировании есть по сути "императивная" составляющая, когда скажем sin(x) вычисляется в результате некоторых действий. Как вот ты этот самый синус типами выразишь?
К>Хотя к макросам это отношение имеет слабое, конечно
К>Тут вот подумал, возможно, ФВП аналогичны макросам по вычислительной мощности, т.к. манипуляции с кодом по сути, наверное, не отличаются от манипуляций с функциями. Но вот момент манипуляции будет разным — в случае ФВП "развёртка" будет в рантайме, тогда как макросы, как правило манипулируют кодом при компиляции.

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

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

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

К>>Тут вот подумал, возможно, ФВП аналогичны макросам по вычислительной мощности, т.к. манипуляции с кодом по сути, наверное, не отличаются от манипуляций с функциями. Но вот момент манипуляции будет разным — в случае ФВП "развёртка" будет в рантайме, тогда как макросы, как правило манипулируют кодом при компиляции.

FR>Кроме макросов и страшной системы типов есть и другие способы метапрограммирования, например метаклассы.

Ммм, ФВП ты считаешь страшной системой типов?
А про метаклассы можно пример?
Или вот здесь, питонский пример есть подобная штука?

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


FR>>Кроме макросов и страшной системы типов есть и другие способы метапрограммирования, например метаклассы.

К>Ммм, ФВП ты считаешь страшной системой типов?
К>А про метаклассы можно пример?

class metaClass(type):
    def __new__(cls, classname, bases, classdict):       
        
        # сохраняем значение в замыкании
        def get(value):
            return lambda self : value
        
        # перебираем все имена и те что имеют тип readonly подменяем на свойства
        for key, value in classdict.iteritems():
            if isinstance(value, readonly):
                classdict[key] = property(get(value.value))
        
        #setattr(cls, "__setattr__", None)    
        return type.__new__(cls,classname,bases,classdict)


class A(object):
    __metaclass__ = metaClass
    a = readonly(1)
    b = readonly("text")

t = A()
print t.a, t.b

Кроме того в питоне есть другое очень удобное средство метапрограммирования, декораторы, они конечно менее мощные чем метаклассы, но более удобные:

# декоратор
def cache(func):
    map = {}
    def call(*args):
        if map.has_key(args):
            return map[args]
        else:
            result = func(*args)
            map[args] = result
            return result

    return call

@cache
def ack(a, b):
    if b == 0:
        return ack(a - 1, 1)
    elif a==0:
        return b + 1
    else:
        return ack(a - 1, ack(a, b - 1))

К>Или вот здесь, питонский пример есть подобная штука?

Нет, этот пример только показывает, что тот кто его писал не знает питона, там все существенно проще:

def foo(n):
    return lambda i : i + n

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

К>Ммм, ФВП ты считаешь страшной системой типов?

Нет конечно, там в контексте было про систему типов, а ФВП я считаю хорошим средством сильно уменьшающим потребность в макросах.

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


К>>>прямая манипуляция с самим кодом проще, имхо
EC>>Чем?
К>Наверное в силу привычки, ведь даже в функциональном программировании есть по сути "императивная" составляющая, когда скажем sin(x) вычисляется в результате некоторых действий. Как вот ты этот самый синус типами выразишь?

Чего в синусе "императивного"? Он, как и все остальные мат. функции, декларируется рядом Тэйлора:

-- Представляем ряд Тэйлора
-- f(x) = a(0)+a(1)*x+a(2)*x^2+a(3)*x^3+...
-- в виде 
-- f(x) = k_ini(x)*(1+k_n(x,1)*(1+k_n(x,2)*(1+k_n(x,3)*(1+...)))))
-- где k_ini и k_n специфичны для конкретной функции
taylor k_ini k_n x = k_ini x * foldr (.) id (map (app k_n x) [2..100]) 1 -- 100 членов хватит за глаза и за уши
                     where app k a n = (1+) . (k a n *)

-- Для экспоненты exp x = 1+x/1!+x^2/2!+x^2/3!+... =
-- = 1*(1+x/1*(1+x/2*(1+x/3*(1+...))))
-- k_ini x = 1
exp_my x = taylor (\x->1) k_n x
   where k_n x n =  x / fromIntegral (n-1)

-- Для синуса sin x = x/1!-x^3/3!+x^5/5!-... =
-- = x*(1-x^2/(2*3)*(1-x^2/(4*5)*(1-...)))
-- k_ini x = x -- id
sin_my x = taylor id k_n x
   where k_n x n = - x^2 / fromIntegral ((2*n-2)*(2*n-1))

-- Для косинуса  cos x = 1-x^2/2!+x^4/4!-x^6/6!+... =
-- = 1*(1-x^2/(1*2)*(1-x^2/(3*4)*(1-...)))
-- k_ini x = 1
cos_my x = taylor (\x->1) k_n x
   where k_n x n = - x^2 / fromIntegral ((2*n-3)*(2*n-2))

А в типы его поднимать незачем, ибо ни фига он не полиморфен

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

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


К>>>>прямая манипуляция с самим кодом проще, имхо
EC>>>Чем?
К>>Наверное в силу привычки, ведь даже в функциональном программировании есть по сути "императивная" составляющая, когда скажем sin(x) вычисляется в результате некоторых действий. Как вот ты этот самый синус типами выразишь?

D>Чего в синусе "императивного"? Он, как и все остальные мат. функции, декларируется рядом Тэйлора:
[cut]
D>
Ну ежу понятно про ряды
Может путано выразился, но мысль в том, что всякие операции аля +, * — императивны, т.к. преобразуются по сути в ассемблерные инструкции и тот же синус выраженный рядом Тейлора есть результат некоторого последовательного вычисления.

D>А в типы его поднимать незачем, ибо ни фига он не полиморфен
Вот об этом сути и речь, что даже если и выражается он в типах, это нафиг особо никому не упало. Ну не будем же мы арифметику на числах Чёрча писать

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

К>Может путано выразился, но мысль в том, что всякие операции аля +, * — императивны, т.к. преобразуются по сути в ассемблерные инструкции и тот же синус выраженный рядом Тейлора есть результат некоторого последовательного вычисления.

А почему не параллельного? Хотя это уже offtop, но распараллелить процесс суммирования ряда при необходимости довольно легко.

D>>А в типы его поднимать незачем, ибо ни фига он не полиморфен
К>Вот об этом сути и речь, что даже если и выражается он в типах, это нафиг особо никому не упало. Ну не будем же мы арифметику на числах Чёрча писать

Ну речь же не идёт о том, чтобы всё поднять на уровень типов/макросов.

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

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

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

Вот об этом "неограничении" и был вопрос, насколько я понимаю — действительно ли на том же Хаскеле можно примерно также просто решать задачи "повышения абстракции", которые решаются на макросах Лиспа/Немерле и иже с ними.

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

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

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

К>Вот об этом "неограничении" и был вопрос, насколько я понимаю — действительно ли на том же Хаскеле можно примерно также просто решать задачи "повышения абстракции", которые решаются на макросах Лиспа/Немерле и иже с ними.

ИМХО, задачи повышения абстракции просто решать ни в каком языке не получится. Абтракцию сперва абстрагировать надо. Причём в контексте наличного языкового инструментария.

Что касается Template Haskell, где есть квазицитирование a-la Nemerle, то я не вижу, чтобы народ активно этим пользовался. Для Haskell'а это немножко инородно и тяжеловесно выглядит, хотя это, опять же, ИМХО.

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

D>ИМХО, задачи повышения абстракции просто решать ни в каком языке не получится. Абтракцию сперва абстрагировать надо. Причём в контексте наличного языкового инструментария.
ммм, не понял, что ты тут имел в виду...

D>Что касается Template Haskell, где есть квазицитирование a-la Nemerle, то я не вижу, чтобы народ активно этим пользовался. Для Haskell'а это немножко инородно и тяжеловесно выглядит, хотя это, опять же, ИМХО.
template-то как раз никто не произносил тут пока
Хотя с другой стороны вопрос — а почему оно инородно?
Может оно там и не нужно особо-то и имеющихся средств вполне хватает для сих нужд?

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

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

D>>ИМХО, задачи повышения абстракции просто решать ни в каком языке не получится. Абтракцию сперва абстрагировать надо. Причём в контексте наличного языкового инструментария.
К>ммм, не понял, что ты тут имел в виду...

Ну, если задача хорошо решается простыми средствами, то незачем городить огород. А если простые средства по каким-то причинам не подходят (много кода, неэффективно, просто невозможно), то подключаем более мощные инструменты (макросы, ФВП, sexy types) и в терминах этих инструментов думаем как задачу решить.

D>>Что касается Template Haskell, где есть квазицитирование a-la Nemerle, то я не вижу, чтобы народ активно этим пользовался. Для Haskell'а это немножко инородно и тяжеловесно выглядит, хотя это, опять же, ИМХО.
К>template-то как раз никто не произносил тут пока
К>Хотя с другой стороны вопрос — а почему оно инородно?
К>Может оно там и не нужно особо-то и имеющихся средств вполне хватает для сих нужд?

Я не специалист в Template Haskell, так, чуть-чуть пробовал. Наверное, просто опыта нет. У Булата есть отличные tutorial'ы haskell.org/bz/th3.htm и haskell.org/bz/thdoc.htm.

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

EC>Имеются в виду взрослые макросы a-la Lisp или Nemerle, а не те, что в C.
EC>Или так: нужны ли макросы в таких языках как Haskell?

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

Да и термин "достаточно/недостаточно" — весьма субъективный, смысл его сугубо интимный для каждого программиста. Так что ответ примерно такой: макроподдержка является инструментом, позволящим приблизить выразительность к уровню достаточности конкретного разработчика.

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

К>Может путано выразился, но мысль в том, что всякие операции аля +, * — императивны, т.к. преобразуются по сути в ассемблерные инструкции и тот же синус выраженный рядом Тейлора есть результат некоторого последовательного вычисления.

Что-то ты глубоко неправильное написал. Императивное и декларативное — это не свойство операций, это стиль записи программы, на чём программист концентритует внимание. Императив это концентрация на изменениях, декларатив это концентрация на существовании (описании). Наличие императивной и декларативной составляющей в каком-то языке или конструкциях не есть неизменное их свойство, а зависит от того, какой смысл программист вложил в свою запись, и от того, как её понял читающий.

Одна и та же запись может быть императивом с одной точки зрения и декларацией с другой. Например, объявление списка
[("add", "ax", "bx"),
("imul", "ax", "dx"),
]
есть чистая декларация с точки зрения языка на котором это написано, и есть чистый императив с точки зрения подпрограммы выполняющей команды из этого списка. Другой пример Лисп: (+ a b) = список из трех элементов.

Императивный или декларативный целиком зависит от того с какой точки зрения посмотреть — является ли это объявлением списка, или инструкцией. Часто и то, и другое. Можно сказать что любая запись есть декларация элементов дерева синтаксического разбора Это как хорошее или плохое — зависит от твоей трактовки.

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

FR>а ФВП я считаю хорошим средством сильно уменьшающим потребность в макросах.

Точно. Надо Лиспарям и самому себе рассказать.

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

EC>Имеются в виду взрослые макросы a-la Lisp или Nemerle, а не те, что в C.
EC>Или так: нужны ли макросы в таких языках как Haskell?

Сначала ответь на похожие ответы из жизни:
1. Являются ли печки не нужными если есть автомабили с хреновым охлождением двигателя и хреновой теплоизоляцией в которых движок греет ноги?
2. Является ли не нужной ложка если в прниципе суп можно хлебать через край тарелки, а гущу есть вилкой?
...

В общем, являются ли ненужными прмые решения предназначенные для решения каких-то проблем, если тоже самое можно сделать "через жопу, автогеном" (с)?

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

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