http://research.sun.com/projects/plrg/
Спецификация.

Впечатляет
И, что особенно приятно, есть реальный шанс, что эти вещи не останутся академическими разработками, а найдут промышленное применение.

пролистал все страницы спецификации по диагонали
больше всего понравилось
2.2.19 atomic expression... (!!!)
2.14 tests.. (!!!!)
3.7. syntax expander... (!!!!!!! да это круче препроцессора)
интересно посмотреть всё это в работе.

Цитата(Mayk @ 12.1.2006, 03:34 )

2.2.19 atomic expression... (!!!)

Саттер обещал в следующем C++/CLI.

Цитата(Mayk @ 12.1.2006, 03:34 )

2.14 tests.. (!!!!)

Ну, фреймворки автоматического юнит-тестирования сейчас вроде много где есть.

Цитата(Mayk @ 12.1.2006, 03:34 )

3.7. syntax expander... (!!!!!!! да это круче препроцессора)

Давно есть в OCaml, теперь еще и в Nemerle. Действительно крутейшая вещь.

Меня убила наповал система размерностей (2.2.4). Сколько я знаю, в полной мере такие вещи еще нигде не реализуются.

Цитата(Mayk @ 12.1.2006, 03:34 )

интересно посмотреть всё это в работе.

Многое по отдельности - хоть сейчас, а вот все вместе - самому жутко интересно

Они говорят, что хотят дать Fortran то же, что дала Java С++. Интересно, найдет ли он признание в тех кругах, где используется Fortran? Жалко, он с ним несовсем совместим.

Цитата(Cr@$h @ 15.1.2006, 01:43 )

Интересно, найдет ли он признание в тех кругах, где используется Fortran?

Почему бы и нет? Уж во всяком случае Fortress удобнее и безопаснее, продвигается крупной фирмой под госзаказ...

Цитата(Cr@$h @ 15.1.2006, 01:43 )

Жалко, он с ним несовсем совместим.

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

Будем надеяться. Хотя, к Fortran я привязался. Будет жалко, если первый высокоуровневый язык канет в Лету. Интересно, не нашел, он будет управляемым? Если да, то про скорость можно будет забыть.

Цитата(Cr@$h @ 15.1.2006, 03:08 )

Интересно, не нашел, он будет управляемым?

Вполне возможно.

Цитата(Cr@$h @ 15.1.2006, 03:08 )

Если да, то про скорость можно будет забыть.

Думаю, ты не прав. Управляемый строготипизированный язык дает компилятору гораздо больше простора для оптимизации. Уже сейчас управляемые языки проигрывают неуправляемым в среднем не более 10-30%. Дальнейшее развитие компиляторов и появление открытой архитектуры бэкэнда (вроде Phoenix) позволит полностью ликвидировать разрыв.

Читаю спецификацию, отмечаю детали. Интересно что все молодые языки с какими я сталкиваюсь не имеют C подобный синтаксис, а мне он нравиться

Traits как я понял это реализация алгоритма, затем эта реализация может быть использована классом над его данными. Впервые столкнулся в JS, где функция может стать члеом прототипа любого обьекта. Одна из больших сложностей в именах, в алгоритме обычно используем некие абстрактные названия вещам, в конкретных "классах" уже из контекста задачи. Без продвинутого, не текстового препроцессора (не как в C) проблема останеться.

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

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

