новая версия fucc: FU Compiler Compiler

зато какое название :)

FUCC with lisp !

fucc the lisp

Если вам пальчик показать, вы тоже смеяться будете?

Какой выходной язык?

>Sorry my terrible English, my native language is Lisp!

Скромный парень, ничего не скажешь.

lisp :)

а разве может быть что-то другое?

Хаскел, например. :)

На lisp генерить haskell? зачем?

>а разве может быть что-то другое?

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

> Системное программирование (в т.ч. и парсеры)

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

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

А потом прикручивать сишную библиотеку к лиспу? К тому же, насколько я понимаю, данная задача (парсер) на лиспе решается значительно проще чем на C, а потеря скорости будет незначительной (если вообще будет).

Готов с вами поспорить.

На lisp можно писать очень быстрые программы.

а че тут спорить.
давайте еще это перепишем на бейсике. на нем тоже можно писать быстрые программы.

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

>А в каком месте парсер - это системное программирование?

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

Даа-с..., мельчает публика... В топиках про Java/Gnome/Kde и прочее копья ломают за 100 постов, а здесь всего ничего --- все больше обывателей идут в Линукс и теперь уже не просто им пользуются, они теперь еще и права качают --- дайте мне то, дайте мне это, и чтобы крутилось и вертелось.

Да, по Лиспу. По-моему, лучшего языка по соотношению скорости разработки/производительности и скорости работы программы просто нету, и уж точно никакая Java на этом поприще Лисп не побьет. У лиспа одна проблема --- порог вхождения очень высок, поэтому простому обывателю не оценить всех его прелестей. Это что-то вроде линукса лет так десять назад.

Да, и на лиспе можно и достаточно просто писать очень быстрые программы, такие же быстрые как на C или ASM.

Да, и по топику: нужно будет посмотреть.

ocaml очень хороший язык с очень сильно вылизанным компилятором. Численные задачи рвет только так, си и рядом не валялся (gcc)

+1

На CLOS я бы ещё писал бы... Но голый лисп - нафиг, уж лучше на жабе...

>Даа-с..., мельчает публика... В топиках про Java/Gnome/Kde и прочее копья ломают за 100 постов, а здесь всего ничего --- все больше обывателей идут в Линукс и теперь уже не просто им пользуются, они теперь еще и права качают --- дайте мне то, дайте мне это, и чтобы крутилось и вертелось.

Это я уже заметил. Последнее время в мир Linux пришло очень много новых людей. Нет, они не хуже... Они просто новые. И этикет, да и сама ос изменилась... Хорошо? плохо?.. Не знаю, по-новому.

>Да, по Лиспу. По-моему, лучшего языка по соотношению скорости разработки/производительности и скорости работы программы просто нету, и уж точно никакая Java на этом поприще Лисп не побьет. У лиспа одна проблема --- порог вхождения очень высок, поэтому простому обывателю не оценить всех его прелестей. Это что-то вроде линукса лет так десять назад.

Полностью согласен. Ну если только про порог вхождения. Есть у меня в голове один курс, который можно будет читать чуть ли не в школе, и дети его пойму. Но. В идеи этого курса нету слова макросы. Вот тут то и начинается гибкость, и появляется "порог вхождения"

Далее, что касается java -- знаешь, в нее тоже порог вхождения ой какой не маленький, а удобство разработки сомнительное (в данный момент java'ой на жизнь и хлеб зарабатываю). Там есть очень много страшных слов (spring, hibernate и т.п.), и я не знаю куда проще войти, в этот мир или в лиспы-окамлы-хаскили-ерланги.

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

Что такое "голый лисп"?

кстати, clos это ничто иное как просто макросы :)

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

Деление на объектно-ориентированную и не объектно-ориентированную часть (как например С и С++) к лиспу неприменимо. Все данные, с которыми оперирует лисп, --- есть объекты. Даже когда программа вроде бы "на голом лиспе", все равно она оперирует с самыми настоящими объектами. В этом смысле лисп "гораздо более ООЯП" чем многие другие ООЯП, включая Java.

к слову и по теме разговора - ocamlyacc в ocaml-е очень посредственный, фактически калька с обычного yacc-а. Для более или менее сложного языка постоянно приходится моделировать контекст парсера через императивные конструкции. Неудобно жутко, сейчас мучаюсь.

И вабще после сиинтаксического и грамматического разбора программы на любом языке высокого уровня всё равно получается лисп в той или иной форме.

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

Знают. И оптимизация делается.

> к слову и по теме разговора - ocamlyacc в ocaml-е очень посредственный, фактически калька с обычного yacc-а. Для более или менее сложного языка постоянно приходится моделировать контекст парсера через императивные конструкции. Неудобно жутко, сейчас мучаюсь.

А чё в yacc-е есть таки штатные средства для смены контекста? А то мы пытались его использовать и отказались - может не нашли.

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

Если в си это еще приемлимо, то в ocaml-е использование императивных констукций достаточно геморойно. Переодически возникает желание забить на LALR и автоматическую генерацию и переписать на LL, рекурсивным спуском и ручками.

Как у него со скоростью полученых парсеров?

>Переодически возникает желание забить на LALR и автоматическую генерацию и переписать на LL, рекурсивным спуском и ручками.

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

Злобный

eXOR: профиль свой почисти плиз, а то похоже раздел Linux-Org-Ru ты не читаешь...

Гы. Это гамлетовский вопрос. Я видел и рекурсивные рукописные и LALR-овские генерируемые парсеры для си++. У каждого свои недостатки.

>ocaml очень хороший язык с очень сильно вылизанным компилятором. Численные задачи рвет только так, си и рядом не валялся (gcc)

не гони. мне БОЛЬШЕ ПОЛОВИНЫ исходников закомпилить не удалось. Про какие численные задачи вы говорите? Я знаю кучу либов на Си для распределенных вычислений, и для обсчета математики, но что-то не слышал даже, что все это есть на ocaml. И воще опции есть у gcc для оптимизации. вот так. афтар жжет. пешите есче.

> ocaml очень хороший язык с очень сильно вылизанным компилятором. Численные задачи рвет только так, си и рядом не валялся (gcc)

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

То что программу тяжелее скопилировать чем написать на ocaml мне прекрасно известно.

Далее, что касается опций оптимизации gcc то это тоже спорно.

ocaml не очень популярен в англо-язычной среде, но его очень сильно любят французы в своем inra.fr ;) Может стоит поискать в этом районе?

Ну как тебе сказать, нет предела к совершенству.

Мне вот код gcc тоже кажется не идеальным, но я же на него открыто не наезжаю?

Что касается функциональщины, то тут немного в другом затык, O'caml очень любит заявлять что стек закончился, вот это действительно раздражает :)

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

> Как у него со скоростью полученых парсеров? Вот когда выйдет версия 1.0, тогда и поинтересуйтесь.

> Системное программирование (в т.ч. и парсеры) Кто вам сказал, что парсеры -- это системное программирование? > и практически на любой платформе. Какое же это *системное программирование*, если на любой платформе :)