возникла идея но конечно оно не нова но все таки, те кто в теме, расскажите что предпринималось и чем закончились вот такие идеи:

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

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

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

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

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

K>возникла идея но конечно оно не нова но все таки, те кто в теме, расскажите что предпринималось и чем закончились вот такие идеи:

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

Причесанный С++ называется D.

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

BE>Причесанный С++ называется D.

Только возможности использовать сторонние С++ библиотеки там ни хрена нет.

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

G>Только возможности использовать сторонние С++ библиотеки там ни хрена нет.

Через dll?

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

BE>Через dll?

Да хоть как. Невозможно. Только plain old C.

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

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

http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html

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

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

Си не нужен т.к. есть ллвм.

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

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

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

A>Си не нужен т.к. есть ллвм.

ллвм это хорошо, тока бинарную совметсимость оно обеспечит?

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

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

BE>>Через dll?

G>Да хоть как. Невозможно. Только plain old C.

Ну чего уж "только"... А как же COM IUnknown ? Вполне себе способ...
См. http://lunesu.com/uploads/ModernCOMProgramminginD.pdf
И "COM Interfaces" секцию в http://dlang.org/interface.html

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

CS>Ну чего уж "только"... А как же COM IUnknown ? Вполне себе способ...
CS>См. http://lunesu.com/uploads/ModernCOMProgramminginD.pdf
CS>И "COM Interfaces" секцию в http://dlang.org/interface.html

А это все равно не дает возможности использовать С++ библиотеки.
Если использовать обертки — можно вызвать что угодно и из чего угодно, вопрос в затратах труда.

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

Есть например такое:

MetaFun is a program to compile functional programs into C++ template metaprograms. It allows you to write programs in the very Haskell-like language Kiff (for Keep It Fun & Functional), and then use them as compile-time C++ metaprograms.

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

K>>цель — сделать синтаксис С++ более приятным + добавить необходимые фичи без написания компилятора
Q>http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html

Любопытный документ, надо будет изучить.
Я сам в режиме хобби неспешно разрабатываю свой язык программирования, так что мысли кое-какие есть.
Для начала — вот этот стиль "type RXBase : class" и "obj x: double" , который пихают сейчас во все языки... откуда это? Традиционный сишный синтаксис гораздо проще и удобнее. Зачем "type", "obj" (а также всевозможные var, val, let и т.д.), если по идентфикатору и так известно что это имя типа???
Единственное что я бы сделал — так это "func foo(int x, int y) int". Без всяких мусорных двоеточий и стрелочек, разумеется. Это нужно и для вывода типов (из-за чего похожую фичу ввели в c++11), и для удобства объявления вложенных функций, и еще для некоторых полезностей.

А вообще автор явно паскалист чего стоит только предложение заменить == на = и = на :=. Вообще, оператору := нашли прекрасное применение авторы Go — для объявления переменных с автоматическим выводом типа. Только вот можно было пойти еще дальше и разрешить применять его внутри выражений... побоялись наверное

Есть и хорошие идеи:
1. ctor/dtor для имен конструткоров (я бы сделал ctor/dtor ключевыми словами вместо "func", так чтобы можно было еще и давать конструкторам смысловые имена)
2. составные скобки для шаблонов (в действительности именно "составные скобки" не нужны, достаточно односимвольного маркера перед угловыми скобками, по которому парсер переключится из режима "больше/меньше" в режим "угловые скобки").
3. lang "asm" {} вместо "asm" и "extern c" — да, это логично и красиво, и открывает возможности для расширений типа встраиваемых в код скриптов.

Но вообще слабенько, многим вещам автор вообще не уделил внимания.

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

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

A>>Си не нужен т.к. есть ллвм.

K>ллвм это хорошо, тока бинарную совметсимость оно обеспечит?

чего с чем? если будешь везде генерировать одинаковые типы и сигнатуры — будет бинарная совместимость

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

