Сортировка списка во время компиляции

Вот зачем нужен такой ппц, а?

Я уж лучше «препроцессором» пройдусь... Это будет работать с любым ЯП.

НЁХ

Вот ее часть, включая сортировку списка.

По ссылке классический С++, бессмысленный и беспощадный. У меня в глазах зарябило от всех этих template

А расскажите, какой практический юз кейс, так сказать, у этой вашей библиотеки?

using namespace std;

В хидере?

Ад.

А способен ли на такое Lisp, Haskell, Agda, Coq, Epigram или Mercury?

Ты забыл OCaml, SML и Prolog.

Для чего нужен TMP, кроме тестирования кода?

Какие списки-то сортируешь? Списки типов?

Это только кусочек библиотеки. А вообще пишу интерпретатор именно Prolog. Тоже в compile-time на C++

На кой ляд тебе сортировка списка констант IRL? Просто потому что «я могу»? И да на этом нашем говнолишпе туева куча списков сортируется во время компиляции без всякой магии. Совсем.

В общем, да. Целое «оборачивается» шаблонным типом Value

template< typename T, T v = T() >
struct Value
{
    enum { val = v };
    typedef T value_type;
};

А какой в этом смысл? Я не часто встречаю вкомпиленые данные, которые надо сортировать. Если же ты это просто, что бы выпедрется, то вынужден тебя огорчить: лисп может любые преобразования делать на этапе компиляции, поскольку макросы лиспа позволяют использовать любые определенные в проге функции(только на этапе компиляции). Так что ненужно и «Lisp, Haskell, Agda, Coq, Epigram или Mercury» не переплюнул.

http://www.haskell.org/haskellwiki/Template_Haskell

Вперёд.