И тут камень преткновения, что это за код? В смысле компилируем ли мы изначальный исходник, а затем интерпретируем код с нашими расширениями, или всё действительно компилиться, а грамматика выдаёт для своих конструкций код компилятору. Между обеими подходами не много разницы, код для интерпреатора может JIT скомпилиться и исполняться как обычный код, другое дело что гибкость новых расширений ограничена, должны генериться законченые конструкции языка. Во втором же подходе расширение может быть не законценой дополнительной частью конструкции оригинального языка, тем самым действительно "вклиниваться" в процесс порождения кода. Тогда конкретно не врубаюсь это реализовать, ведь не каждая конструкция (не синтаксически, думаем о логике) может "дополнить" другую, к тому же как тогда реализовать оптимизатор (расматриваем самые первые оптимизаторы, а не простые peep hole.

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

Цитата(Sardar @ 15.1.2006, 04:02 )

Интересно что все молодые языки с какими я сталкиваюсь не имеют C подобный синтаксис, а мне он нравиться smile

А мне разонравился Все больше убеждаюсь, что конструкции вроде if..then..end или do..end предпочтительнее явных блоков.

Цитата(Sardar @ 15.1.2006, 04:02 )

А вот как с примитивами, был у меня byte, чере три операции стал double. Можно конечно отказаться от примитивов, всё это обьеткы, разбросанные по памяти, на которые держим ссылки, но об эффективности то забывать тоже нельзя...

Значение не может поменять тип. В ФЯ и на обыкновенные присваивания со скрипом идут, а тут - смена типа
Примитивы в OCaml есть: это unit, int, char, bool и конструкторы без параметров (вроде type order = Less | Equal | Greater). Все они имеют размер в машинное слово.
Открою страшную тайну: в OCaml float - ссылочный тип Но компилятор оптимизирует работу с ним, делая unboxing где только можно.
Одна из самых неприятных вещей в реализации рантайма OCaml - это отсутствие целочисленной арифметики в полную ширину машинного слова. Один бит у любого значения воруется в пользу GC для пометки - это значение ссылочного типа или нет. К сожалению, никому еще не удавалось создать безтеговый GC для ML.

Цитата(Sardar @ 15.1.2006, 04:02 )

И тут камень преткновения, что это за код? В смысле компилируем ли мы изначальный исходник, а затем интерпретируем код с нашими расширениями, или всё действительно компилиться, а грамматика выдаёт для своих конструкций код компилятору.

Нет, все действительно компилится, а не интерпретируется: CamlP4 отдает компилятору дамп преобразованного AST, а тот его компилирует так же, как обычный код.
Но в процесс кодогенерации он вмешаться не может, также как и в вывод типов. CamlP4 можно рассматривать как компилятор, target'ом которого является не машинный код, а код на OCaml.
Внедрение кастомных бэкэндов - это отдельная тема, вроде того же вышеупомянутого Phoenix.

Цитата(Void @ 15.1.2006, 02:25 )

Уже сейчас управляемые языки проигрывают неуправляемым в среднем не более 10-30%. Дальнейшее развитие компиляторов и появление открытой архитектуры бэкэнда (вроде Phoenix) позволит полностью ликвидировать разрыв.

Да ну. Основная идея управляемого кода -- виртуальная машина (среды выполнения, как хотите), которая позволяет теоретически запускать прогу на любой платформе, лишь бы стояла там она (пусть .Net под Linux'ом). Если посмтреть на байт-код (MSIL), то увидим процессоро независимые команды псевдо ассемблера -- потому и пофиг, где запускать -- машина установлена, значит может запускать код на этой платформе. Отсюда дикий проигрыш в производительности все навороты вроде векторизации, SSE3 и проч. простаиваются. А пытаться оптимизировать байт-код все равно что оптимизировать ассемблерный код -- что толку, спустились, не поднятся.
Говоря про управляемый код, я прежде всего имел в виду управление кучей. В задачах, которые я решаю, любой дотНет загнется за считанные секунды. Обычно результаты операций выделяются целыми массивами и матрицами, которые занимают чуть ли не четверть памяти и которые надо подчищать. Хотя, это еще как писать проги, да и управляемые среды возвращают все больше прав на память...

Цитата(Void @ 15.1.2006, 03:21 )

Все больше убеждаюсь, что конструкции вроде if..then..end или do..end предпочтительнее явных блоков.

Если, имеешь в виду {} под блоком, то согласен. Порой за птичками не усежу, от кого она -- от цикла, класса или свитча.

Цитата(Void @ 15.1.2006, 03:21 )

Значение не может поменять тип.

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

Cr@$h
Байт-код сейчас никто напрямую не интерпретирует. Его сначала обрабатывает JIT-компилятор, который генерирует машинные коды. И уже сейчас он генерирует очень неплохой код: C# 2.0 во многих задачах генерирует код, сопоставимый по производительности с MSVC. Только за ICC ему пока не угнаться.

Цитата(Cr@$h @ 15.1.2006, 17:48 )

Отсюда дикий проигрыш в производительности все навороты вроде векторизации, SSE3 и проч. простаиваются.

Придет время, и Intel займется бэкэндами для управляемых языков. Это неизбежно.

Цитата(Cr@$h @ 15.1.2006, 17:48 )

Если, имеешь в виду {} под блоком, то согласен.

Да, {} или begin/end - т.е то, что называется compound statement.

Цитата(Cr@$h @ 15.1.2006, 17:48 )

Это правда, но не вся.

Я имел в виду статически типизированные ФЯ.

Цитата(Void @ 15.1.2006, 18:11 )

Байт-код сейчас никто напрямую не интерпретирует. Его сначала обрабатывает JIT-компилятор, который генерирует машинные коды.

Собственно, другого мне даже не известно (уже не помню ) -- при первом запуске происхоит компиляция на лету из промежуточного яыка в машинный для данной платформы.
Компиляция с оптимизацией некоторых довольно больших проектов занимает часы. Как ты себе это представляешь при управляемом коде? При первом запуске тебе надо будет подождать часок, чтобы прооптимайзилось все. Да даже не получится этого сделать из-за псевдо ассемблера.
А компилирует кто вообще? -- среда выполнения. Их пишут Mic и Sun. Другие тоже хотят и сюда влезть, чтобы писать оптимизирующие компиляторы, например, Intel, но я себе это плохо представляю, когда стоят два дотНета на одной машине -- как выбрать, какой компилить будет пусть даже на лету, и уж тем более, где указывать параметры компиляции для того же Intel .Net...

Цитата(Void @ 15.1.2006, 18:11 )

Придет время, и Intel займется бэкэндами для управляемых языков. Это неизбежно.

Естественно, путей на самом деле совсем мало. С бэкэндами я не знаком..., но и не слышал, чтобы они про это подумывали.
Что касается Fortress, то я на него смотрю, как смотрят со стороны C++ на Java. Наверное, перейду таки. Хорошо я еще не так консерватичен и могу здраво выбирать.

Цитата(Cr@$h @ 15.1.2006, 23:09 )

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

Двух фреймворков скорее всего не будет, Intel и другие получат возможность встраивать собственные кодогенераторы. См. http://research.microsoft.com/phoenix/compiler.aspx

Цитата(Void @ 15.1.2006, 01:21 )

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

В принципе это эффективней по памяти чем структуры с типом(тегом) и union полем, в том плане что проц читает значение одним словом. В машине с 64 словом можно и несколько битов отдать на служебную инфу, точности всё равно достаточно, только для float чисел сложности будут, нельзя "так просто" выделить пару битов на метаинфу (видать отсюда в OCaml float это ссылочный тип...). Xотя какая сейчас экономия, в принципе любой тип храниться/выравниваеться в один или несколько машинных слов, дабы bus error не поймать. Меня это когда то сильно задело, старался использовать минимум памяти, где можно обойтись char или short, int не пользовал...

Цитата(Void @ 15.1.2006, 01:21 )

Внедрение кастомных бэкэндов - это отдельная тема, вроде того же вышеупомянутого Phoenix.

Ясно, в принципе пока это мне не нужно, просто были размышления. А вот с введением traits действительно необсодимо что то подобное "контролируемому препроцессору" на подобие шаблонов в C++, но только менять/декларировать можно было бы всё, имена используемых методов/функций, собственных и других переменных, всё, так что бы класс наследуемый алгоритм не ограничивался в именах своих членов. Только как бы громоздко не вышло... Дочитаю спецификацию, поделюсь как есть.

Цитата(Cr@$h @ 15.1.2006, 14:48 )

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

Мне всего раз в жизни (сейчас) потребовалось управлять кучей самому, софтина исполняеться на "продвинутом" z80 проце с 512кб памятью в многопоточной (таймер) среде, есессно никакой виртуальной памяти. Изучил как работать может malloc/free для "обычной" памяти, также для страничной виртуальной(размеченной) памяти, ИМXО хорошо реализованный сборщик мусора может работать эффективней чем malloc, если прога совершает туеву хучу мелких аллокаций, хитросплетённых в деревья с "рекурсией". Фрагментации меньше если GC гоняет время от времени данные "из чаши в чашу" собирая живое плотно по страницам.

Цитата(Sardar @ 16.1.2006, 00:29 )

В принципе это эффективней по памяти чем структуры с типом(тегом) и union полем, в том плане что проц читает значение одним словом. В машине с 64 словом можно и несколько битов отдать на служебную инфу,

Можно, но не нужно (кстати, OCaml портирован и на AMD64, и на PPC и на IA-64). Дело не только (и не столько) в точности, а в том, что целые значения периодически приходится выравнивать инструкциями сдвига, что снижает быстродействие. И одновременно это затрудняет интероп. У OCaml не лучший FFI, по трудоемкости оберток сравним с JNI. Хотя есть тулзы вроде SWIG и ocamlidl (да, на OCaml можно работать с COM, как в роли клиента, так и сервера).
Да, и еще одно неудобство проистекающее из внутреннего представлениях данных: длина массивов в OCaml ограничена ~4M, а строк - 16M для 32-разрядных машин.

Цитата(Sardar @ 16.1.2006, 00:29 )

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

Угу, именно так. Вообще, по некоторым деталям технической реализации OCaml стоит глянуть сюда.
Добавлено @ 22:43
P.S. Как-то скачкообразно дискуссия движется Может посты сугубо про OCaml выделить из темы?

Цитата(Void @ 15.1.2006, 21:39 )

длина массивов в OCaml ограничена ~4M, а строк - 16M для 32-разрядных машин.

4Мб или 4.Е6 элементов? В принципе в 4Мб много ссылок и примитивов влезет, но это сильное ограничение...
У себя со строками хорошо провернул, не мутируемые, созданные из блоков и связанных списков "указателей" на части блоков. Это помогает не транжирить память при многих строковых операциях, например "test: " + 90 +"Mb" или "[pad]" * 3 (создать новую строку как сложив "[pad]" три раза), также подстроки и другое. Цена этому накладные расходы при чтении строк, например выбирать посимвольно charAt(индекс) будет жутко не эффективно, но решением будет открыть stream на строке и читать её как поток символов (текущую позицию сохраняет "драйвер" потока для строк и не прыгает по блокам). Xотя это всё overkill для простого шаблонизатора вебстраничек для вебинтерфейса мудрёной железки

Цитата(Void @ 15.1.2006, 21:39 )

P.S. Как-то скачкообразно дискуссия движется smile Может посты сугубо про OCaml выделить из темы?

Не думаю, ведь серьёзно Fortress пока не обсуждаем, только гадаем что вкусного у него есть + просто свои мысли, полезно читая спецификацию врубаться как же оно реализовываеться

Цитата(Void @ 15.1.2006, 22:27 )

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

Это я имел в виду. Конечно .Net та же будет одна. Но все равно, как пользователю выбирать и настраивать кодогенератор. Сейчас по оптимизации много фич накрутили: можно даже автопрофилирование делать -- прога запускается и во время своей "стандартной работы" кидает "какую-то" хитрую инфу в отдеьный файл. Потом компилируешь снова, указываешь использовать наработанный файл. На основе него он делает оптимизацию, и при стандартной работе твоя прога ведет себя довольно шустро.
Компиляция в MSIL -- вещь не благодарная. Там же все в простых терминах написано, на псевдо ассемблере, а про саму библиотеку .Net я вообще молчу -- она же вообще не должна компилиться, на сколько я знаю, стоит себе и стоит под Виндой.
Заботливый компилятор показывает, какие циклы векторизовались, какие нет, почему так и т.д. А тут у него один MSIL. А ведь векторизация -- это грубо увеличение скорости работы цикла со стандартными операциями во столько раз, сколько АЛУ по плавающей точе установлено на проце. У камней с SSE3 их, кажись, 4. Актуально, не правда ли?
Про управляемый код -- можешь обозвать любой язык .Net'ом (например, MC++) и использовать для него соотв. компилятор, но, объясняя все в терминах MSIL, особо не разгонишься, никакой специфики проца. А выполнять его будет только CLR, на к. покушаться третьим лицам не разрешено вообще-то.

Цитата(Sardar @ 15.1.2006, 23:29 )

malloc/free для "обычной" памяти

Да мне бы матрицу или массив освободить самому через какой-нить deallocate -- так ведь и этого не дают.

Цитата(Sardar @ 16.1.2006, 00:58 )

Не думаю, ведь серьёзно Fortress пока не обсуждаем, только гадаем что вкусного у него есть + просто свои мысли, полезно читая спецификацию врубаться как же оно реализовываеться

Sun этим серьехно занилась. Слышал тестирования и разработка и в Питере проходит.

Цитата(Sardar @ 16.1.2006, 01:58 )

4Мб или 4.Е6 элементов?

4 миллиона элементов (ну и соответственно 16 Мб). Для float array - только 2 млн., потому что компилятор трактует массив вещественных чисел особым образом, храня их сразу в unboxed виде.

Цитата(Sardar @ 16.1.2006, 01:58 )

У себя со строками хорошо провернул, не мутируемые, созданные из блоков и связанных списков "указателей" на части блоков. Это помогает не транжирить память при многих строковых операциях, например "test: " + 90 +"Mb" или "[pad]" * 3 (создать новую строку как сложив "[pad]" три раза), также подстроки и другое. Цена этому накладные расходы при чтении строк, например выбирать посимвольно charAt(индекс) будет жутко не эффективно

Кстати, вот в этом документе описывается интересная структура данных VList, с амортизированным временем конкатенации и произвольного доступа к элементу в O(1), при некоторой избыточности по памяти.

Цитата(Cr@$h @ 16.1.2006, 07:06 )

А тут у него один MSIL. А ведь векторизация -- это грубо увеличение скорости работы цикла со стандартными операциями во столько раз, сколько АЛУ по плавающей точе установлено на проце. У камней с SSE3 их, кажись, 4.

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

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

Занятно: хотя название предполагает родство с Фортраном, язык значительно больше напоминает APL. Также собственный набор символов, близость к нормальной математической нотации, мощная матричная алгебра и пр. Но идея может быть и неплохая.