NC>Для начала — вот этот стиль "type RXBase : class" и "obj x: double" , который пихают сейчас во все языки... откуда это? Традиционный сишный синтаксис гораздо проще и удобнее. Зачем "type", "obj" (а также всевозможные var, val, let и т.д.), если по идентфикатору и так известно что это имя типа???

традиционный синтаксис это чтоли где "int x" — переменная, а "int x()" — функция?

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

K>возникла идея но конечно оно не нова но все таки, те кто в теме, расскажите что предпринималось и чем закончились вот такие идеи:

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


А нахрена, собственно? Меня и так все устраивает.
Я считаю синтаксис С++ достаточно хорошим и приятным, а если хомячкам что-то не нравится — для вас придуман замечательный язык для программирования кофемолок — Джаба.

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

NC>Для начала — вот этот стиль "type RXBase : class" и "obj x: double" , который пихают сейчас во все языки... откуда это? Традиционный сишный синтаксис гораздо проще и удобнее. Зачем "type", "obj" (а также всевозможные var, val, let и т.д.), если по идентфикатору и так известно что это имя типа???

Во-первых, суффиксный стиль type-or-obj NewName : Type-Expression — как раз и является традиционным, ещё со времён алгола-60 (про -58 не скажу).
Во-вторых, инфиксный сишный стиль — контекстно-зависимый, чтобы его правильно распарсить и трактовать, требуется знать, какие имена уже определены и как они определены (являются типами, шаблонами типов, и т.д.)

Но у автора статьи, на мой вкус, эклектичненько получилось. Особенно с наследованием.

NC>Единственное что я бы сделал — так это "func foo(int x, int y) int". Без всяких мусорных двоеточий и стрелочек, разумеется. Это нужно и для вывода типов (из-за чего похожую фичу ввели в c++11), и для удобства объявления вложенных функций, и еще для некоторых полезностей.

Суффиксный алголо-паскалевский стиль объявления типов и переменных находится в соответствии с алголо-паскалевским стилем объявления функций.
Инфиксный сишный — с инфиксным сишным.
А здесь — предложение рассогласовать стили.

Замечу, что смешанный стиль auto function-name(arg-list) -> function-type одинадцатого стандарта — это компромиссное решение контекстно-зависимых проблем девяносто восьмого.

NC>А вообще автор явно паскалист чего стоит только предложение заменить == на = и = на :=. Вообще, оператору := нашли прекрасное применение авторы Go — для объявления переменных с автоматическим выводом типа. Только вот можно было пойти еще дальше и разрешить применять его внутри выражений... побоялись наверное

Чем плохо auto Var = ..... вместо Var := ..... ?
Ну, или в суффиксной нотации: Var : [auto|ConcreteType] = .....

Или тут дело в том, чтобы отличить инициализирующее присваивание (фактически, конструктор) от переприсваивания?

Var := init-value;
Var = new-value;
Var = another-value;

NC>Есть и хорошие идеи:
NC>1. ctor/dtor для имен конструткоров (я бы сделал ctor/dtor ключевыми словами вместо "func", так чтобы можно было еще и давать конструкторам смысловые имена)

А смысл давать конструкторам разные имена? А как это будет выглядеть в точке вызова?

Кстати, одно время MSVC понимал __ctor / __dtor.

NC>2. составные скобки для шаблонов (в действительности именно "составные скобки" не нужны, достаточно односимвольного маркера перед угловыми скобками, по которому парсер переключится из режима "больше/меньше" в режим "угловые скобки").

Да ну их нафиг, угловые скобки. Опять сделаем контекстно-зависимую грамматику, только контекст будет чуть проще: наличие маркера.
Если уж делать скобки, то нормальную пару.
Пусть хотя бы и [< ... >] — во-первых, никаких пересечений этих диграфов со случайными лигатурами в старом коде — если бы были [[ ... ]], например, то x[y[2]] стало бы неоднозначным.
Во-вторых, помимо мощного умного парсера в самом компиляторе, есть ещё парсеры в интеллисенсе, в редакторах, в препроцессоре. Чем ближе грамматика к операторной, хотя бы в первом приближении, тем лучше для них.