(defmacro msort (&rest lst) `(quote ,(sort lst #'>)))

Эта замечательная программа определяет два списка, затем сливает их в один и сортирует. Во время компиляции.

А способен ли на такое Lisp?

Это шутка такая что ли?

#.(defconstant +funny-list-1+ '(3 2 1))
#.(defconstant +funny-list-2+ '(5 4 6))

(let ((v (list . #.(sort (append +funny-list-1+ +funny-list-2+) #'<))))
  (print v))

«Lisp, Haskell, Agda, Coq, Epigram или Mercury» не переплюнул.

Еще как переплюнул. Всякие уникалы постоянно на лисповских макрос какой-то ужас ваяют, но такого я еще никогда не видел.

Это при чтении же, а у автора при компиляции. Надо как-то так.

(eval-when (:compile-toplevel :load-toplevel :execute)
  (defconstant +list-1+ '(3 2 1))
  (defconstant +list-2+ '(5 4 6)))

(defmacro macrosort (list pred)
  `',(sort (eval list) (eval pred)))

(macrosort (append +list-1+ +list-2+) #'<)

=> '(1 2 3 4 5 6)

Но таки встречный вопрос ТС. Способны ли плюсы сделать сортировку списка при *чтении сорцов*, как в примере korvin_?

Я уж лучше «препроцессором» пройдусь... Это будет работать с любым ЯП.

Согласен. Тут даже не то, что препроцессор; просто часть данных надо прегенерировать.

Если при чтении, то ещё проще:

(print '#.(let ((list-1 '(3 2 1))
                (list-2 '(5 4 6)))
            (sort (append list-1 list-2) #'<)))

Ты ведь знаешь, что на compile-time вычисления время тратится больше, чем на подобные в runtime? Это не говоря уже о сотнях излишних строк.

Это при чтении же, а у автора при компиляции.

Ага, но в данном случае разница не принципиальна.

Если при чтении, то ещё проще:

Разве что списки не сохранятся для последующего использования.

при *чтении сорцов*

C++ не возволяет выполнять управляемые операции ввода/вывода на этапе компиляции

то не нужно в такой реализации. CTFE нужен, а вот тот плюсовый ужос - нет.

Каковы преимущества перед лисповскими макросами?

Эта замечательная программа определяет два списка, затем сливает их в один и сортирует. Во время компиляции.

Ух ты! А можно в студию время сортировки ста миллионов чисел, пожалуйста?

Перепиши лучше этот п***ц на constexpr'ах.

Болезнь всех c++ фанбоев.

А Common Lisp такое умеет, да, даже во время чтения.

'#.(sort '(1 2 3 4) #'>)

Причём, как видишь, всё намного короче

Эх, опередил

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

А в CL во время чтения/компиляции можно сделать всего такого, что в вашем C++ просто и не сделаешь. Например, в специфических случаях вместо вызова функции вкомпилировать более простой код

Генерируешь код, вызываешь конпелятор и загружаешь новую функцию через dlopen. ECL отчасти так и работает :)

а еще плюсы не варят кофе, приходится делать это кофеваркой :)

Каковы преимущества перед лисповскими макросами?

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

А способен ли на такое Lisp, Haskell, Agda, Coq, Epigram или Mercury?

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

Ну если для вас код выше читаем хуже полотна на C++, то у меня для вас плохие новости

А аналог механизма подстановки лучшего кода через compiler macro используется многими реализациями, где тип переменной указали заранее через (declare (type ...)). В цепепе это же просто не нужно.

Вот, кстати, интересная заметка о связи C++ template metaprogramming с фп

http://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/

Вот ссылка на код, который автоматически создает два списка по 7 элементов, мержит и сортирует их (список на 14 эл-в).
Компиляция заняла ~60 секунд.

Перепиши лучше этот п***ц на constexpr'ах.

Тогда в коде появится императивная скверна! Не бывать сему!

Охренеть! 60 сек на g++ vs. 1.5 сек на clang++. Это ШIN!

Есть куда стремиться

* 
; compiling file "/home/vasily/testlol.lisp" (written 18 FEB 2014 05:48:53 PM):

; /home/vasily/testlol.fasl written
; compilation finished in 0:00:00.033
 *list*

(16 24 161 170 179 273 311 351 594 601 740 743 762 857)
*

0.03 секунды

(defparameter *list*
  '#.(let ((part-a (loop repeat 7 collect (random 1000)))
           (part-b (loop repeat 7 collect (random 1000))))
       (sort (append part-a part-b) #'<)))

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

Какой юзкейс?

Но ты молодец, не каждый осилит такое. Хотя выглядит говняно, признай сам.

Так же ж нельзя же.

Результат append получит в качестве хвоста литерал из list-2, а потом мы его подвергаем (деструктивному) sort. CLHS 3.7.1 негодует.

Какой юзкейс?

Эту либу использует недописанная реализация Prolog на шаблонах C++.
Поэтому это еще цветочки по сравнением с Prolog на шаблонах C++.

Святая простота. Лучше задумайся о том, что ты простыни кода мастеришь на плюсах для этой «задачи», которую каждый лиспер решит не задумываясь за 2 сек строчкой кода.

Про тот же пролог, реализации которого в книжках 'on Lisp' & PAIP, если надо (зачем-то) queries в compile-time обработать, пишешь макрос и вуаля. Выше продемонстрировано как. Это _вообще_ не задача.

(append list-1 list-2 nil) ?

Шаблоны C++ головного мозга. Ты скажи лучше, зачем?

Или copy-list.

Ладно, я думаю автор уже понял, что сложность решения этой задачи на порядок где-то различается. :)

Это я чтобы ещё себя проверить. Я что-то думал даже, что там sort не деструктивный, хотя ещё вроде как недавно что-то на лиспе сортировал :)

В Template Haskell я нуб нубом

$ cat Ololo.hs

{-# LANGUAGE TemplateHaskell #-}

module Ololo where

import Language.Haskell.TH

(++|) (ListE a) (ListE b) = ListE (a++b)

less (LitE (IntegerL a)) (LitE (IntegerL b)) = a < b

sortE (ListE ys) = ListE $ sortL ys
    where sortL (x:xs) = let ps = filter (less x) xs
                             qs = filter (not.(less x)) xs
                          in (sortL ps) ++ [x] ++ (sortL qs)
          sortL _ = []


a = [| [3, 2, 7] |]

b = [| [2, 2, 1] |]

$ cat tst.hs

{-# LANGUAGE TemplateHaskell #-}

import Ololo
import Control.Monad

main =
    print $(liftM sortE $ liftM2 (++|) a b)

[7,3,2,2,2,1]