Свой компилятор(С++'о подобный)

[Utkin]

что-то вроде:

using(auto f=new File("1.txt"))
{
    //code
}

в using шапке можно лишь обьявлять переменные(через запятую) создавая/инициализируя их, если все созданы нормально, то блок перейдет внутрь, а если нет...
хм, думаю полезно может оказаться чтото вроде else для using(эта часть обсуждаема)

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

[Пепел Феникса]

2Пепел Феникса, А как Вы собираетесь реализовать автовывод типов и перегрузку функций вместе? Как генерическую функцию? Тогда что с примитивными типами, вроде int? Будут генерироваться специализированные ф-ции для примитивов, или параметры будут упаковываться? В любом случае, я против автовывода, так как это, как правило, сильно замедляет компиляцию.

ровно так же как работает auto в С++ и var в C#.
отличие в том что компилятор будет стараться вывести типы автоматически так же для параметров(если не указаны явно).
если не справляется, то выдаст ошибку.
на времени компиляции это скажется незначильно.

И ещё кое что. Уверены ли Вы по поводу отсутствия уборщика мусора? Мне кажется, ссылочная семантика и отсутствие уборщика мусора плохо скажутся на простоте контроля над памятью.

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

И есть ли реальная необходимость в decltype, если нет шаблонов?

есть генерики, а не шаблоны(различия надеюсь не нужно обьяснять?)

за callbyname функции

а что это? можно примерчик?

возможность определения неизменяемых переменных

const,readonly?

кортежи

а можно примерчик этого? я не очень понимаю что это...

Не вижу смысла в п. 14, п. 18

абстрагирование от архитектуры.

и Обдумывание.п.2.

я тут сам 50 на 50, с виду и удобно, а с другой, очень уж не привычно.

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

я не имею опыта с функциональными ЯП.
можно ссылку на подробное описание этих конструкций?

[Utkin]

Есть немного в 4-м выпуске журнала http://procoder.info/index.php/articles/04/128-sheme1
Точнее смотреть надо в английском варианте.

[netrino]

Сообщение от Пепел Феникса

ровно так же как работает auto в С++ и var в C#.
отличие в том что компилятор будет стараться вывести типы автоматически так же для параметров(если не указаны явно).
если не справляется, то выдаст ошибку.
на времени компиляции это скажется незначильно.

Я к тому, что будет сгенерировано в таком случае:

func(a, b) {
  return a + b;
}

func(1, 2);
func("Hello, ", "World!");

Тут есть некоторые проблемы, а именно: как определить функцию, как генерическую (и таким образом придётся упаковывать целые числа, что скажется на производительности), или определить две функции (одна для примитивных типов, другая для объектов); Необходимо определить, что для a и b существует оператор +, что в случае генерической (а не шаблонной) функции весьма затруднено, ведь информация о типе поступает во время исполнения.

Сообщение от Пепел Феникса

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

Хм, уборщик на основе подсчёта ссылок имеет известные проблемы как с производительностью, так и с циклическими ссылками, что отлично видно в реализациях C++ и Vala (unique_ptr, weak_ptr ...). Но ладно, допустим. В таком случае, действительно ли необходима возможность контроля над счётчиком ссылок? Довольно опасная вещь.

Сообщение от Пепел Феникса

есть генерики, а не шаблоны(различия надеюсь не нужно обьяснять?)

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

Сообщение от Пепел Феникса

а что это? можно примерчик?

Это функция, которая откладывает вычисление параметров до первого их использования. Удобного, например, для assert'ов или debug'ов

callbyname void assert(bool cond, string msg) {
  if (assertsEnabled)
    if (cond) // Тут произойдёт вычисление LongComputation
      throw new AssertFailureError(msg);
}

assert(LongComputation(), "assertion failed");

Другими словами, LongComputation как бы попадает в лямбду типа () => LongComputation; и не будет вызван до вызова этой лямбды.

Сообщение от Пепел Феникса

const,readonly?

Да, то что в шарпе звётся readonly

Сообщение от Пепел Феникса

а можно примерчик этого? я не очень понимаю что это...

Это как неименованные структуры(tuples)

(string, int) replaceAll(string s, char from, char to) {
  int count = 0;
  ... // заменяем все символы в строке s с подсчётом кол-ва замен
  return (new_string, count);
}
...
auto t = replaceAll("string", 't', 'r');
println(t.1, t.2);
auto (s, c) = replaceAll("string", 't', 'r');
println(s, c);

Сообщение от Пепел Феникса

абстрагирование от архитектуры.

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

Сообщение от Пепел Феникса

я тут сам 50 на 50, с виду и удобно, а с другой, очень уж не привычно.

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

[Пепел Феникса]

Необходимо определить, что для a и b существует оператор +, что в случае генерической (а не шаблонной) функции весьма затруднено, ведь информация о типе поступает во время исполнения.

это можно сделать и во время компиляции, хоть и чуть труднее, чем в рантайме, хоть и реально + я отлично представляю это себе.

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

явно указав что она генерическая(тогда так же явное указание типов).
примитивные типы тоже объекты, конечно при возможности это будет оптимизировано, но это уже иной разговор.

В таком случае, действительно ли необходима возможность контроля над счётчиком ссылок?

контроль лишь в сторону уменьшения(причем на один, не более), что позволит уничтожить объект раньше конца блока(причем дальше ссылаться на этот объект уже никак, да и компиль может это отследить во время компиляции)

Другими словами, LongComputation как бы попадает в лямбду типа () => LongComputation; и не будет вызван до вызова этой лямбды.

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

Это как неименованные структуры(tuples)

ну об этом подумаю.

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

пожалуй, логично.

[netrino]

Сообщение от Пепел Феникса

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

Я имел ввиду, что если в моём примере assertsEnabled == false, то LongComputation() не будет вычислено.
В остальном, главное, что Вы всё это хорошего представляете, посмотрим со временем, может что-то хорошее получится)
И кстати, может быть будет интересно, в D (и ещё некоторых языках) есть интересная фича, называемая scope-guard, выглядит это примерно так:

