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

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

K>>цель — сделать синтаксис С++ более приятным + добавить необходимые фичи без написания компилятора

T>Программа переводящая с вашего Clean-C++ на C++ технически будет компилятором. По определению. Не вижу причин генерировать C++ код а например не гораздо более чистый C-код или LLVM IR. Генерируемый C сделает совместимость вашего Clean-C++ со всем чем угодно только лучше.

так я там вроде и писал что генерироваться будет Си код, а не С++, Си вполне достаточно, про ллвм знаю мало поэтому не сильно представляю какие с ней будут трудозатраты

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

T>Не вижу причин генерировать C++ код а например не гораздо более чистый C-код или LLVM IR.

Перевести, например, вот это:

foo(A a, B b)
{
    return a + b;
}
// ...
x = foo(y, z);

в это:

struct foo__
{
    template<typename A, typename B>
    decltype(auto) operator()(A a, B b) const
    {
        return a + b;
    }
} const foo;
// ...
auto x = foo(y, z);

Намного легче чем в "C-код или LLVM IR"
Плюс остаётся возможность использовать уже готовые библиотеки.

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

K>так я там вроде и писал что генерироваться будет Си код, а не С++, Си вполне достаточно, про ллвм знаю мало поэтому не сильно представляю какие с ней будут трудозатраты

Sorry, невнимательно прочитал.

И что вас останавливает? Берете за базу clang или любой другой open source frontend для C++ чтобы не писать его с нуля (потому что это убиться). Модифицируете, добавляя мадзянга и няшек по вашему усмотрению, выкладываете на sourceforge, ???, profit.

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

EP>Перевести, например, вот это:
EP>[ccode]
EP>foo(A a, B b)
EP>{
EP> return a + b;
EP>}

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

А значит он всё равно будет переводить исходную конструкцию в свой IR (деревья хотя бы строить), потом немного может быть оптимизировать и потом сбрасывать в некое представление. IR по любому будет ближе к C, чем к C++, так что и сбрасывать будет лучше в C. Или вы хотите как IR тоже использовать нечто C++ подобное? Вот такого точно никто никогда не делал =)

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

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

Я не знаю сколько кучерявости нужно автору, но такой rewrite компилятор помог бы упростить многие места + добавить новые возможности.
afaik, в компиляторе D некоторые фичи реализованы именно как rewrite к "более раннему D".

T>А значит он всё равно будет переводить исходную конструкцию в свой IR (деревья хотя бы строить), потом немного может быть оптимизировать и потом сбрасывать в некое представление. IR по любому будет ближе к C, чем к C++, так что и сбрасывать будет лучше в C.

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

T>Или вы хотите как IR тоже использовать нечто C++ подобное? Вот такого точно никто никогда не делал =)

Я выше приводил ссылку

Автор: Evgeny.Panasyuk
Дата: 01.11.13

как раз на такое. Например переводит это:

foldl :: (a -> b -> a) -> a -> [b] -> a
foldl f x [] = x
foldl f x (y:ys) = foldl f (f x y) ys

add x y = x + y -- The builtin operators are not first-class functions

sum xs = foldl add 0 xs -- Currying is not yet supported

в это:

template< int > struct Int;
template< bool > struct Bool;
struct nil;
template< class, class > struct cons;
template< template< class, class > class, class, class > struct foldl;
template< class, class > struct add;
template< class > struct sum;

template< int x >
struct Int
{
  static const int v = x;
};

template< bool b >
struct Bool
{
  static const bool v = b;
};

template< template< class, class > class f, class x >
struct foldl< f, x, nil >
{
  typedef x v;
};

template< template< class, class > class f, class x, class y, class ys >
struct foldl< f, x, cons< y, ys > >
{
  typedef typename foldl< f, typename f< x, y >::v, ys >::v v;
};

template< class x, class y >
struct add
{
  typedef Int< (x::v) + (y::v) > v;
};

template< class xs >
struct sum
{
  typedef typename foldl< add, Int< 0 >, xs >::v v;
};

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

EP>Я выше приводил ссылку

Автор: Evgeny.Panasyuk
Дата: 01.11.13

как раз на такое. Например переводит это:
EP>

EP>foldl :: (a -> b -> a) -> a -> [b] -> a
EP>foldl f x [] = x
EP>foldl f x (y:ys) = foldl f (f x y) ys

EP>add x y = x + y -- The builtin operators are not first-class functions

EP>sum xs = foldl add 0 xs -- Currying is not yet supported      
EP>

Вообще-то, ценность хаскелла в способности компилятора к оптимизации алгоритмов на высоком уровне.
Ну, там, начиная с элементарного length(map any_fun the_list) == length(the_list).

Просто избавиться от синтаксического оверхеда — дело приятное, но не самое главное.

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

K>так я там вроде и писал что генерироваться будет Си код, а не С++, Си вполне достаточно, про ллвм знаю мало поэтому не сильно представляю какие с ней будут трудозатраты

В С++ есть много чего такого, что трудно поддержать в С. Ну, например, если в вашем "чистом С++" будут позволены исключения, тот на С будет компилячиь трудно. Или, например, если будут позволены шалоны или Inline-функции или методы, сгенерированные компилятором или виртуальные метод или...

весь тред не читал, но возможно тут еще не приводили как пример Vala:
https://wiki.gnome.org/Vala/Tutorial/ru

я его когда-то тыкал. оно генерит Си-код из своего синтаксиса. чем-то напоминает C#.