| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Технологии: Разные > Создание компилятора |
| Автор: UniBomb 18.12.2006, 18:46 |
| Надеюсь эта тема переживёт прочтение модерации.... (это пролог) Итак, предлагаю новичкам и середничкам объеденится в некое комьюнити для создание своего языка программирования и своего компилятора этого самого языка. Причём в целях этого проекта (а это в принципе проект) не лежит получение материальных благ, доказание всему миру своей крутости, не попытываться (блин) создать самоо лучшего в мире компилятора. А в чём же тогда смысл? Смысл есть, но о нём несколько похже. А суть проекта преследует несколько целей: - углублённое осознание "что такое компилятор" - приобретение навыка работы в команде - приобретение навыков ведения большого проекта - улучшение навыков программирования - ну и просто приятное время препровождение Это основные цели, которые лежат на поверхности, но каждый может поставить перед собой отдельные цели. А самое главное, что это проект позволит накопить столь драгоценный опыт быстрее, чем набивание однотипных программ, с разницей в пару функций. Теперь собственно о языке и компиляторе. Название ему пока придумывать не стоит, ведь ничего пока ещё не создано, для краткости навесим на него ярлык "свой". Язык изначально не подразумевается как http://ru.wikipedia.org/wiki/Эзотерический_язык_программирования. Он должен отвечать неким требованиям (они подберутся, если проект не загнётся), быть вполне функционален, работоспособный. Что бы любой желающий мог сваять программу посложнее чем "Hello World!". В общем и целом думаю понятно. (на правах постскриптма) : если тема не выживет посещения модерации, но желающие появятся - стучитесь ко мне в личку... |
| Автор: Sartorius 18.12.2006, 18:50 |
| UniBomb, а CVS - то у тя есть? |
| Автор: UniBomb 18.12.2006, 18:52 |
| Sartorius, если бы я знал что это... скорее всего нет... |
| Автор: Artemios 18.12.2006, 22:56 |
| flex+byson+мануалы... много документации по ASM-у, теории графов, формальных языков и грамматик... |
| Автор: UniBomb 18.12.2006, 23:51 | ||||
Artemios,
Тот же Турбо Паскаль не сразу седьмой версией вышел. Я же не говорил, что свой язык с первой версией будет достойный ответ всему существующему... Это я к тому, что начинать надо с малого, попутно накапливая эти самые "много документации по ASM-у, теории графов, формальных языков и грамматик...". Никто не говорил, что это будет легко. Никто не говорил, что всё будет сделано с первого раза, никто не говорил, что не нужно дополнительного багажа знаний. Да и потом я никого не принуждаю, тут все на личном желании и энтузиасме. А тот кто хочет, тот достанет нужный мануал, узнает что нужно, поймёт и запомнит. В этой затее ничего дурного нет, как нет и того, чего надо высмеивать. Да и во времени ничто не ограничивает... |
| Автор: Иванофф 19.12.2006, 00:57 | ||
наверно нужно определить предметную область, рассмотреть сушествуюшие решения, наметить чем новый компилятор будет лучше или хотябы чем будет отличаться. в бесплатно бездежной форме такой проект врядли будет жить. |
| Автор: UniBomb 19.12.2006, 01:10 | ||||
| Иванофф, Уже пошёл креатифф... Пошли дельные мысли...
Проведение маркетинговых исследований - основная часть успеха. В принципе предметную облать можно взять самую широкую (эх, гулять так гулять) - от создания текстовых процессоров, до вполне солидных графических редакторов, от баз данных до программирования на уровне ядра ОС... Каждый может составить список отличий или новвоведений (т.н. фич) и, скажем, путём голосования оставить самые перспективные. Но опять таки повторюсь - цель проекта не создание панацеи от всех задач.
тут на самом деле более важно чем язык будет отличатся от остальных. Ведь основная задача компилятора - просто выполнять свою работу. А вот основные параметры приложений зависят от кода... |
| Автор: Иванофф 20.12.2006, 01:32 |
| давайте делать компилятор для создания 3Д САПРов. Возьмем подмножество фортрана, добавим 3Д примитивы и структуры, добавим библиотеку по вводу-выводу, апи по интефейсам, вин апи + сервисные функции для 1Д-2Д-3Д. а что дальше? |
| Автор: Kostt 20.12.2006, 08:06 |
| А у нас в универе преподавали теорию компиляторов, задание было - написать свой интерпретатор с функциональностью примерно паскаля. Теорию нужно учить, но хорошо, когда знаешь, что конкретно учить |
| Автор: UniBomb 20.12.2006, 17:47 | ||||||||
Иванофф,
Действительно, зачем? Это уже не то... Это уже сборка, а не разработка... Намного интереснее разработать с нуля... NightmareZ,
Моё ИМХО - язык должны придумывать (хотя скорее разрабатывать) несколько человек. А выбирать наиболее удачные концепции - уже один человек. Это наиболее оптимальный вариант, т.к. один человек просто не в состоянии учесть особенности уже существующих языков - их прелести и недостатки.
Тоже в принципе дельная мысль. Можно начать с простого линейного интерпретатора и постепенно его усложнять. Тем более как я понял из http://www.sbin.org/doc/jargon/D/Dragon-Book.html, существует не так много способов создания компиляторов и соответсвенно не придётся изобретать велосипед идя по протоптанной дороге лишь иногда меняя путь... Kostt,
Ну, что конкретно учить выяснится в процессе. Главное с чего начать... |
| Автор: Иванофф 21.12.2006, 01:55 |
| зачем писать компилятор с привязкой к предметной области? в таком виде он хоть кому-то понадобиться. если будете писать компилятор под фортран, паскаль, си и т.д. или язык с близкой функциональностью, то потребителей (помимо разработчиков) не будет. |
| Автор: regis 21.12.2006, 10:47 |
| Прежде, чем создавать язык, необходимо определить, для чего он собственно нужен. Это поможет определиться с другими принципиальными вопросами: например, идеология реализации (чистый компилятор, компилятор в машинно-независимый байт-код, интерпретатор и пр.) И пока, честно, говоря, я просто не вижу здесь интересных и оригинальных идей. На мой взгляд, чтобы начать что-то разрабатывать, хотя бы пара таких идей должна быть. |
| Автор: UniBomb 22.12.2006, 01:23 |
| Иванофф, regis, Почитайте повнимательней первый пост топика... Идея не в том, что бы создать какой-то супер пупер компилятор, который заткнёт cpp и c#. Этот проект должен стать первым опытом создания компиляторов. Хотя конечно хочется сделать самостоятельный и законченый продукт... Очередная агидинформация: Грядут новогодние каникулы, у кого сессия, у кого выходные, а у кого просто есть свободное время. Предлагаю всем подумать над двумя вопросами - 1) Чего не хватает современным ЯП? 2) Чего лишнего в современных ЯП? Агидотдел закончил... От себя могу добавить - язык будет универсальным. Т.е. не ограниченным одной сферой. Из нововведений есть желание реализовать редактор формул. Не знаю, есть такое в фортране или нет (если там нет, то и нигде нет), но смысл вот в чём - если есть какая-нить большущая дробь, которую надо запрограммировать - во всех ЯП вся дробь записывается в одну длиннющую строку, в которой подчас ничего не разобрать, следовательно это надо сделать более удобным - позволить записывать эту дробь в привычном виде - под числителем знаменатель, над знаменателем - числитель. В общем как редактор формул в ворде. ЗЫ:. в течении двух недель порбую выработать концепцию языка и разработать его синтаксис - так что думайте, чего надо критиковать в первую очередь... ЗЫ:. хорошо что хоть на этом этапе критики нет.... |
| Автор: Artemios 22.12.2006, 15:40 | ||
Обычно, кто много возится с наборами формул (не в программировании, вообще математический текст) -- в конечном итоге большинство переходит от визуальных построителей (типа редактора формул в ворде) к системе LaTeX, где формулы как раз записываются в одну строчку набором комманд. Так что вопрос об удобстве WISIWIG построителей достаточно спорен, практика доказывает обратное. А вообще, последнее предложение касается не языка, а IDE. ну вот и критика |
| Автор: UniBomb 22.12.2006, 18:10 | ||
Artemios,
Ну в принципе да... Просто есть желание по максимуму организовать WYSIWYG по максимуму, но приэтом что бы было комфортно работать... Можно сделать поддержку обоих вариантов... |
| Автор: Иванофф 23.12.2006, 02:23 | ||
можно объединить две темы, тогда появиться хоть какая-то конкретика "Компилятор для языка программирования Д" все чаще на подобные вопросы 1) Чего не хватает современным ЯП? 2) Чего лишнего в современных ЯП? появляются ответы 1) Чего не хватает современным ЯП? программистов, которые могут изучить язык и сделать более-менее готовую коммерческую программу. 2) Чего лишнего в современных ЯП? программисты, которые не могут доделать программы до того уровня, чтобы пользователи могли ими пользоваться. |
| Автор: Sardar 23.12.2006, 04:28 | ||||||||||
Ух ты какая регулярная тема снова всплыла
Я перечислю что бы хотел видеть, но это не значит что этого нет (Ruby например рулит почти по всему, что я назову). Closures и некоторые другие вещи (ну и конечно http://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F_%D0%B2%D1%8B%D1%81%D1%88%D0%B5%D0%B3%D0%BE_%D0%BF%D0%BE%D1%80%D1%8F%D0%B4%D0%BA%D0%B0, что будет автоматом):
Функции и бы отдельно от closure's реализовать, для эффективности, всё таки не всегда контекст привязанный нужен. Конечно интересны (мне
Блоки могут сделать код похожим на "спагетти", т.к. это ограниченый аналг goto, но ИМХО очень удобно и при реализации с умом будет эффективней чем closure. Конечно же блоки это обьекты, но они не могут быть возвращеы как closure из функции. Человеческие коллекции. Т.е. не всё под одну гребёнку, а возможность эффективно писать выбирая ArrayList (список на массиве), LinkedList (связанный список), LinkdHashMap (ассоциативный массив) и т.д. как в Java. Естественно подогнать это всё под удобный синтаксис, пример списка я дал в примере closure. Конструкцию match как в Ocaml (спосоставление по типу). Это мощная вешь, с которй можно пойти дальше добавив операторы apply и pass. Конечно нужны тогда "жёсткие типы" (http://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D1%82%D0%B8%D0%BF%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F), что есть гуд. Также нужны http://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%B5%D0%B1%D1%80%D0%B0%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D1%82%D0%B8%D0%BF_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 ну и прочее:
В паре слов не обьяснить конечно же, смотрим Ocaml и Haskell. Алгебраические типы позволят собирать какие угодно структуры, удобно в контейнерах и т.д. С помощью match + apply + pass можно проходить пол любым структурам (по деревьям идеально). Вообщем это очень круто Расширение компилятора с помощью core интерфейсов. Это такой более продвинутый аналог перегрузки операторов и т.п.:
Много... так долго можно продолжать В любом случае не нужно препроцессора, всё остальное по вкусу. |
| Автор: adejneka 23.12.2006, 14:10 |
| Простите за глупый вопрос, но чем блоки отличаются от dynamic-extent замыканий? |
| Автор: Sardar 23.12.2006, 16:54 | ||
| adejneka, возможно тем что к значениям переменных не имеет никакого отношения, т.е. переменные связываються статично со своим значением и не могут быть редекларированны в блоке ниже. Блоки что я предложил есть ничто иное чем "безопасный" goto или "функция в функции". Блок можно вызвывать снова и снова, строя например рекурсию внутри конкретной функции, это как приватные функции, не видимые вне функции/метода. Но блок не функция, он не принимает никаких аргументов, а видит все переменные выше по контексту. Поэтому нельзя просто вызвать любой блок, а только те, что определены в текущем контексте(блоке) или выше. Внутри блока действуют break и continue, заставляющие соотвественно прыгнут в начало или в конец текущего блока (или "родительского" блока по имени). Если предложить, что continue передаёт управление не блоку (он есть выражение), а на начало statement'а, то можно строить условия и циклы одним if'ом:
От такого код будет менее читабелен, но можно будет писать без дублирования участков кода, что облегчит не только работу оптимизатора, но и даст морально-эстетическое наслаждение программисту |
| Автор: regis 25.12.2006, 12:38 | ||||||||
Как раз желательно определиться вот с этим: будет ли это просто учебный пример, или язык, ориентированный на практическое применение. И кстати: если уж речь идет о чисто учебном примере, то призывать других принимать в этом участие как-то нелогично (поскольку учится человек всегда сам ;) ). Если же речь идет о практической разработке, то опять встает вопрос о конкретике, который я уже задавал. В наши дни "язык программирования" вообще -- настолько общее, неконкретное понятие, что это уже ничего не говорит. Если хочется просто поразрабатывать что-нибудь системное (заодно приобрести не только знания, но и какую-то известность), то позволю себе чуть саморекламы: а вы с моим проектом (AWL) знакомы? Там творческим личностям пока есть много возможностей для приложения усилий (и, кстати, вполне реальный шанс прославиться).
Речь уже идет о какой-то интерактивной программе? Не совсем понял: если встал вопрос о редактировании, предполагается, что это некий диалговый инструмент, а не просто ЯП.
Честно говоря, здесь важнее концепция: синтаксис, в конце концов, дело наживное.
Так пока что критиковать-то и нечего. |
| Автор: regis 25.12.2006, 13:38 | ||||||||||||||||
Здесь возникло сразу несколько вопросов:
Кстати, недурной пример на использование замыканий. Но что, действительно существует браузер, поддерживающий Ruby вместо JS?
Так, как я понял, цикл foreach своему телу передает два параметра -- сам элемент коллекции и его номер?
Хмм-вроде это уже реализовано. Только синтаксис вот такой:
[/QUOTE]
Хмм, а не могли бы пояснить: в чем разница между всеми этими структурами данных? "Список на массиве", например? А вообще, спасибо, идеи весьма интересные. Над некоторыми явно стоит подумать. |
| Автор: Sardar 25.12.2006, 18:25 | ||||||
К сожалению нет, но язык http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 существует и является ИМХО очень мощной вещью. Правда я больше поклонник С подобного синтаксиса, но это мелочи
Цикла нет вообще. В примере создаётся дефолтовая коллекция (список), у которого определён метод foreach. Как и любой метод он может принимать любые аргументы, но вот один специальный аргумент передаётся не как обычно (в "()"), а блоком за конструкцией и это всегда должен быть closure. Фича впервые увиденная мной в Ruby, по сути посто syntatic sugar, но как удобно! Получаеться любой метод или функция может принять любые аргументы + специальный "блок" - аргумент, что всегда является closure. Для такого специального аргумента можно создать специальное ключевое слово yield(), что будет вызывать closure если оно есть или ничего не делать если его нет. В скобках можно передать параметры. Естественно что какие параметры и сколько определяет сам метод. Просто пример как это может реализоваться (выдуманный Java подобный язык):
Как видим блок/closure можно передать и в аргументах, но компилер нам просто предлагает более красивый синтаксис. Также это означает что каждый метод/функция принимают как минимум один аргумент - собственно сам блок. В окружении где есть общий тип и допустимо изменяемое количество аргументов это не проблема. В примере кстати даны пара примеров как расширять синтаксис компилера без препроцессора (который сам по себе является чистым злом). Допустим LinkedList реализует некий интерфейс ArrayAccess, позволяющий к классу или к обьекту обращаться как к массиву, вызывая соответствующие методы. Также Closure может быть системным классом от Function, который релизует интерфейс Callable. Любой обьект реализующий Callable может быть вызван как функция (допустим вызывается метод call, навязываемый интерфейсом). Ну а наследовав от Closure или имплементировав интерфейс (допустим) Yieldable можно вести себя как closure и быть переданным в любую функцию как блок. Возможно покажется немного мозгодробильно, но ИМХО это очень хороший подход к использованию полного синтаксиса компилера любым класом/обьектом. |
| Автор: maggot 18.6.2007, 13:43 |
| Ну как, сделали компилятор? |