Надеюсь эта тема переживёт прочтение модерации.... (это пролог)

Итак, предлагаю новичкам и середничкам объеденится в некое комьюнити для создание своего языка программирования и своего компилятора этого самого языка. Причём в целях этого проекта (а это в принципе проект) не лежит получение материальных благ, доказание всему миру своей крутости, не попытываться (блин) создать самоо лучшего в мире компилятора. А в чём же тогда смысл? Смысл есть, но о нём несколько похже. А суть проекта преследует несколько целей:

- углублённое осознание "что такое компилятор"
- приобретение навыка работы в команде
- приобретение навыков ведения большого проекта
- улучшение навыков программирования
- ну и просто приятное время препровождение

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

Теперь собственно о языке и компиляторе. Название ему пока придумывать не стоит, ведь ничего пока ещё не создано, для краткости навесим на него ярлык "свой". Язык изначально не подразумевается как эзотерический. Он должен отвечать неким требованиям (они подберутся, если проект не загнётся), быть вполне функционален, работоспособный. Что бы любой желающий мог сваять программу посложнее чем "Hello World!". В общем и целом думаю понятно.

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

UniBomb, а CVS - то у тя есть?

Sartorius, 

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

flex+byson+мануалы...
много документации по ASM-у, теории графов, формальных языков и грамматик...

Artemios, 





Тот же Турбо Паскаль не сразу седьмой версией вышел. Я же не говорил, что свой язык с первой версией будет достойный ответ всему существующему... Это я к тому, что начинать надо с малого, попутно накапливая эти самые "много документации по ASM-у, теории графов, формальных языков и грамматик...". Никто не говорил, что это будет легко. Никто не говорил, что всё будет сделано с первого раза, никто не говорил, что не нужно дополнительного багажа знаний. Да и потом я никого не принуждаю, тут все на личном желании и энтузиасме. А тот кто хочет, тот достанет нужный мануал, узнает что нужно, поймёт и запомнит. В этой затее ничего дурного нет, как нет и того, чего надо высмеивать. Да и во времени ничто не ограничивает...

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

Иванофф, 

Уже пошёл креатифф... Пошли дельные мысли... 




Проведение маркетинговых исследований - основная часть успеха. В принципе предметную облать можно взять самую широкую (эх, гулять так гулять) - от создания текстовых процессоров, до вполне солидных графических редакторов, от баз данных до программирования на уровне ядра ОС... Каждый может составить список отличий или новвоведений (т.н. фич) и, скажем, путём голосования оставить самые перспективные. Но опять таки повторюсь - цель проекта не создание панацеи от всех задач.



тут на самом деле более важно чем язык будет отличатся от остальных. Ведь основная задача компилятора - просто выполнять свою работу. А вот основные параметры приложений зависят от кода...

давайте делать компилятор для создания 3Д САПРов. Возьмем подмножество фортрана, добавим 3Д примитивы и структуры, добавим библиотеку по вводу-выводу, апи по интефейсам, вин апи + сервисные функции для 1Д-2Д-3Д. 

а что дальше?

Имхо. Язык должен придумывать один человек. Ибо иначе никогда не избавитесь от разногласий.



А зачем?


Убедился на своём опыте, что это всё лишний мусор. Если пишешь компилятор первый раз. Слишком много инфы, которая с трудом кладывается в голове и не даёт креативно мыслить. Писал свой первый basic-подобный интерпретатор, понятия не имея что такое графы и грамматики и прочее..... Хотя, не спорю, что вообще это нужные знания.

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

Иванофф, 



Действительно, зачем? Это уже не то... Это уже сборка, а не разработка... Намного интереснее разработать с нуля...


NightmareZ, 



Моё ИМХО - язык должны придумывать (хотя скорее разрабатывать) несколько человек. А выбирать наиболее удачные концепции - уже один человек. Это наиболее оптимальный вариант, т.к. один человек просто не в состоянии учесть особенности уже существующих языков - их прелести и недостатки. 



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

Kostt, 



Ну, что конкретно учить выяснится в процессе. Главное с чего начать...

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

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


