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

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

я против шаблонов по типу С++.
лучше уж генерики.

вообще насчет бумаги все верно, там то красиво, а на практике оптимизаций нужно будет до*** проводить.(хоть не грозит проблема асм->bin)

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

в общем небольшой итог синтаксиса(и его вкусностей):

что уже решено:
1)синтаксис сишного стиля.
2)препроцессор отсутствует.
3)классы: один родитель, множество реализаций интерфейса.
4)перегрузка операторов, ужесточена немного по сравнению с С++.
например насчет операторов смещения(обязательны оба), и насчет операторов сравнения.
запрещена одновременная реализация присвающего оператора(+=) и не присвающего(+).
так же думаю вводить ограничение по правилу "от перемены мест слагаем/множителей сумма/произведение не меняется".
для некоторых интерфейсов так же будет введено дополнительное ограничение.
5)шаблонов не будут, будут генерики.(правда это больше разница для компиляции)
6)возможность ограничения параметров генериков:

class A<IAriphmetic t>
{
    public A(t d);
};

в отличие от указания интерфейса в качестве параметра, здесь будет передан объект реализующий интерфейс, а не реализация интерфейса, что даст возможность изменять обьект(например копировать, или RTTI).
7)автовывод типов(в том числе для параметров функции, для него идет прогон по коду в цели анализа кода функции(может там есть зацепка) или же по вызову функции).
если нет возможности понять то ошибка.
8)тип по типу аналогично decltype из C++11.
9)делегатам быть)
причем два принципа.
delegate==указатель на одну функцию.
event==список вызова.*
10)type&==ссылка.
type*==итератор этого типа.
11)foreach нужен.
12)лямбды нужны.
13)компилятор будет анализировать функции на побочность.
если функция не имеет побочного эффекта, то она может быть отложена до необходимости*.
все это будет помечаться в итоговом файле если библиотека.
14)нет указателям.
15)

класс по умолчанию(по аналогии с пространством имен по умолчанию) что позволит писать просто функции.

16)class-helper'ы думаю полезны и нужны.
17)ведение документации прямо в коде, причем для библиотек последняя включается в саму библиотеку.
18)компилятор изолирован от других dll(не наших), доступ к ним только через механизм наподобие маршалинга.
19)поддержка более удобного синтаксиса для RAII.
что-то вроде:

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

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

сборщик тут не нужен(но компилятор проследить за уходом переменных наружу)
что в обдумавании(или требует изменений):
1)

Сообщение от Сtrl

Вот такой можно еще синтаксический сахар:

while (...)
{ ... }
else
{ ... }

Ветвь else выполняется, если цикл не выполнился ни разу.

требует изменений, так как невозможно будет понять к чему относится else, к if или к for/while(для циклов с предусловием думаю такой синтаксис полезен)
2)

Согласитесь, это похоже не решение многих реальных задач? Было бы удобно, если бы язык давал возможность безболезненно писать подобные вещи. Например, так:

foo(x, y, z) = a * b * c // Разбиваем задачу на подзадачи
    where
        a = very_long_calculation(x, y) // Решаем каждую
        b = very_long_calculation(z, y) // подзадачу отдельно
        c = very_long_calculation(x, z)

синтаксис удобен, но это еще нужно обдумать.
3)см принятые решения п 18.
поскольку в else ветке может быть нужно узнать причину невозможности получения ресурсов, то все исключения будут доступны(или через map(точнее аналог), или если одно исключение через lastError, в зависимости от п4).
и насчет else таже проблемка что и в мыслях п1.
4)так же, насчет RAII using.
нужно ли пытаться получить все ресурсы(чтоб сразу узнать обо всех проблемах с ресурсами?

*возможна параллельность, но она не основа, но мысли насчет нее есть.

в общем пока так.

[anyx]

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

1)синтаксис сишного стиля.