NC>3. lang "asm" {} вместо "asm" и "extern c" — да, это логично и красиво, и открывает возможности для расширений типа встраиваемых в код скриптов.

lang asm — это автор не видел gcc-шного стиля.

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

K>возникла идея но конечно оно не нова но все таки, те кто в теме, расскажите что предпринималось и чем закончились вот такие идеи:

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

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

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

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

Вообще глобально для языка программирования надо:

1. Разнести алгоритмы и типизацию. То есть пишется всегда шаблон, а типизируется этот шаблон в отдельном месте.
2. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа. Алгоритмы обработки ключевых слов должны быть доступны для переопределения пользователем, а не как сейчас — жестко прошиты в трансляторе.
3. Ну там по мелочи — функции объявлять без списка аргументов, а фактический список аргументов указывать в вызове.

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

P>Вообще глобально для языка программирования надо:
P>1. Разнести алгоритмы и типизацию. То есть пишется всегда шаблон, а типизируется этот шаблон в отдельном месте.

Для этого нужна система типов как у хаскелла. Даже обычного Хиндли-Милнера окажется недостаточно.
Либо уткина заводь.

P>2. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа. Алгоритмы обработки ключевых слов должны быть доступны для переопределения пользователем, а не как сейчас — жестко прошиты в трансляторе.

Форт. Там даже пробелы доступны для переопределения, если очень захотеть.
В крайнем случае, лисп — там жёстко прошиты только круглые скобки.

P>3. Ну там по мелочи — функции объявлять без списка аргументов, а фактический список аргументов указывать в вызове.

Однозначно, форт.

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

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

P>>Вообще глобально для языка программирования надо:
P>>1. Разнести алгоритмы и типизацию. То есть пишется всегда шаблон, а типизируется этот шаблон в отдельном месте.

К>Для этого нужна система типов как у хаскелла. Даже обычного Хиндли-Милнера окажется недостаточно.
К>Либо уткина заводь.

P>>2. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа. Алгоритмы обработки ключевых слов должны быть доступны для переопределения пользователем, а не как сейчас — жестко прошиты в трансляторе.

К>Форт. Там даже пробелы доступны для переопределения, если очень захотеть.
К>В крайнем случае, лисп — там жёстко прошиты только круглые скобки.

P>>3. Ну там по мелочи — функции объявлять без списка аргументов, а фактический список аргументов указывать в вызове.

К>Однозначно, форт.


10. Бывает нечто, о чем говорят: "смотри, вот это новое"; но это было уже в веках, бывших прежде нас.
...
18. И предал я сердце мое тому, чтобы познать мудрость и познать безумие и глупость: узнал, что и это — томление духа; потому что во многой мудрости много печали; и кто умножает познания, умножает
скорбь.

Я в том смысле, что от транслятора требуется только построить по тексту "программы" базу данных с именами.
Все остальное надо делать пользователю — указывать что в данный момент делать с данным именем. Трактовать ли имя как вызов функции, как имя структуры данных, проверить ли связи имени (ака наследник-потомок в терминах С++). Короче говоря — обработка синтаксически разобранного текста должна быть отделена от самого текста. Тогда все новое легко и непринужденно добавляется пользователем. А что понадобится полльзователю заранее неизвестно. Вот и надо дать инструмент.

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

P>2. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа.
Предлагаете избавиться от терминальных символов в грамматике, а как-же тогда делать синтаксический анализ?

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

O>А нахрена, собственно? Меня и так все устраивает.
O>Я считаю синтаксис С++ достаточно хорошим и приятным, а если хомячкам что-то не нравится — для вас придуман замечательный язык для программирования кофемолок — Джаба.

эти хомячки, которым не нравится синтаксис С++, сидят в WG21, а самого главного хомячка зовут Stroustrup.
если Вы считаете синтаксис С++ хорошим, то Вы просто не знаете С++.

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

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

P>>2. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа.
C>Предлагаете избавиться от терминальных символов в грамматике, а как-же тогда делать синтаксический анализ?

