Вышел язык програмирования Cobra 0.7.4

>Что я вижу - инлайнинг?

почему-то если в компиляторах есть оптимизатор, который заменяет x на его значение, и common subexpression оптимизатор, что, это означает что для декомпиляторов совсем нет деОптимизатора, который понимая AST будет обобщать символы и заменять "инлайнинг на символы"?

В конечном виде, инлайнинг -- это ещё один view на те же AST. Необязательно там должен быть инлайнинг, но всякий деОптимизитор/рефакторинг view должен делаться интерактивно, как в той же IDA Pro.

> инвариантом алфавита является мощность множества его символов, которая у кои-8 есть 256, а у утф-16 около 32000.

для исключительно русских текстов, мощность текста будет одинаковая, хоть в кои-8 нарисуй, хоть в utf-16. Если существуют биективные отображения между кодировками, это один и тот же алфавит, виды с боку.

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

>паскаль1 в паскаль2, заменяя ньюлайн пробелом. Алфавит-то уменьшается?

нет. алфавит паскаля1 = ключевые слова паскаля и описание грамматики в BNF = алфавиту паскаля2, это один и тот же алфавит, только разные "кодировки". Кстати, взаимно однозначное соответствие. Вот если у тебя паскаль1 и паскаль2 будут с разной семантикой, тогда да, это будет точно компилятор :)

> семантика программы при компиляции должна сохранятся.

семантика foreach, for(i=0;i<N;i++) и велосипеда c IF/GOTO -- одинаковая. Но можно сказать, что семантика foreach более богатая, правильная -- т.к. она подходит для любых контейнеров. Так что тут с foreach семантика сохраняется, но уровень детализации меняется.

> З.Ы. все-таки хочу написать компилятор

Ахо А., Ульман Дж. Теория синтаксического анализа, перевода и компиляции

>Ахо А., Ульман Дж. Теория синтаксического анализа, перевода и компиляции

Книга А.Ахо, Р.Сети, Дж.Ульман: Компиляторы: принципы, технологии, инструменты,

http://www.proklondike.com/contentview.php?content=273&print=1

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

"а вот это устарело". Скорее, это маш. код от байткода "почти ничем не отличается". И интерпретировать его не нужно, достаточно откомпилировать один бинарный код в другой бинарный код. Пользуясь при этом информацией из рантайма, которая становится доступной благодаря JIT.

> И там оно будет компилируемым. Но это все 0.00000001% от общего использования явы

Батенька, следите за нулями. На Fedora>=4 и RHEL/CentOS>=5 gcj входит в поставку, как и софт скомпилированый им (напр. Tomcat, Eclipse).

> В такой системе, С будет интерпретируемым. в 0.00000001% от общего использования С.

Батенька, следите за нулями. Архитектура MIPS это и есть байт-код практически 1 в 1. По крайней мере байт-код MIPS в байт код jvm переводистя без особенных проблем и реально используется для перевода кода написаного на Си в 100% pure java.

>Давайте добьём поц иента:

>- Форт в шитом коде -

Поц иент на слово "шитый код" скажет "ЩИТО?" :))

>А в Компилируемом языке все связи зашиваются на этапе сборки. Причем нет нужды в универсальной vm. Связал с такой, с какой считаешь нужным. И в прокладках нет нужды (собственно, и возможности). Вот и получается...

вот и получается, что в compile-time у тебя не будет информации о run-time, и возможных способах оптимизации "на лету". Допустим, у тебя функция, у которой есть 3 реализации. Ты смотришь в профилировщик, видишь что её надо оптимизировать. Но параметры функции скачут в runtime, и ты не знаешь, под какой вариант её оптимизировать. JIT же сможет эту информацию собрать, статистически обработать и предложить автоматически нужный сценарий, по эвристикам. Чего в принципе не получится на "Компилируемом языке. где все связи зашиваются на этапе сборки"

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

это значит, что "старое определение" -- некорректно, раз оно не работает для новых явлений, и его надо выкинуть, расширив теорию и дав корректное для обоих случаев определение. Вот почему я возмутился в этом топике, вот здесь: http://www.linux.org.ru/jump-message.jsp?msgid=2556882&cid=2558025

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

ай как карашо.

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

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

Угу, а окажется его эвристика неэффективной и пролетите Вы, батенька, со своим jit-компилятором.

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

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

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

> Если это сделать нельзя, то будь он хоть 10 раз компилятор,

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

> А можт тогда все программы прямо в дебаге и гонять из иде?