Фигурные скобки в том числе? А как насчёт отступов? Чтобы отступы обозначали блоки кода? Причём можно дать возможность писать и так, и так, как это сделано в Haskell и, вроде, в Nemerle. Основным способом я бы считал отступы, а фигурные скобки только для того, чтобы выделить большой блок без необходимости выставлять отступы у сотен строк кода (уже после того, как блок написан)

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

8)тип по типу аналогично decltype из C++11.

Что это?

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

10)type&==ссылка.

Я долго думал о том, нужно ли выделять отдельный тип-ссылку и давать синтаксис для конструирования этого типа. Я пришёл к выводу, что компилятор вполне может сам определить, где использовать значения, а где ссылки.

Или вы про передачу параметров функции? Я бы запретил изменять параметры в функции. Пусть лучше функции могут возвращать несколько значений (кортежем, массивом и т.д.)

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

type*==итератор этого типа.

А это зачем?

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

11)foreach нужен.

Я бы назвал его просто for, а обычный for убрал бы - слишком опасен и нечитабелен.

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

17)ведение документации прямо в коде, причем для библиотек последняя включается в саму библиотеку.

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

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

19)поддержка более удобного синтаксиса для RAII.
что-то вроде:

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

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

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

let
    fin = File("input.txt");
    fout = File("output.txt")
in
{
    // code
}

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

Ветвь else выполняется, если цикл не выполнился ни разу.

Может лучше если цикл вышел не по break'у?

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

foo(x, y, z) = a * b * c // Разбиваем задачу на подзадачи
    where
        a = very_long_calculation(x, y) // Решаем каждую
        b = very_long_calculation(z, y) // подзадачу отдельно
        c = very_long_calculation(x, z)

2)синтаксис удобен, но это еще нужно обдумать.

Обдумать, как будет выглядеть? Т.к. я думаю наличие обдумывать нет смысла - такая конструкция слишком полезна, чтобы её не включать.

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

через lastError

Нет, нечитабельный же вариант. Лучше структурированно, как и в случае исключений:

using (f = File("ololo.txt")
{
}
except (e: FileError)
{
    println("Error! Cann't open file \"" + e.file_name + '"');
}

Или вообще не исключения ловить, а ресурс, при создании которого произошла ошибка (тот же иденти):

using (f = File("ololo.txt")
{
}
except (f -> e: FileError)
{
    println("Error! Cann't open file \"" + e.file_name + '"');
}

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

Чтобы отступы обозначали блоки кода?

фигурные скобки определяют блок.

Что это?

int t;
decltype(t) d;//d будет такого же типа как и t

больше всего это полезно при использовании вывода типов.

Или вы про передачу параметров функции? Я бы запретил изменять параметры в функции. Пусть лучше функции могут возвращать несколько значений (кортежем, массивом и т.д.)

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

Во-первых, зачем auto? Тип ведь всегда можно будет вывести по конструктору.

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

Может лучше если цикл вышел не по break'у?

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

А это зачем?

просто удобный синтаксис для обьявления потокового типа(итератор и поток похожи)

Я бы назвал его просто for, а обычный for убрал бы - слишком опасен и нечитабелен.

я думаю пусть останется.
но будет foreach и repeat циклы, которые куда проще и удобны.

repeat([identificator],start,end,step)
{

}

identificator это имя для переменной с номером/значением итерации.
тип выводиться автоматически.
[start,end] - промежуток выполнения.(если для шага это возможно то end войдет)
step - шаг выполнения.
цикл так же может идти в обратную сторону, если переменные выпали так.(шаг будет изменен автоматически на отрицательный)

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

но хвосты к этому нужны сразу.

Обдумать, как будет выглядеть? Т.к. я думаю наличие обдумывать нет смысла - такая конструкция слишком полезна, чтобы её не включать.

<func_decl>=<params> 
    where
        <param>=<lambda|func_call>
        ...

так выходит оно?

Или вообще не исключения ловить, а ресурс, при создании которого произошла ошибка (тот же иденти):

значит тот же идентификатор, хорошо.

[_-Re@l-_]

2)препроцессор отсутствует.

-1

3)классы: один родитель, множество реализаций интерфейса.

