возникла идея но конечно оно не нова но все таки, те кто в теме, расскажите что предпринималось и чем закончились вот такие идеи:
цель — сделать синтаксис С++ более приятным + добавить необходимые фичи без написания компилятора
т.е. создается причесанная версия С++ несовместимая с обычнм С++, без разделения на заголовки и спп, с нормальный неймспейсами, с метаданными и прочими упрощенияим, вплоть до довольно радикальных(я сделал бы чтобы для поинетра . означал -> по умолчанию)
но не создавать под это компилятор, а транслировать это в Си код, тогда любой другой код сможет использовать ваш код, потому что бинарная совместимость и можно будет легко сгенерировать заголовочные файлы
(метаданные кста не нада будет вкомпилировать намертво они легко могут быть частью рантайма)
ну и нада конечно прикрутить штуку котороая будет позвоялть подключать сторонние С/С++ либы к нашей среде, тут я пока не уверен что есть простой путь
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
K>возникла идея но конечно оно не нова но все таки, те кто в теме, расскажите что предпринималось и чем закончились вот такие идеи:
K>цель — сделать синтаксис С++ более приятным + добавить необходимые фичи без написания компилятора
Здравствуйте, Kingofastellarwar, Вы писали:
K>но не создавать под это компилятор, а транслировать это в Си код, тогда любой другой код сможет использовать ваш код, потому что бинарная совместимость и можно будет легко сгенерировать заголовочные файлы
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, Kingofastellarwar, Вы писали:
K>>но не создавать под это компилятор, а транслировать это в Си код, тогда любой другой код сможет использовать ваш код, потому что бинарная совместимость и можно будет легко сгенерировать заголовочные файлы
A>Си не нужен т.к. есть ллвм.
ллвм это хорошо, тока бинарную совметсимость оно обеспечит?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
А это все равно не дает возможности использовать С++ библиотеки.
Если использовать обертки — можно вызвать что угодно и из чего угодно, вопрос в затратах труда.
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.
Любопытный документ, надо будет изучить.
Я сам в режиме хобби неспешно разрабатываю свой язык программирования, так что мысли кое-какие есть.
Для начала — вот этот стиль "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" — да, это логично и красиво, и открывает возможности для расширений типа встраиваемых в код скриптов.
Здравствуйте, 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. Отказаться от ключевых слов. Все ключевые слова должны обрабатываться уже после синтаксического анализа.
Предлагаете избавиться от терминальных символов в грамматике, а как-же тогда делать синтаксический анализ?
Перекуём баги на фичи!