с JIT в "дебаге" можно собирать не всю программу, а отдельную функцию, которую нужно оптимизировать. всё остальное в release, потому что по данным профилировщика нам до них дела нет.

> с JIT в "дебаге" можно собирать не всю программу, а отдельную функцию, которую нужно оптимизировать. всё остальное в release, потому что по данным профилировщика нам до них дела нет.

У ленивого индуса этой функцией будет main()

>Угу, а окажется его эвристика неэффективной и пролетите Вы, батенька, со своим jit-компилятором.

это я описал сценарий скорее из автоматизации выч. эксперимента и выборе лучшего метода для условий задачи. Эта задача вполне себе решается автоматически, конечно, окончательный выбор в неочевидных случаях (которых не так уж много) должен делать человек. Я сказал "предложить", не говорил, что JIT должен сам эвристики туда-сюда переключать пока не накопил статистически значимых данных. А штуки вроде probes в dtrace и интерфейс в JIT к ним -- позволяют львиную долю "оптимизации в профилировщике вручную" сделать автоматически, в случаях, когда выбор эвристики и выгода -- очевидна.

>А программы надо писать сейчас и не тормозить они должны тоже сейчас.

ну так пишите, Шура, пишите, они золотые.. и оптимизируйте, ага, вот прямо сейчас (и ещё неделю) :)

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

> это я описал сценарий скорее из автоматизации выч. эксперимента и выборе лучшего метода для условий задачи. Эта задача вполне себе решается автоматически, конечно, окончательный выбор в неочевидных случаях (которых не так уж много) должен делать человек. Я сказал "предложить", не говорил, что JIT должен сам эвристики туда-сюда переключать пока не накопил статистически значимых данных. А штуки вроде probes в dtrace и интерфейс в JIT к ним -- позволяют львиную долю "оптимизации в профилировщике вручную" сделать автоматически, в случаях, когда выбор эвристики и выгода -- очевидна.

Опять сказки о теоретической возможности.

>> А программы надо писать сейчас и не тормозить они должны тоже сейчас.

> ну так пишите, Шура, пишите, они золотые.. и оптимизируйте, ага, вот прямо сейчас (и ещё неделю) :)

Дык, всю неделю и пишу. Работа такая :)

> неленивый индус

оксюморон

>Опять сказки о теоретической возможности.

мы рождены, чтоб сказку сделать пылью.. так и запишем :)

>Работа такая :)

аналогично

>Дык, всю неделю и пишу.

"некогда думать, трясти надо" :)

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

1. При том что полная версия мс дотнета щас уже 200М (сюрприз?) это было бы интересно не только на embedded. Кстати, та программка размером меньше 1М тянула с собой 30М в дистрибутиве.

2. "теоретически возможно по мнению анонимуса" недостаточно. Нужны ключи командной строки или сторонние утилитки.

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

_____________________

а*(а+1)%2 всегда равно 0, не все читавшие это поняли

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

я думаю что-нить такое:

class C1 { int a; int f(){return a;} int g(){return a+1;} C1(int x) {a=x;} };

в другом файле:

class C2 { int h(int x) { C1 c=new C1(x); return c.f()*c.g()%2; } <...> };

>а*(а+1)%2 всегда равно 0, не все читавшие это поняли

Скобки как стоят?

как a* ( (a+1)%2) ? тогда если а-чётное, a+1- нечетное, внутр. скобка=1, результат = а. Если а нечётное, то (a+1)-чётное, итого 0. (кстати, если a float, вообще интересно :)

если ( a*(a+1) ) %2, то = ( a*a +a )%2, тут уже смотреть надо. a - чётное => a*a чётное, итого 0. а - нечётное, => a*a нечётное, нечетное+нечетное=чётное =>0.

ага, в этом случае 0. А если a - дробное или трансцендентное (a=pi)?

Если задано что a - целые, скобки/приоритеты расставлены однозначно, то Лисп, например, может вывести формулу по правилам символьной алгебры и проделать вот эту цепочку рассуждений во время компиляции.

В общем, я понял, что ты хотел сказать, но пример неудобный :)

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

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

http://ru.wikipedia.org/wiki/Модель_типизации_Хиндли_—_Милнера

кстати, почитай по ссылке http://www.linux.org.ru/jump-message.jsp?msgid=2528737&cid=2547089, там для Хаскелля расписано практическое применение PS. Дочитал про JNode, добавил тебя в аську. Пересечёмся как-нибудь, только чуть-чуть разгребу.