Это сообщение отредактировал(а) regis - 21.12.2006, 10:48

Иванофф, 
regis, 


Почитайте повнимательней первый пост топика... Идея не в том, что бы создать какой-то супер пупер компилятор, который заткнёт cpp и c#. Этот проект должен стать первым опытом создания компиляторов. Хотя конечно хочется сделать самостоятельный и законченый продукт... 

Очередная агидинформация:

Грядут новогодние каникулы, у кого сессия, у кого выходные, а у кого просто есть свободное время. Предлагаю всем подумать над двумя вопросами - 

1) Чего не хватает современным ЯП?
2) Чего лишнего в современных ЯП?

Агидотдел закончил...

От себя могу добавить - язык будет универсальным. Т.е. не ограниченным одной сферой. Из нововведений есть желание реализовать редактор формул. Не знаю, есть такое в фортране или нет (если там нет, то и нигде нет), но смысл вот в чём - если есть какая-нить большущая дробь, которую надо запрограммировать - во всех ЯП вся дробь записывается в одну длиннющую строку, в которой подчас ничего не разобрать, следовательно это надо сделать более удобным - позволить записывать эту дробь в привычном виде - под числителем знаменатель, над знаменателем - числитель. В общем как редактор формул в ворде.

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

ЗЫ:. хорошо что хоть на этом этапе критики нет.... 

Это сообщение отредактировал(а) UniBomb - 22.12.2006, 01:25

Обычно, кто много возится с наборами формул (не в программировании, вообще математический текст) -- в конечном итоге большинство переходит от визуальных построителей (типа редактора формул в ворде) к системе LaTeX, где формулы как раз записываются в одну строчку набором комманд. Так что вопрос об удобстве WISIWIG построителей достаточно спорен, практика доказывает обратное.
А вообще, последнее предложение касается не языка, а IDE.


ну вот и критика )

Artemios, 



Ну в принципе да... Просто есть желание по максимуму организовать WYSIWYG по максимуму, но приэтом что бы было комфортно работать... Можно сделать поддержку обоих вариантов...

можно объединить две темы, тогда появиться хоть какая-то конкретика

"Компилятор для языка программирования Д"

все чаще на подобные вопросы
1) Чего не хватает современным ЯП?
2) Чего лишнего в современных ЯП?

появляются ответы

1) Чего не хватает современным ЯП?

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

2) Чего лишнего в современных ЯП?

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

Ух ты какая регулярная тема снова всплыла 


Я перечислю что бы хотел видеть, но это не значит что этого нет (Ruby например рулит почти по всему, что я назову).

Closures и некоторые другие вещи (ну и конечно фуннкции высшего порядка, что будет автоматом):

Функции и бы отдельно от closure's реализовать, для эффективности, всё таки не всегда контекст привязанный нужен.

Конечно интересны (мне  ) именнованные блоки, но их применение (а также вообще смысл) сомнительно:

Блоки могут сделать код похожим на "спагетти", т.к. это ограниченый аналг goto, но ИМХО очень удобно и при реализации с умом будет эффективней чем closure. Конечно же блоки это обьекты, но они не могут быть возвращеы как closure из функции.

Человеческие коллекции. Т.е. не всё под одну гребёнку, а возможность эффективно писать выбирая ArrayList (список на массиве), LinkedList (связанный список), LinkdHashMap (ассоциативный массив) и т.д. как в Java. Естественно подогнать это всё под удобный синтаксис, пример списка я дал в примере closure.

Конструкцию match как в Ocaml (спосоставление по типу). Это мощная вешь, с которй можно пойти дальше добавив операторы apply и pass. Конечно нужны тогда "жёсткие типы" (статическая типизация), что есть гуд. Также нужны алгебраические типы ну и прочее:

В паре слов не обьяснить конечно же, смотрим Ocaml и Haskell. Алгебраические типы позволят собирать какие угодно структуры, удобно в контейнерах и т.д. С помощью match + apply + pass можно проходить пол любым структурам (по деревьям идеально). Вообщем это очень круто 

Расширение компилятора с помощью core интерфейсов. Это такой более продвинутый аналог перегрузки операторов и т.п.:


Много... так долго можно продолжать 
В любом случае не нужно препроцессора, всё остальное по вкусу.

Простите за глупый вопрос, но чем блоки отличаются от dynamic-extent замыканий?

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

Но блок не функция, он не принимает никаких аргументов, а видит все переменные выше по контексту. Поэтому нельзя просто вызвать любой блок, а только те, что определены в текущем контексте(блоке) или выше. Внутри блока действуют break и continue, заставляющие соотвественно прыгнут в начало или в конец текущего блока (или "родительского" блока по имени).

Если предложить, что continue передаёт управление не блоку (он есть выражение), а на начало statement'а, то можно строить условия и циклы одним if'ом:

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

Как раз желательно определиться вот с этим: будет ли это просто учебный пример, или язык, ориентированный на практическое применение. И кстати: если уж речь идет о чисто учебном примере, то призывать других принимать в этом участие как-то нелогично (поскольку учится человек всегда сам ;) ).
Если же речь идет о практической разработке, то опять встает вопрос о конкретике, который я уже задавал. В наши дни "язык программирования" вообще -- настолько общее, неконкретное понятие, что это уже ничего не говорит.
Если хочется просто поразрабатывать что-нибудь системное (заодно приобрести не только знания, но и какую-то известность), то позволю себе чуть саморекламы: а вы с моим проектом (AWL) знакомы? Там творческим личностям пока есть много возможностей для приложения усилий (и, кстати, вполне реальный шанс прославиться).



Речь уже идет о какой-то интерактивной программе? Не совсем понял: если встал вопрос о редактировании, предполагается, что это некий диалговый инструмент, а не просто ЯП.



Честно говоря, здесь важнее концепция: синтаксис, в конце концов, дело наживное. 



Так пока что критиковать-то и нечего.   


Это сообщение отредактировал(а) regis - 25.12.2006, 12:40

Здесь возникло сразу несколько вопросов:



Кстати, недурной пример на использование замыканий. Но что, действительно существует браузер, поддерживающий Ruby вместо JS?



Так, как я понял, цикл foreach своему телу передает два параметра -- сам элемент коллекции и его номер?



Хмм-вроде это уже реализовано. Только синтаксис вот такой:


[/QUOTE]




Хмм, а не могли бы пояснить: в чем разница между всеми этими структурами данных? "Список на массиве", например?

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


Это сообщение отредактировал(а) regis - 25.12.2006, 13:41

К сожалению нет, но язык Ruby существует и является ИМХО очень мощной вещью. Правда я больше поклонник С подобного синтаксиса, но это мелочи 


Цикла нет вообще. В примере создаётся дефолтовая коллекция (список), у которого определён метод foreach. Как и любой метод он может принимать любые аргументы, но вот один специальный аргумент передаётся не как обычно (в "()"), а блоком за конструкцией и это всегда должен быть closure. Фича впервые увиденная мной в Ruby, по сути посто syntatic sugar, но как удобно!

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

Просто пример как это может реализоваться (выдуманный Java подобный язык):

Как видим блок/closure можно передать и в аргументах, но компилер нам просто предлагает более красивый синтаксис. Также это означает что каждый метод/функция принимают как минимум один аргумент - собственно сам блок. В окружении где есть общий тип и допустимо изменяемое количество аргументов это не проблема.

В примере кстати даны пара примеров как расширять синтаксис компилера без препроцессора (который сам по себе является чистым злом). Допустим LinkedList реализует некий интерфейс ArrayAccess, позволяющий к классу или к обьекту обращаться как к массиву, вызывая соответствующие методы. Также Closure может быть системным классом от Function, который релизует интерфейс Callable. Любой обьект реализующий Callable может быть вызван как функция (допустим вызывается метод call, навязываемый интерфейсом). Ну а наследовав от Closure или имплементировав интерфейс (допустим) Yieldable можно вести себя как closure и быть переданным в любую функцию как блок.

Возможно покажется немного мозгодробильно, но ИМХО это очень хороший подход к использованию полного синтаксиса компилера любым класом/обьектом.

Ну как, сделали компилятор?