void fn(string s) {
  Object obj = malloc (sizeof(Object)); // небезопасное выделение памяти, или какого-либо неавтоматического ресурса

  scope (exit) {
    println("Exit");
    free (obj); // эта строчка выполнится обязательно по завершению ф-ции
  }

  scope (success) { // если мы достигли конца ф-ции
    println("Everything is O.K.");
  }

  scope (failure) { // если мы не достигли конца ф-ции (вышли по исключению)
    println("Error occured");
  }

  // ... работа с obj
}

Вот, правда, это довольно грубый пример, тем не менее, идея должна быть понятна. scope (exit) будет выполнено при выходе из текущей области видимости, scope (failure) только в том случае, если мы выходим с исключением, scope (success) в ином случае. Удобно для освобождения ресурсов и всего прочего в таком духе. Безусловно, того же эффекта можно достичь используя try/catch/finally, но так выглядит красивше)

[Пепел Феникса]

делегирование внутрь...хм интересный вариант.

scope guard как то не красивы

[netrino]

Сообщение от Пепел Феникса

scope guard как то не красивы

Ну тут каждому своё, с этим не поспоришь))
Но по моему это красивей, чем

void fn(string s) {
  Object obj = malloc (sizeof(Object));
  bool exceptionOccured = false;

  try {
    // работа с obj
  } catch (Exception e) {
    println("Error occured");
    exceptionOccured = true;
  } finally {
    if (!exceptionOccured) {
      println("Everything is O.K.");
    }
    println("Exit");
    free (obj);
  }
}

Или удобно в таком случае:

bool call (Object obj, string s) {
  BSTR sz = SysAllocString(s.c_str());
  scope (exit)
    SysFreeString(sz);
  return obj.call(sz);
}

В это случае sz освободится по выходу из функции, но после вызова obj.call
Впрочем, это вам уже решать

[_-Re@l-_]

это очень читабельно?

Да.

по вашим темам пока все что я видел это потерю указателя

Ну - да, пока бывает и такое что я допускаю ошибки. Со временем пройдёт но так или иначе, всё равно мне нужна такая возможность.

2_-Re@l-_, C++09 не существует. decltype официально принят в C++11.

С++ 09 не существует?! Чёйта вдруг? Он был , есть и будет.

[Utkin]

Необходимо определить, что для a и b существует оператор +, что в случае генерической (а не шаблонной) функции весьма затруднено, ведь информация о типе поступает во время исполнения.

Функциональное программирование показывает, что это заблуждение. Автовывод типов позволяет определить получаемые типы еще до исполнения, а значит генерить те функции, которые будут задействованы.