>Блин, вы реально невменяемы! В любом интерпретаторе есть синтаксический и семантический разбор! Как в компиляторе. Но в интерпретаторе нету кодагенерации! Там есть исполнение!

То есть отсутсвует фаза _преобразования_.

>1. При том что полная версия мс дотнета щас уже 200М (сюрприз?) это было бы интересно не только на embedded. Кстати, та программка размером меньше 1М тянула с собой 30М в дистрибутиве.

если стоит 2 програмки, каждая использует своё подмножество функций, то проще поставить один раз фреймворк (и потом не трогать при установке след. N программок), чем пытаться слепить фреймфорк по кусочкам или тянуть с каждой свою версию.

>И вообще, все эти "информацию собрать, статистически обработать и предложить автоматически нужный сценарий" -- это пока что из раздела фантастики.

Этот раздел фантастики давно имплементирован в JVM/CLR.

>если стоит 2 програмки, каждая использует своё подмножество функций, то проще поставить один раз фреймворк (и потом не трогать при установке след. N программок), чем пытаться слепить фреймфорк по кусочкам или тянуть с каждой свою версию.

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

>1. При том что полная версия мс дотнета щас уже 200М (сюрприз?) это было бы интересно не только на embedded.

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

>Этот раздел фантастики давно имплементирован в JVM/CLR.

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

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

По идее, грамотный линкер должен уметь связывать на уровне отдельных классов и методов. Если есть жёсткие манифесты на всё, каждая версия фреймворка имеет GUID и этот GUID прописан в манифестах, если есть универсальная метода выкачать/доставить нужные библиотеки (в ед. экземпляре), то этот толстый фреймворк можно разбить на кучу модульных классов-кусков (гы, ApplicationKit, WebKit, и т.п. ).

То есть нужен "распределённый" пакетный менеджер вроде 0install, который хранит GUIDы для разных пакетов. Тогда можно наплодить кучу подпакетов с каждым классом фреймворка конкретной версии, а пакет фреймворка сделать "метапакетом" в смысле Gentoo portage.

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

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

Давай лучше начнем с того, что тех кому "нравится язык жаба", надо отстреливать, потому что они портят генофонд. Нравится должно другое, женщины там, вино, музыка, табак, видеоролики про сложные взаимотношения двух семейных пар и т.п. Люди учат ЯП чтобы работать, а не для того, чтобы "абстрактно пейсать программы", для никого, в стол там, для будущих поколений. Это не проза, код через 20 лет никто не оценит. Да и вообще, код за который не получены деньги, нужен постольку, поскольку он принес пользу человечеству и ушел в опенсорс|паблик домен. Абстрактные фитюльки на Фокале, испражнения академиков интересны только в целях обучения. Я не слышал ни о ком, кто бы работал в котельной для заработка, а потом дома при лучине на пергаменте писал бы программы для удовольствия. (В отличие от музыкантов, которые играли музыку для удовольствия и которым приходилось зарабатывать дворниками и сторожами) Так вот "люди хотят жабу, потому что >50% промышленного и корпоративного софта пока что пишется на жабе". Раньше на Коболе. Фортран и C извини, в бухгалтериях не использовались и не прижились, как и Форт и Фокал.

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

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

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

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

да, тот же dlopen/загрузка dll'ек/reflection с именем класса, заданным вручную в поле ввода EditBox, всю эту модель ломает. Ломает где и почему -- потому что в поле можно ввести всё что угодно, в том числе и "нескешированное локально". Но если у каждой .so /dll-ки кроме имени будет ещё и GUID, и этот GUID будет задан, то сможем и из сети вытянуть, если понадобится (или, при установке, определять и выкачивать/устанавливать заранее).

Верифицируемый managed код с жёсткими манифестами на всё так вообще эту проблему снимет. В той же Сингулярити вместо костылей вроде scanf("%s", dllname); lib=dlopen(dllname) должен появиться стандартный протокол, в котором обязательное поле будет не только soname, но и GUID, и загрузчик .so должен будет грузить по этому GUID. Тогда эта загрузка ломаться не будет.

>Хотя жаба может и быть неидеальной, но и Хаскель наверняка не без узких мест и изьянов, а значит точно так же неидеален

ни один язык не идеален абсолютно. Но отдельный элемент отдельного языка для отдельного участка отдельной задачи может подходить лучше чем Общее Универсальное Решение. То есть вопрос просто в уместности применения, и определении границ применимости.