Так и делать. По именам разбор, а потом уже типизация.

описание что-то вроде:

start1

call start2

a=b+c

stop1

start2

d=e+f

stop2

в месте применения что-то вроде:

start1 stop1 in=b=c out=a a=b=c=int
start2 stop2 in=e=f out=d d=e=f=float
start2 stop2 in=f e=1 out=d d=e=f=long

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

P>1. Разнести алгоритмы и типизацию. То есть пишется всегда шаблон, а типизируется этот шаблон в отдельном месте.

С этим согласен, неплохо было бы. Но это нужно сделать очень красиво и удобно, чтобы не порождать писанину как в С++.
Возможно — просто ввести "метатипы", то есть кроме фиксированных типов ("int", "char" etc.) ввести некие обобщенные типы; код с такими типами автоматически превращается в шаблонный и при компиляции типизируется как будто это шаблон. А использовать их наравне с обычными, без всяких "template" и прочего словесного мусора.

P>2. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа. Алгоритмы обработки ключевых слов должны быть доступны для переопределения пользователем, а не как сейчас — жестко прошиты в трансляторе.

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

P>3. Ну там по мелочи — функции объявлять без списка аргументов, а фактический список аргументов указывать в вызове.

Объявлять где? Непонятно что вы имеете в виду

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

P>1. Разнести алгоритмы и типизацию. То есть пишется всегда шаблон, а типизируется этот шаблон в отдельном месте.
P>2. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа. Алгоритмы обработки ключевых слов должны быть доступны для переопределения пользователем, а не как сейчас — жестко прошиты в трансляторе.
P>3. Ну там по мелочи — функции объявлять без списка аргументов, а фактический список аргументов указывать в вызове.

1. ну и нафига? где шаблоны используется? контейнеры, фукторы/сигналы иииии еще пара мелочей
зачем шаблоны ставить во главу угла куда ни попадя если на практике они нужны для 0.5% кода?

и вообще их парктически не использую и не вижу особой выгоды от тех шаблонных извратов которые тут на рсдн обсуждаются

3. а ну пример плз шо это такое(помнится в инсте нам про такой друний язык рассказыали в плане того что ракета из за этого упала ибо забыли параметр передать а проверки не было)


вообще академиков-теоретиков при создании языков нужно использовать по-минимуму

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

call start2

В этом фрагменте call это ключевое слово или нет?

start1 stop1 in=b=c out=a a=b=c=int

В этом фрагменте in, out это ключевые слова или нет?

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

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

C>

C>call start2
C>

C>В этом фрагменте call это ключевое слово или нет?

C>

C>start1 stop1 in=b=c out=a a=b=c=int
C>

C>В этом фрагменте in, out это ключевые слова или нет?

в идеале нет
в идеале in out call int обрабатываются уже на этапе разобраного дерева
но это просто фантазии на тему, может быть и не получится обойтись без ключевых слов

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

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

P>>1. Разнести алгоритмы и типизацию. То есть пишется всегда шаблон, а типизируется этот шаблон в отдельном месте.
P>>2. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа. Алгоритмы обработки ключевых слов должны быть доступны для переопределения пользователем, а не как сейчас — жестко прошиты в трансляторе.
P>>3. Ну там по мелочи — функции объявлять без списка аргументов, а фактический список аргументов указывать в вызове.

K>1. ну и нафига? где шаблоны используется? контейнеры, фукторы/сигналы иииии еще пара мелочей
K>зачем шаблоны ставить во главу угла куда ни попадя если на практике они нужны для 0.5% кода?

бросить все и уехать в Урюпинск...

K>и вообще их парктически не использую и не вижу особой выгоды от тех шаблонных извратов которые тут на рсдн обсуждаются

секс это неинтересно, я читала (С) Валерия Новодворская

K>3. а ну пример плз шо это такое(помнится в инсте нам про такой друний язык рассказыали в плане того что ракета из за этого упала ибо забыли параметр передать а проверки не было)

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