-1(по типу шарпа делали?)

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

-2

8)тип по типу аналогично decltype из C++11.

decltype появился в С++ 09.

9)делегатам быть)

+1

11)foreach нужен.

+- 0. С одной стороны - полезен, с другой стороны - и без него можно обойтись.

14)нет указателям.

-10000000000000000000
После того как перешёл с Delphi на С++, вапше не понимаю как можно жить без указателей.

19)поддержка более удобного синтаксиса для RAII.

Ну, такое в шарпе тоже есть.

Всё остальное(синт.сахар и прочее) - мне кажется, лишнее.

Но это всего лишь моё ИМХО.

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

про препроцессор, можно хоть один аргумент его необходимости?
я и в С++ его не применяю.

-1(по типу шарпа делали?)

Delphi\Java\C#\etc, ибо не вижу в этом смысла.
плодить кучу VMT, и тп и тп.

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

decltype появился в С++ 09.

С++09=>C++0x=>C++11.

С одной стороны - полезен, с другой стороны - и без него можно обойтись.

код гораздо читабельнее становится.

После того как перешёл с Delphi на С++, вапше не понимаю как можно жить без указателей.

пишу на плюсах, отлично живу без них.(иногда лишь как замена ссылке, ибо в С++ ссылка обязана указывать на объект, нет понятия null ссылка)
зато вижу массу ошибок с указателями у других людей.

Ну, такое в шарпе тоже есть.

у меня то не шарп, потому я должен был перечислить это как часть синтаксиса.

Всё остальное(синт.сахар и прочее) - мне кажется, лишнее.

удобство написания и красивость кода не считаю сильно лишним.

[_-Re@l-_]

С++09=>C++0x=>C++11.

C++ 09 != C++0x

можно хоть один аргумент его необходимости?

Ну... а #include куда? #ifndef? #pragma once? Ну, скажем так: мне с ним удобно.

код гораздо читабельнее становится.

А мне кажется, наоборот. Нечитабельней.

пишу на плюсах, отлично живу без них.(иногда лишь как замена ссылке, ибо в С++ ссылка обязана указывать на объект, нет понятия null ссылка)
зато вижу массу ошибок с указателями у других людей.

А я вот не могу Мне просто необходима возможность самому полностью контролировать память.

P.S. Понимаю, что не смогу повлиять на то, что вы будете реализовывать в своём языке, поэтому скажу так: хозяин - барин.

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

Ну... а #include куда? #ifndef? #pragma once? Ну, скажем так: мне с ним удобно.

к черту инклюды, модульность должна быть нормальной.

А мне кажется, наоборот. Нечитабельней.

то есть по вашему

for(vector<int>::iterator  it=myvector.begin();it<myvector.end();it++ )
    cout << " " << *it;

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

foreach(int i in myvector)
    cout<<" "<<i;

куда читабельнее.

А я вот не могу Мне просто необходима возможность самому полностью контролировать память.

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

P.S. Понимаю, что не смогу повлиять на то, что вы будете реализовывать в своём языке, поэтому скажу так: хозяин - барин.

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

[Utkin]

Пепел Феникса, всем все равно не угодишь .

Мне просто необходима возможность самому полностью контролировать память.

Это мания. Лечить ее нужно. Таких задач, требующих явного контроля - раз и обчелся.

вапше не понимаю как можно жить без указателей.

Раньше как-то обходились же. Также как и сейчас многие обходятся. Это при том, что в Дельфи указатели тоже есть.

[netrino]

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

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

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

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

Не вижу смысла в п. 14, п. 18 и Обдумывание.п.2.

2_-Re@l-_, C++09 не существует. decltype официально принят в C++11. И да, препроцессор не нужен, можно покрыть весь его функционал модулями и чем-нибудь вроде D-го version или static if