Напоминает ActiveX

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

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

>> И вообще, все эти "информацию собрать, статистически обработать и предложить автоматически нужный сценарий" -- это пока что из раздела фантастики.

> Этот раздел фантастики давно имплементирован в JVM/CLR.

И он всегда даёт оптимальное решение? Слава Роботам уже наступила и людишки не нужны?

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

А чистить неиспользуемые либы кто будет?

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

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

Чтобы расписать поподробнее: вышла версия 1.0 библиотеки libjopa, на неё сослались программы AAA и BBB. Затем автор увидел, что в ней есть страшный баг, поправил его и выпустил libjopa 1.1. Но программы AAA и BBB продолжают юзать libjopa 1.0!

>вышла версия 1.0 библиотеки libjopa, на неё сослались программы AAA и BBB. Затем автор увидел, что в ней есть страшный баг

В названии 8), это решается не id библиотеки а id интерфейсов.

> С другой стороны, должен быть какой-то унифицированный загрузчик, интегрированный с распределённым пакетным менеджером. Ну и унифицированный формат-контейнер документа, унифицированные метаданные и протоколы заодно :) это хорошо.

<mask set="ballmer"> И всё это -- в новой версии Windows Vista! Технологии микрософт рулят! </mask>

>> вышла версия 1.0 библиотеки libjopa, на неё сослались программы AAA и BBB. Затем автор увидел, что в ней есть страшный баг

> В названии 8), это решается не id библиотеки а id интерфейсов.

А как быть с расширенным функционалом (пусть окромя функции pook() добавлена функция defecate())? Программам, которые используют только pook() на какую версию библиотеки ссылаться?

>А как быть с расширенным функционалом (пусть окромя функции pook() добавлена функция defecate())?

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

>>1. При том что полная версия мс дотнета щас уже 200М (сюрприз?) это было бы интересно не только на embedded.

>Это не было бы интересно. Ты сейчас сказал что .so не нужны. ДАвай собери весь свой дистр статически - и ты увидишь сколько он займет и побежишь за памятью в магазин.

ПОАККУРАТНЕЙ пожалуста.

я НЕ сказал что .so не нужны. Я выдвинул "дополнительный критерий компилируемости", и _для_простоты_ заявил там статическую компиляцию, а вообще (согласен с тобой) динамическое связывание лучше, только опять не с целой VM/Runtime/ОбзовиКакУгодно.

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

А еще в мобильном случае многие любят по сети тянуть инсталляшку прямо на девайс, а не через десктоп. Да и не в кайф долго тянуть 30 метров, если можно 0.1М, и всеж влом платить лишние деньги за ГПРС.

>> А как быть с расширенным функционалом (пусть окромя функции pook() добавлена функция defecate())?

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

То есть теперь мне надо завести 2 ветки для библиотеки libjopa: одну, в которой поправлена бага, а другую, в которой добавлена функция defecate() ? А если это нельзя или очень сложно сделать?

> Программам, которые используют только pook() на какую версию библиотеки ссылаться?

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

>> Программам, которые используют только pook() на какую версию библиотеки ссылаться?

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

Ну вот слинковались они с версией 1.0, в которой, как известно, баг. Но он поправлен только в 1.1, в которой также добавлена функция defecate(). Таки как быть?

>> Программам, которые используют только pook() на какую версию библиотеки ссылаться?

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

Ну вот слинковались они с версией 1.0, в которой, как известно, баг. Но он поправлен только в 1.1, в которой также добавлена функция defecate(). Таки как быть?

>То есть теперь мне надо завести 2 ветки для библиотеки libjopa: одну, в которой поправлена бага, а другую, в которой добавлена функция defecate() ? А если это нельзя или очень сложно сделать?

Нет, зачем? Один объект может реализовывать несколько интерфейсов разом. Вы знаете про множетсвенно наследование в C++ или про интерфейсы в java?

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

Мне кажется уже пора как-то формализовать выражение обратной совместимости либ. Ну например согласиться всем что должна быть статические переменные например CurrentVersion & СompatibleWithVersion

При том это полностью проблему не решит, а только 99.9, поскольку вроде несущественные изменения могут кого-то сильно затронуть ( пример: в php text2html вместо <br> стал ставится <br /> )

> Один объект может реализовывать несколько интерфейсов разом.

На самом деле проблема есть и гораздо глубже, поскольку интерфейс ОТНЮДЬ не полностью формализует требования к чему-то.