K>вообще академиков-теоретиков при создании языков нужно использовать по-минимуму

бей профессоров, они гадюки...

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

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

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

P>>>1. Разнести алгоритмы и типизацию. То есть пишется всегда шаблон, а типизируется этот шаблон в отдельном месте.
P>>>2. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа. Алгоритмы обработки ключевых слов должны быть доступны для переопределения пользователем, а не как сейчас — жестко прошиты в трансляторе.
P>>>3. Ну там по мелочи — функции объявлять без списка аргументов, а фактический список аргументов указывать в вызове.

K>>1. ну и нафига? где шаблоны используется? контейнеры, фукторы/сигналы иииии еще пара мелочей
K>>зачем шаблоны ставить во главу угла куда ни попадя если на практике они нужны для 0.5% кода?

P>бросить все и уехать в Урюпинск...

K>>и вообще их парктически не использую и не вижу особой выгоды от тех шаблонных извратов которые тут на рсдн обсуждаются

P>секс это неинтересно, я читала (С) Валерия Новодворская

K>>3. а ну пример плз шо это такое(помнится в инсте нам про такой друний язык рассказыали в плане того что ракета из за этого упала ибо забыли параметр передать а проверки не было)

P>У нас тоже был похожий случай. Бабка с двенадцатого этажа упала. Сама вдребезги, а галоши целы...

K>>вообще академиков-теоретиков при создании языков нужно использовать по-минимуму

P>бей профессоров, они гадюки...

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

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

ну не беда
отрицательный результат в науке это тоже результат

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

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

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

C>>

C>>call start2
C>>

C>>В этом фрагменте call это ключевое слово или нет?

C>>

C>>start1 stop1 in=b=c out=a a=b=c=int
C>>

C>>В этом фрагменте in, out это ключевые слова или нет?

P>в идеале нет
P>в идеале in out call int обрабатываются уже на этапе разобраного дерева
P>но это просто фантазии на тему, может быть и не получится обойтись без ключевых слов

И, да, даже если in out call int это ключевые слова, то они не в тексте собственно алгоритма.
Собственно текст алгоритма свободен от ключевых слов.
А инстанцирование шаблонов должно происходить в другом файле.

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

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

O>>А нахрена, собственно? Меня и так все устраивает.
O>>Я считаю синтаксис С++ достаточно хорошим и приятным, а если хомячкам что-то не нравится — для вас придуман замечательный язык для программирования кофемолок — Джаба.

A>эти хомячки, которым не нравится синтаксис С++, сидят в WG21, а самого главного хомячка зовут Stroustrup.
A>если Вы считаете синтаксис С++ хорошим, то Вы просто не знаете С++.

Да ну? Удивительно. Чего я еще не знаю?

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

A>>эти хомячки, которым не нравится синтаксис С++, сидят в WG21, а самого главного хомячка зовут Stroustrup.
A>>если Вы считаете синтаксис С++ хорошим, то Вы просто не знаете С++.

O>Да ну? Удивительно. Чего я еще не знаю?
что именно для Вас удивительно? то что есть С++11 потому что в С++03 была куча проблем с синтаксисом, и что сейчас делают С++14 потому что С++11 тоже не достаточно хорош?

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

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

A>>>эти хомячки, которым не нравится синтаксис С++, сидят в WG21, а самого главного хомячка зовут Stroustrup.
A>>>если Вы считаете синтаксис С++ хорошим, то Вы просто не знаете С++.

O>>Да ну? Удивительно. Чего я еще не знаю?
A>что именно для Вас удивительно? то что есть С++11 потому что в С++03 была куча проблем с синтаксисом, и что сейчас делают С++14 потому что С++11 тоже не достаточно хорош?

чем Страуструп отличается от кота?
когда Страуструпу нечего делать, он полирует синтаксис С++

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

A>традиционный синтаксис это чтоли где "int x" — переменная, а "int x()" — функция?

А int x(1) — опять переменная.

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

P>

P>start1
P>call start2
P>a=b+c
P>stop1
P>start2
P>d=e+f
P>stop2
P>

P>в месте применения что-то вроде:
P>

P>start1 stop1 in=b=c out=a a=b=c=int
P>start2 stop2 in=e=f out=d d=e=f=float
P>start2 stop2 in=f e=1 out=d d=e=f=long
P>

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

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

G>А это все равно не дает возможности использовать С++ библиотеки.

А С++ сам себе тоже не дает возможности использовать С++ библиотеки.
Даже две static lib с разной memory/runtime model не линкуются вместе. Что уж говорить про остальное.

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

NC>Для начала — вот этот стиль... "x: double" , который пихают сейчас во все языки... откуда это?

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

NC> Традиционный сишный синтаксис гораздо проще и удобнее.

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

NC>Зачем "type", "obj" (а также всевозможные var, val, let и т.д.), если по идентфикатору и так известно что это имя типа???

Классический пример неоднозначности грамматики Си, требующий контекста:

a * b;

Это выражение умножения; или объявление переменной b типа указатель на a?
Или в C++:

a b(c);

Это определение переменной b типа a, инициализируемой c; или объявление функции b, принимающей c, и возвращающей a?

NC>А вообще автор явно паскалист:) чего стоит только предложение заменить == на = и = на :=.

Опять же, традиционный синтаксис.

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

O>Да ну? Удивительно. Чего я еще не знаю?

По какой причине в некоторых случаях язык C++ обязывает использовать слово ключевое `template` в качестве квалификатора?

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

A>если Вы считаете синтаксис С++ хорошим, то Вы просто не знаете С++.

Я бы не рискнул брать на должность C++-программиста человека, который считает синтаксис C++ хорошим.

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

Q>Я бы не рискнул брать на должность C++-программиста человека, который считает синтаксис C++ хорошим.

Ну, я считаю синтаксис С++ хорошим... потому что видал плохие синтаксисы.
Уж во всяком случае, не настолько он плох, чтоб всё вдребезги взять и разломать.
Да, компилятору тяжело приходится.
Но, если не ставить себе задачу обфускации, то вполне можно писать сколь угодно сложные и сколь угодно ясные программы.
А обфускацию хоть на языке Ада сделать нетрудно.

С++ не ограничивает пользователя синтаксисом. Только в некоторых случаях заставляет быть чуть многословнее, чем хотелось бы: template typename всякие и лишние скобки в определениях переменных и в макросах.

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

К>Ну, я считаю синтаксис С++ хорошим... потому что видал плохие синтаксисы.

Так ты не на плохие, ты на хорошие синтаксисы смотри.

К>Уж во всяком случае, не настолько он плох, чтоб всё вдребезги взять и разломать.

Я не говорю про разломать. Я говорю про осознавать его проблемы, в контексте фразы: «Я считаю синтаксис С++ достаточно хорошим и приятным, а если хомячкам что-то не нравится — для вас придуман замечательный язык для программирования кофемолок — Джаба». Если человек не осознаёт проблемы и уродство C++, значит, у него недостаток критического восприятия и здорового скепсиса. Это повод для тревоги со стороны работодателя — вероятно, сотрудник не будет воспринимать и критику своего кода, как он не способен осознать пороки своего любимого языка. Решит: да вы убогие хомячки и вебдевелоперы, куда вам тут понять мои творения на величайшем из языков.

И ещё добавит что-нибудь про кофемолки и «джабу».

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

Q>Так ты не на плохие, ты на хорошие синтаксисы смотри.

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

К>>Уж во всяком случае, не настолько он плох, чтоб всё вдребезги взять и разломать.

Q>Я не говорю про разломать. Я говорю про осознавать его проблемы, в контексте фразы: «Я считаю синтаксис С++ достаточно хорошим и приятным, а если хомячкам что-то не нравится — для вас придуман замечательный язык для программирования кофемолок — Джаба». Если человек не осознаёт проблемы и уродство C++, значит, у него недостаток критического восприятия и здорового скепсиса. Это повод для тревоги со стороны работодателя — вероятно, сотрудник не будет воспринимать и критику своего кода, как он не способен осознать пороки своего любимого языка. Решит: да вы убогие хомячки и вебдевелоперы, куда вам тут понять мои творения на величайшем из языков.

А недостаток здорового пофигизма?

Я, как ты понимаешь, прекрасно осознаю проблемы, уродства и пороки. Но С++ — это мои кресты, и нести их буду Я!
Кроме всего прочего, у С++ есть и плюсы, которые не исчерпываются синтаксисом.

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

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

К>Мне вот языки с табуляцией чисто эстетически нравятся. Хоть питон, хоть хаскелл. (Впрочем, и там, и там от табуляции возникают проблемы).

Хорошие, да. А как насчёт Scala, например? (Пользуясь случаем, напомню, что скоро на Coursera курс Эрички Мейера и Мартина Одерского; всем быть.)

К>Я, как ты понимаешь, прекрасно осознаю проблемы, уродства и пороки. Но С++ — это мои кресты, и нести их буду Я!

Так ведь и у меня тоже по отношению к C++ Стокгольмский синдром.

К>Кроме всего прочего, у С++ есть и плюсы, которые не исчерпываются синтаксисом.

Плюсы C++ к его синтаксису не имеют никакого отношения. Не благодаря, а вопреки.

К>Черчилль, кажется, говорил: плох тот, кто в молодости не был революционером, и кто в зрелости не стал консерватором.

Всё правильно сказал.

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

К>Черчилль, кажется, говорил: плох тот, кто в молодости не был революционером, и кто в зрелости не стал консерватором.

Тут в жежешечке проскакивал пруфлинк, что всё обман, Черчилль такого сказать не мог, и вообще был консерватором в 15, и стал либералом в 35.

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

Q>Если человек не осознаёт проблемы и уродство C++, значит, у него недостаток критического восприятия и здорового скепсиса. Это повод для тревоги со стороны работодателя — вероятно, сотрудник не будет воспринимать и критику своего кода, как он не способен осознать пороки своего любимого языка. Решит: да вы убогие хомячки и вебдевелоперы, куда вам тут понять мои творения на величайшем из языков.

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

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

O>Повод для тревоги со стороны работодателя — если у программиста не хватает мозгов, чтобы выучить разницу между операторами . и ->
O>Причем настолько не хватает, что этот "программист" начинает вопить на форумах про плохой синтаксис. Вот это действительно повод для тревоги.

Есть объективный факт (не зависящий от субъекта восприятия): операторы . и -> отличаются. Но есть субъекты, которые этого не понимают. Согласен, это повод отказать соискателю в должности программиста C++.
Другой объективный факт (также не зависящий от субъекта восприятия): синтаксис C++ ущербен. Опять же есть субъекты, которые этого не понимают. И это тоже повод отказать соискателю в должности программиста C++.

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

Q>синтаксис C++ ущербен. Опять же есть субъекты, которые этого не понимают. И это тоже повод отказать соискателю в должности программиста C++.
а разве кому-то может быть нужен программист, считающий свой основной инструмент ущербным?

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

Q>Другой объективный факт (также не зависящий от субъекта восприятия): синтаксис C++ ущербен.

Плохому танцору... сам знаешь. Объективный ли? И в чем его ущербность? Мне лично эта "ущербность" никак не мешает.

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

мы хотим поправить в с++ некоторые вещи, и если кто-то хочет убедить нас в том что нам не нада этого хотеть, то максимум чего он достигнет это срача и нулевых результатов по факту

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

K>мы хотим поправить в с++ некоторые вещи, и если кто-то хочет убедить нас в том что нам не нада этого хотеть, то максимум чего он достигнет это срача и нулевых результатов по факту

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

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

O>>Да ну? Удивительно. Чего я еще не знаю?
A>что именно для Вас удивительно? то что есть С++11 потому что в С++03 была куча проблем с синтаксисом, и что сейчас делают С++14 потому что С++11 тоже не достаточно хорош?

А ты уверен, что С++11 появился только из-за проблем с синтаксисом?

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

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

K>>мы хотим поправить в с++ некоторые вещи, и если кто-то хочет убедить нас в том что нам не нада этого хотеть, то максимум чего он достигнет это срача и нулевых результатов по факту

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

нам, я прям щас готов бросить все и перейти на причесаный с++

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

O>>>Да ну? Удивительно. Чего я еще не знаю?
A>>что именно для Вас удивительно? то что есть С++11 потому что в С++03 была куча проблем с синтаксисом, и что сейчас делают С++14 потому что С++11 тоже не достаточно хорош?

O>А ты уверен, что С++11 появился только из-за проблем с синтаксисом?

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

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

Q>Другой объективный факт (также не зависящий от субъекта восприятия): синтаксис C++ ущербен.

А где вы видели нормальный синтаксис? Нормальный, это такой, где, например, присваивание записывается так: "a <- b" или так "a <= b". Присваивание — это перенос значения из одной ячейки памяти в другую ячейку. Причём тут знак '=' или ':=' ? Получается, что все языки, которые явно не выражают эту простую мысль — ущербны. Согласны?

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

BFE>Присваивание — это перенос значения из одной ячейки памяти в другую ячейку.
нет. копирование а не перенос. для ячеек памяти.

В С++ кроме copy-assignment есть еще и move-assignment. а еще есть просто инициализация нового объекта.

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

K>нам, я прям щас готов бросить все и перейти на причесаный с++

А кто-то еще?

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

A>кроме изменения синтаксиса есть еще процесс добавления библиотек, в основном из буста, но основные изменения происходят именно в синтаксисе.
A>то же добавление enable_if_t стало возможным только после внедрения template aliases.

Синтакс является следствием изменений в семантике.
Например, вывод типа переменной потребовал какую-то новую конструкцию; комитет решил не придумывать новые ключевые слова, а переосмыслил слово auto.
Лямбды — так вообще придумали чёрте-что из спецсимволов.
(Такое впечатление, что лексер — это самая нежная любовь комитетчиков, ради которой можно издеваться над парсером).

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

Кстати, по мотивам лямбд — можно и шаблоны функций делать

template<class T, class U, class V> void foo(T t, U u, V v) { ..... }
void foo(auto t, auto u, auto v) { ..... }

template<class T, class U> void foo(T t, U u, T v) { ..... }
template<class T> void foo(T t, auto u, T v) { ..... }

не знаю, ожидается ли в С++1х.

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

A>>кроме изменения синтаксиса есть еще процесс добавления библиотек, в основном из буста, но основные изменения происходят именно в синтаксисе.
A>>то же добавление enable_if_t стало возможным только после внедрения template aliases.

К>Синтакс является следствием изменений в семантике.
К>Например, вывод типа переменной потребовал какую-то новую конструкцию; комитет решил не придумывать новые ключевые слова, а переосмыслил слово auto.
К>Лямбды — так вообще придумали чёрте-что из спецсимволов.
К>(Такое впечатление, что лексер — это самая нежная любовь комитетчиков, ради которой можно издеваться над парсером).

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

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

P>Вообще глобально для языка программирования надо:
P>1. Разнести алгоритмы и типизацию. То есть пишется всегда шаблон, а типизируется этот шаблон в отдельном месте.

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

P>2. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа. Алгоритмы обработки ключевых слов должны быть доступны для переопределения пользователем, а не как сейчас — жестко прошиты в трансляторе.

Prolog? Там их вообще нет и поэтому пишут на нём три с половиной упоротых. При чём тут C++ и индустрия?

P>3. Ну там по мелочи — функции объявлять без списка аргументов, а фактический список аргументов указывать в вызове.

А компилятору вы предлагаете смотреть все единицы трансляции, чтобы разложить по стеку аргументы? А если нужно собрать библиотеку в объектник -- уже нельзя?

Мне кажется, я сейчас кормил тролля ((

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

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

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

Здравствуйте, 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#.