Re[21]: Noop - новый язык для JVM
От: FR  
Дата: 28.09.09 08:41
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>Ну тогда держи: Nemerlo


VD>А шо? Мне нравится!


Угу у меня тоже сразу в голове украинский гимн зазвучал
Re[21]: Noop - новый язык для JVM
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.09.09 08:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:


S>>Ну тогда держи: Nemerlo


VD>А шо? Мне нравится!


Дарю
Re[21]: Немерло
От: Qbit86 Кипр
Дата: 28.09.09 08:45
Оценка: 15 (1) :))) :)
Здравствуйте, VladD2, Вы писали:

VD>А шо? Мне нравится! :))


Например, в сочетании «это ваше Немерлó» :) Или: «закрой Немерлó!» :)
Глаза у меня добрые, но рубашка — смирительная!
Re[5]: Noop - новый язык для JVM
От: thesz Россия http://thesz.livejournal.com
Дата: 28.09.09 09:18
Оценка:
Здравствуйте, nikov, Вы писали:

N>Здравствуйте, thesz, Вы писали:


T>>Иными словами, higher-kinded types не позволяют эмулировать даже базовые возможности классов типов Хаскеля.

T>>Тем временем Хаскель ушёл ещё дальше.

N>Adriaan утверждает, что в Scala тоже можно сделать вещи, невыразимые в Haskell:


N>

N>Your example does not type check because it imposes a bound on the higher-order type parameter of the Monad's type constructor that is stricter than what was originally declared. Our paper on type constructor polymorphism explains how to do this is Scala. By the way, this is impossible in Haskell. You'd need something like abstraction over type class contexts.


Семейства типов эту задачу не решат?

class AMonadContext context a where
    aMonadContext :: Monad m => a -> context (m a) -- a witness of existence.

class AMonad m where
    type Context m
    return :: AMonadContext (Context m) a => a -> m a
    (>>=) :: (AMonadContext (Context m) a,
              AMonadContext (Context m) b) => ...

instance AMonad Set where
    type Context Set = ReqOrder
    ...

instance Ord a => AMonadContext ReqOrder a where
    aMonadContext a = ReqOrder (return a)


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

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

Итак, подходит ли это в качестве решения?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: Noop - новый язык для JVM
От: LaptevVV Россия  
Дата: 28.09.09 10:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, что я могу сказать? Ошибочное и приземленное мышление.

VD>Про парадокс Блаба
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.
слыхал?

VD>Вот — это отличный его пример.
Читал, конечно.
LVV>>И я с этим согласен.
VD>Прискорбно. Значит ваш вуз будет плодить тех самых блабов. И совершенно все равно какие языки или платформы вы будете преподавать. Ведь если преподаватель не знаком с концепциями которые предоставляют все эти лиспы, хаскели и т.п., то научить вы людей сможете только оберону, так как любое обучение не выйдет за рамки структурного программирования, ООП и КООП. В прочем, многие вузы и дальше структурного программирования не идут.
Тут как всегда наблюдаем соотношение изменчивость vs стабильность. В промышленности лучше иметь стабильность — на некоторый период времени. Так оно и есть. Потом наступает время изменчивости. Но скачком! Новая технология создает ступеньку. Вот вчера только затопили последний аналоговый Прогресс. А в ИТ изменчивость — это непрерывный процесс. И это не есть хорошо для производства программ.
LVV>>Фичи должны быть оправданы. Например, усложнением решаемых задач.
VD>Дык они и оправданы. А то что эти оберонисты не понимают этого — проблема именно оберонистов, а не фич или индустрии.
Ну, скорее всего, зависит от задач.
VD>Структурное программирование, ООП и КООП — это замечательно! Но современный вуз обязан давать так же ФП и МП! Обязан!!!
VD>А на Обероне вы точно этому не научите.
А мы на Обероне и не учим. А чему учим — ты ж читал мою цитату из блога. И Фадиез там есть.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[18]: Noop - новый язык для JVM
От: Andrei F.  
Дата: 28.09.09 11:26
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>1. Специально разработанная система типов позволяющая осуществлять метапрограммирование на базе специально заточенной под это системы типов.


Звучит, гм, довольно тавтологично

VD>Причем программы в конечном счете транслируются в эффективный (по словам автора) С-код который компилируется с помощью GCC. При этом устраняется большая часть оверхэда вызванного использованием высокоуровенвых абстракций (в плоть до избавления программы от необходимости использовать сборку мусора).


Мощная заявка. А как оно это делает? Особенно интересно про сборку мусора.

VD>Спорным в этом проекте можно назвать использование метапрограммирования на основе супер-мощьной системы типов (полной по тьюрингу). Но учитывая, что эта система типов используется для контроля надежности программы, может быть это и не страшно.


Где можно почитать в доступной форме, что это такое и как работает?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[20]: Noop - новый язык для JVM
От: Mr.Cat  
Дата: 28.09.09 11:54
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>

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

Отнимая фичу — надо дать механизм ее реализации — такова суть языка scheme.
Re[19]: Noop - новый язык для JVM
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 12:04
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Где можно почитать в доступной форме, что это такое и как работает?


Ссылки были выше. На сайте есть ряд работ. Основная их проблема — излишняя заформализованность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Noop - новый язык для JVM
От: Andrei F.  
Дата: 28.09.09 12:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Основная их проблема — излишняя заформализованность.


Вот-вот. В этих мануалах черт ногу сломит. Но мне была интересна сама концепция, что это за хитрая система типов. Она же вроде бы не уникальная для этого языка?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[5]: Noop - новый язык для JVM
От: Andrei F.  
Дата: 28.09.09 14:01
Оценка:
Здравствуйте, nikov, Вы писали:

N>Теперь, тебе надо написать функцию Map0, которая будет абстрагироваться от конкретного типа коллекции, и вызывать у нее метод Map, передав ей функцию (_ -> 0), которая устанавливает все элементы коллекции в 0. Для этого все коллекции должны реализовывать общий интерфейс с методом Map. Но вот беда: в рамках обычных дженериков C#, Nemerle или Java такого не сделать — у методов Map совершенно разные сигнатуры.


Разве результат выполнения Map (при вызове на коллекции интерфейсов) не придется все равно приводить к базовому классу?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[21]: Noop - новый язык для JVM
От: nikov США http://www.linkedin.com/in/nikov
Дата: 28.09.09 14:08
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Вот-вот. В этих мануалах черт ногу сломит. Но мне была интересна сама концепция, что это за хитрая система типов. Она же вроде бы не уникальная для этого языка?


Насколько я понял, там поддерживается kind polymorphism, что довольно уникально.
Re[6]: Noop - новый язык для JVM
От: nikov США http://www.linkedin.com/in/nikov
Дата: 28.09.09 14:10
Оценка: 4 (1)
Здравствуйте, Andrei F., Вы писали:

AF>Разве результат выполнения Map (при вызове на коллекции интерфейсов) не придется все равно приводить к базовому классу?


Не придется. Почитай эту статью, в ней несколько примеров, и хорошее объяснение, как это работает.
Re[5]: Noop - новый язык для JVM
От: thesz Россия http://thesz.livejournal.com
Дата: 28.09.09 15:37
Оценка: 22 (2)
Здравствуйте, nikov, Вы писали:

N>Здравствуйте, thesz, Вы писали:


T>>Иными словами, higher-kinded types не позволяют эмулировать даже базовые возможности классов типов Хаскеля.

T>>Тем временем Хаскель ушёл ещё дальше.

N>Adriaan утверждает, что в Scala тоже можно сделать вещи, невыразимые в Haskell:


N>

N>Your example does not type check because it imposes a bound on the higher-order type parameter of the Monad's type constructor that is stricter than what was originally declared. Our paper on type constructor polymorphism explains how to do this is Scala. By the way, this is impossible in Haskell. You'd need something like abstraction over type class contexts.


{-# LANGUAGE TypeFamilies, MultiParamTypeClasses, FlexibleContexts, FlexibleInstances, UndecidableInstances, RankNTypes #-}

import Data.Set hiding (map)

class Monad' m where
    return' :: a -> m a
    bind' :: m a -> (a -> m b) -> m b

class Monad''Req rq a where
    requirement :: rq a    -- a witness
    requirement = undefined


class (Monad''Req (ValueReq m) a, Monad''Req (ValueReq m) b) => Monad'' m a b where
    type ValueReq m :: * -> *
    return'' :: a -> m a
    bind'' :: m a -> (a -> m b) -> m b

data Ord a => RequireOrd a = RequireOrd a

instance Ord a => Monad''Req RequireOrd a

bindSet :: (Ord a, Ord b) => Set a -> (a -> Set b) -> Set b
bindSet g q = unions (map q (toList g))

instance (Ord a, Ord b) => Monad'' Set a b where
    type ValueReq Set = RequireOrd
    return'' a = singleton a
    bind'' g q = bindSet g q

checkZero :: Int -> Set Int
checkZero 0 = empty
checkZero n = singleton n

decrement :: Int -> Set Int
decrement n = singleton (n-1)

decCheck :: Set Int -> Set Int
decCheck set = (set `bind''` decrement) `bind''` checkZero

test = decCheck $ fromList [0,1,2,3]


См. также: http://hackage.haskell.org/package/rmonad

A library for restricted monads based on associated datatypes. This allows datatypes such as Set to be made into monads.


Сие позволяет мне заявить, что товарищи из Scala слегка поотстали от жизни в Хаскеле.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Noop - новый язык для JVM
От: WolfHound  
Дата: 28.09.09 15:46
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

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

А мне подход с системой типов нравится гораздо больше.
1)Мы в очень широком смысле не можем написать метафункцию не правильно.
2)Метафункция не может порождать не правильный код. Те все ошибки увидит разработчик матафункции, а не пользователь метафункции.
3)Если пользователь метафункции попытается не правильно ее использовать ему об этом расскажет компилятор.
4)Благодоря строгому отделению мух от котлет мы упрощаем сам компилятор.
В том же компиляторе немерла в алгоритме вывода типов есть куча приседаний вокруг макросов. Что явно не идет на пользу и так очень не простому алгоритму вывода типов.
В случае с навороченной системой типов система разваливается на несколько весьма изолированных слоев:
1)Парсер.
Если делать парсер на основе PEG то мы практически бесплатно получаем расширяемый во все стороны парсер.
На этой стадии мы сообщаем программисту об ошибках разбора текста.
Также мы производим переписывание из красивых синтаксических конструкций в вызовы метафункций.
2)Вывод типов. Разрешение перегрузки и тп.
Так как для вывода типов разницы между функцией и метафункцией нет мы получаем серьезное упрощение самой сложной части фронтенда.
Данная стадия основной источник ошибок времени компиляции.
В случае если ошибок компиляции не обнаружено на выходе этой стадии мы получаем дерево которое можно сразу скормить бекенду.
Однако так как по всей видимости для навороченных систем типов построить полный и не противоречивый вывод типов невозможно мы будем вынужденны использовать эвристики.
Как следствие эта стадия может дать неправильное дерево.

Следующие 2 стадии общие для всех фронтендов.
3)Верификатор.
Ага. Так как предыдущая стадия может молча выдать пургу мы проверяем дерево.
Благо верификакор можно создать без всяких эвристик.
Кстати для него тоже нет разницы между кодом и метакодом.
Ошибки на этой стадии трактуются исключительно как ICE.
4)Сериализация дерева в файл.
На этом работа фронтенда заканчивается.
Заметь фронтенд занимается только синтаксическим уровнем метакода (если он вообще есть). На этой стадии метакод не порождают никакого кода.

Теперь бекенд:
5)Десериализация дерева из файла.
6)Верификатор.
Ага. Тот самый что был в пункте 3.
В этот раз мы защищаемся от ошибок при сериализации/десериализации и от намеренных или нет искажений файла.
7)Частичное выполнение.
Именно на этой стадии происходит раскрутка метакода.
Причем все работает по очень простым правилам.
8)Оптимизация.
9)Генерация нативного кода.

Если нам не нужно сохранять модуль на диск стадии 4, 5 и 6 могут быть пропущены.

Также у меня есть подозрение что верификатор полностью или около того можно заменить системой типов. Что было бы гораздо предпочтительнее. И кода нужно будет меньше и количество ICE уменьшится.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Noop - новый язык для JVM
От: Andrei F.  
Дата: 28.09.09 15:55
Оценка:
Здравствуйте, nikov, Вы писали:

N>Насколько я понял, там поддерживается kind polymorphism, что довольно уникально.


А можно объяснить идею вкратце?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[21]: Noop - новый язык для JVM
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 17:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А мне подход с системой типов нравится гораздо больше.

WH>1)Мы в очень широком смысле не можем написать метафункцию не правильно.

Опыт исползования МП в С++ убеждает меня в обратном.
К тому же ошибки бывают разные. Формально правильная функция может генерировать логически неверный код. И как его тогда отлаживать?

WH>2)Метафункция не может порождать не правильный код. Те все ошибки увидит разработчик матафункции, а не пользователь метафункции.


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

WH>3)Если пользователь метафункции попытается не правильно ее использовать ему об этом расскажет компилятор.


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

WH>4)Благодоря строгому отделению мух от котлет мы упрощаем сам компилятор.


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

Что будет в случае навороченной системы типов?

Можно ли будет заставить систему типов обращаться ко внешним источникам данных?

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

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

WH>В том же компиляторе немерла в алгоритме вывода типов есть куча приседаний вокруг макросов.


Да, ну? Приведи, плиз, хотя бы один пример.

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


Исходная посылка не верна. Так что все выводы идут в топку.
А вот то, что система типов у этого чуда будет гораздо навороченнее (при том, что количество поддерживаемых типов и их возможности даже по проще) — это точно.

WH>В случае с навороченной системой типов система разваливается на несколько весьма изолированных слоев:

WH>1)Парсер.
WH>Если делать парсер на основе PEG то мы практически бесплатно получаем расширяемый во все стороны парсер.
WH>На этой стадии мы сообщаем программисту об ошибках разбора текста.
WH>Также мы производим переписывание из красивых синтаксических конструкций в вызовы метафункций.
WH>2)Вывод типов. Разрешение перегрузки и тп.

В приведенной ситеме типов перегрузки (не считая классов типов) и сабтайпинг не поддерживается.

WH>Так как для вывода типов разницы между функцией и метафункцией нет мы получаем серьезное упрощение самой сложной части фронтенда.


Упрощения я не вижу. Усложнение вижу.

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

WH>Данная стадия основной источник ошибок времени компиляции.

WH>В случае если ошибок компиляции не обнаружено на выходе этой стадии мы получаем дерево которое можно сразу скормить бекенду.
WH>Однако так как по всей видимости для навороченных систем типов построить полный и не противоречивый вывод типов невозможно мы будем вынужденны использовать эвристики.
WH>Как следствие эта стадия может дать неправильное дерево.

И это тоже. В общем, тут только практика может показать. Есть некоторые "за" и некоторые "против".

WH>Кстати для него тоже нет разницы между кодом и метакодом.

WH>Ошибки на этой стадии трактуются исключительно как ICE.

ICE — это ошибка в компиляторе. Неверно предположение программиста писавшего часть кода компилятора, или изменения в другой части компилятора повлиявшее на ту часть в которой возникло ICE. Так что ICE может быть в любом компиляторе (и есть в любом).

WH>4)Сериализация дерева в файл.

WH>На этом работа фронтенда заканчивается.
WH>Заметь фронтенд занимается только синтаксическим уровнем метакода (если он вообще есть). На этой стадии метакод не порождают никакого кода.

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

Кроме того важно еще как схема компиляции будет уживаться с такими вещами как IDE. Макры уже тяжел подружить с IDE, а метакод на основе типов высшего порядка может вообще быть не совместим с IDE. А может наоборот. Тут без исследований не обойтись. На это уйдут годы.

WH>Теперь бекенд:

WH>5)Десериализация дерева из файла.
WH>6)Верификатор.
WH>Ага. Тот самый что был в пункте 3.
WH>В этот раз мы защищаемся от ошибок при сериализации/десериализации и от намеренных или нет искажений файла.
WH>7)Частичное выполнение.
WH>Именно на этой стадии происходит раскрутка метакода.

Метакод в бэкэнде? А как ты все это отлаживать то будешь?


WH>Также у меня есть подозрение что верификатор полностью или около того можно заменить системой типов. Что было бы гораздо предпочтительнее. И кода нужно будет меньше и количество ICE уменьшится.


Опять же на все подозрения придется убить еще несколько лет (или десятков).

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

Меж тем акры уже изучены и с ними все понятно. Естественно, что склоняешься к тем решениям которые более изучены.
Собственно я не спорю. Я могу быть не прав и все опасения могут быть напрасными. Но времени на их проверки у меня нет.

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

Так вот генерировать красивые идеи читая чужие дисеры — это конечно интересно, но довольно бесполезно. А вот сделать что-то законченное и применимое на практике — это большой и неблагодарный труд. Но только сделав его можно получить продукт который действительно сможет поднять производительность программиста.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Noop - новый язык для JVM
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 17:23
Оценка: 2 (1)
Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, VladD2, Вы писали:


VD>>Основная их проблема — излишняя заформализованность.


AF>Вот-вот. В этих мануалах черт ногу сломит. Но мне была интересна сама концепция, что это за хитрая система типов. Она же вроде бы не уникальная для этого языка?


http://rsdn.ru/forum/decl/3546753.1.aspx
Автор: palm mute
Дата: 24.09.09
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Noop - новый язык для JVM
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.09.09 18:09
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>И я с этим согласен.


А я — нет. Как тот самый производитель программ, смею тебя заверить — мы добавляем только те фичи, которые, как мы считаем, будут очень полезны большому количеству народу (и нам самим в том числе). И хотел бы я знать, как можно зарабатывать на фичах бесполезных.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[22]: Noop - новый язык для JVM
От: WolfHound  
Дата: 28.09.09 19:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Опыт исползования МП в С++ убеждает меня в обратном.

Опыт использования С++ убеждает меня что функции высшего порядка фигня! Посмотри на stl.
Мысль понятна?
В любом случае все последующие апелляции к С++ будут игнорироваться. Ибо язык сильно не той системы.

VD>К тому же ошибки бывают разные. Формально правильная функция может генерировать логически неверный код. И как его тогда отлаживать?

Отладчиком разумеется.
С отладкой тут как раз все будет очень просто.
Так как код не отличим от метакода мы можем отлаживать метакод тем же отладчиком. Для удобства в отладчике будет флажок заглядывать в метакод или не надо.

VD>Где преимущества, так и ограничения. Камил в своей работе посвященной макрам как раз писал о том, что он выбрал работу с нетипизированным АСТ именно потому, что типизированные макры слишком сковывают свободу и в итоге порождают намного более сложные решения при весьма посредственных возможностях.

В данном случае работа идет не с AST.
Тут используется другой метод мета-программирования.

VD>А вот на счет строгости вообще большие сомнения. Как раз макра отдаляет все очень хоршо. Макры понятны и очевидны.

Тебе.
А лично меня очень сильно напрягают совершенно не формализованные потроха компилятора.

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

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

VD>Можно ли будет заставить систему типов обращаться ко внешним источникам данных?

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

WH>>В том же компиляторе немерла в алгоритме вывода типов есть куча приседаний вокруг макросов.

VD>Да, ну? Приведи, плиз, хотя бы один пример.
DelayMacro и вся байда которая с этим связана.
Да и на тот же foreach посмотри... сколько там присаданий.

VD>А вот то, что система типов у этого чуда будет гораздо навороченнее (при том, что количество поддерживаемых типов и их возможности даже по проще) — это точно.

Система то будет навороченее но выделенное далеко не факт.

VD>В приведенной ситеме типов перегрузки (не считая классов типов) и сабтайпинг не поддерживается.

Ну так они и в ML не поддерживаются. Но это не мешает немерлу их поддерживать.

WH>>Так как для вывода типов разницы между функцией и метафункцией нет мы получаем серьезное упрощение самой сложной части фронтенда.

VD>Упрощения я не вижу. Усложнение вижу.
Простите но единообразная работа с кодом и метакодом это как ни крути упрощение.

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

Совершенно не придется.

VD>И это тоже. В общем, тут только практика может показать. Есть некоторые "за" и некоторые "против".

Так и немерле то и дело попадается на генерации невалидного кода.
Так что это нужно всем компиляторам...

VD>ICE — это ошибка в компиляторе. Неверно предположение программиста писавшего часть кода компилятора, или изменения в другой части компилятора повлиявшее на ту часть в которой возникло ICE. Так что ICE может быть в любом компиляторе (и есть в любом).

Ну да.
Только если верификатор поймал ошибку в сгенерированном компилятором коде то это самое натуральное ICE. Ибо компилятор не должен генерировать неправильный код.
Считай это встроенным в компилятор PEVerify

VD>Кроме того важно еще как схема компиляции будет уживаться с такими вещами как IDE. Макры уже тяжел подружить с IDE, а метакод на основе типов высшего порядка может вообще быть не совместим с IDE. А может наоборот. Тут без исследований не обойтись. На это уйдут годы.

Я думаю что наоборот.

VD>Метакод в бэкэнде? А как ты все это отлаживать то будешь?

См выше.

WH>>Также у меня есть подозрение что верификатор полностью или около того можно заменить системой типов. Что было бы гораздо предпочтительнее. И кода нужно будет меньше и количество ICE уменьшится.

VD>Опять же на все подозрения придется убить еще несколько лет (или десятков).
Не уйдут.
Я даже где то видел статью в которой зависимыми типами проверяли дерево в интерпретаторе.
Тут ровно тоже самое.
Так что это даже не подозрение, а почти 100% уверенность.

VD>Меж тем акры уже изучены и с ними все понятно. Естественно, что склоняешься к тем решениям которые более изучены.

Угу. На foreach посмотри.

VD>Собственно я не спорю. Я могу быть не прав и все опасения могут быть напрасными. Но времени на их проверки у меня нет.

А я тебе и не предлагаю. Я просто изложил свои соображения на этот счет.

VD>Приведу один пример.

VD>Ты мне очень красиво расписал как хорош PEG и Packrat.
Я только про PEG писал. С Packrat все было ясно с самого начала.

VD>Как и в данном случае сразу (без тестирования или анализа) заявил, что это офигительно и проблем там нет. Пообещал написать построитель парсеров (там типа работы было не много) который выдавал бы офигительно быстрые парсеры.

Строки давно он матчит. И матчит быстро.
Осталось сделать построение дерева и поддержку левой рекурсии.

VD>Понятно куда я веду?

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

VD>Так вот генерировать красивые идеи читая чужие дисеры — это конечно интересно, но довольно бесполезно.

Меня очень давно не устраивают современные языки. По этому я читаю диссеры и генерирую идеи.
Начал я это делать еще до того как ты немерлом увлекся.
А когда из диссеров и идей сложу мозаику в единую систему типов которая даст мне все что я хочу от языка программирования вот тогда я и начну действовать в этом направлении активно.
А пока этого нет я буду читать диссиры, генерировать идеи и скармливать эти идеи общественности. Пусть проверяет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: Noop - новый язык для JVM
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 20:22
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, VladD2, Вы писали:


VD>>Опыт исползования МП в С++ убеждает меня в обратном.

WH>Опыт использования С++ убеждает меня что функции высшего порядка фигня! Посмотри на stl.
WH>Мысль понятна?



WH>В любом случае все последующие апелляции к С++ будут игнорироваться. Ибо язык сильно не той системы.


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

VD>>К тому же ошибки бывают разные. Формально правильная функция может генерировать логически неверный код. И как его тогда отлаживать?

WH>Отладчиком разумеется.

Не...а. Отладчики пока что не умеют отлаживать вычисления в типах. Более того оные проходят в недрах компилятора и выделенной фазы не имеют.

WH>С отладкой тут как раз все будет очень просто.


Не убедил.

WH>Так как код не отличим от метакода мы можем отлаживать метакод тем же отладчиком. Для удобства в отладчике будет флажок заглядывать в метакод или не надо.


А с чего бы это код не отличим от метакода? Ты не забыл, что это не Немерле. В Ur предлагается писать метакод на базе типов высшего порядка. Как я понимаю — это совершенно другой язык нежели прикладной.

VD>>Где преимущества, так и ограничения. Камил в своей работе посвященной макрам как раз писал о том, что он выбрал работу с нетипизированным АСТ именно потому, что типизированные макры слишком сковывают свободу и в итоге порождают намного более сложные решения при весьма посредственных возможностях.

WH>В данном случае работа идет не с AST.

Возможно ты прав. А возможно нет. Без экспериментов и научной базы это не установить.

WH>Тут используется другой метод мета-программирования.


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

VD>>А вот на счет строгости вообще большие сомнения. Как раз макра отдаляет все очень хоршо. Макры понятны и очевидны.

WH>Тебе.
WH>А лично меня очень сильно напрягают совершенно не формализованные потроха компилятора.

Причем тут форматирование?

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

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

VD>>Что будет в случае навороченной системы типов?
WH>Метакод и код вообще говоря не различимы.

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

WH>На входе данные и на выходе данные.


Это пустые слова. Они и для макросов справедливы. Вопрос только в типе этих данных.

WH>Типы и их структура это тоже данные.

WH>Таким образом метафункция это просто код который что-то считает.

Ну, и макры — это тоже код который что-то считает.

WH>Но благодаря частичному выполнению весь оверхед связанный с обсчетом констант вообще и типов в частности исчезает.

WH>Те фактически раскруткой метакода у нас занимается оптимизатор.

Мне кажется от слов нужно перейти к примерам.

VD>>Можно ли будет заставить систему типов обращаться ко внешним источникам данных?

WH>Нельзя. Но если очень хочется то можно.

Так можно или нельзя? Потому как если нельзя, то в топку.

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


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

WH>В языках с неизменяемыми типами данных в ресурсах можно хранить не только и не столько блобы, а любые неизменяемые структуры данных.


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

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


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

WH>После чего любая функция в том числе метафункция сможет обратиться к этим данным.


Напоминает анекдот когда мужик предложил классный способ бороться с самолетами противника. Когда они подлетают к границе, то переворачиваются и падают. На вопрос как это реализовать он ответил "- Ну, вы же учерые! — Вы идумйте!".

WH>>>В том же компиляторе немерла в алгоритме вывода типов есть куча приседаний вокруг макросов.

VD>>Да, ну? Приведи, плиз, хотя бы один пример.
WH>DelayMacro и вся байда которая с этим связана.

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

WH>Да и на тот же foreach посмотри... сколько там присаданий.


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

VD>>А вот то, что система типов у этого чуда будет гораздо навороченнее (при том, что количество поддерживаемых типов и их возможности даже по проще) — это точно.

WH>Система то будет навороченее но выделенное далеко не факт.

Факт. Следует из описания языка. Там сказано, что поддерживаются структуры и записи. Сам понимаешь, что система типов дотнета сильно навороченее.

VD>>В приведенной ситеме типов перегрузки (не считая классов типов) и сабтайпинг не поддерживается.

WH>Ну так они и в ML не поддерживаются. Но это не мешает немерлу их поддерживать.

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

WH>>>Так как для вывода типов разницы между функцией и метафункцией нет мы получаем серьезное упрощение самой сложной части фронтенда.

VD>>Упрощения я не вижу. Усложнение вижу.
WH>Простите но единообразная работа с кодом и метакодом это как ни крути упрощение.

Где там единообразие? Ты даже к ресурсам обратиться не можешь.

VD>>И это тоже. В общем, тут только практика может показать. Есть некоторые "за" и некоторые "против".

WH>Так и немерле то и дело попадается на генерации невалидного кода.

В нем этот код можно материализовать (сгенерировать текст) и посмотреть. А что будем делать с сообщениями об ошибках при обработке "35-го" порядка?

WH>Так что это нужно всем компиляторам...


Ты пробовал ставить и использовать этот самый Ur?

VD>>ICE — это ошибка в компиляторе. Неверно предположение программиста писавшего часть кода компилятора, или изменения в другой части компилятора повлиявшее на ту часть в которой возникло ICE. Так что ICE может быть в любом компиляторе (и есть в любом).

WH>Ну да.
WH>Только если верификатор поймал ошибку в сгенерированном компилятором коде то это самое натуральное ICE. Ибо компилятор не должен генерировать неправильный код.

С макрами все просто. Как бы они не изгалялись в итоге они должны породить нетипизированное АСТ которое уже будет подвергаться типизации. Так что при качественном компиляторе ICE не должно быть. Только жизнь есть жизнь. Ошибки в компиляторе случаются. Плюс, конечно, неограниченная мощь макросов может тупо все сломать ни смотря ни на что.
Но неограниченная немощь тоже плохо. Так что если метакод будет ограничен — это будет очень плохо.
Как я уже говорил, метакод обязан иметь возможность обращаться к внешним ресурсам (пусть и только на чтение), и обязан иметь возможность выдавать сообщения об ошибках.

WH>Считай это встроенным в компилятор PEVerify


Звучит хорошо... в теории.

VD>>Кроме того важно еще как схема компиляции будет уживаться с такими вещами как IDE. Макры уже тяжел подружить с IDE, а метакод на основе типов высшего порядка может вообще быть не совместим с IDE. А может наоборот. Тут без исследований не обойтись. На это уйдут годы.

WH>Я думаю что наоборот.

Что наоборот? Тебе ничего не придется делать и все чудесным образом интегрируется в IDE?

VD>>Опять же на все подозрения придется убить еще несколько лет (или десятков).

WH>Не уйдут.

Где гарантии?

WH>Я даже где то видел статью в которой зависимыми типами проверяли дерево в интерпретаторе.

WH>Тут ровно тоже самое.
WH>Так что это даже не подозрение, а почти 100% уверенность.

"почти 100% уверенность" — это надо запомнить!

VD>>Меж тем акры уже изучены и с ними все понятно. Естественно, что склоняешься к тем решениям которые более изучены.

WH>Угу. На foreach посмотри.

Смотрел. Он есть и работает в 10 раз лучше встроенного в шарп. А где посмотреть на аналог на ЗТ?

VD>>Собственно я не спорю. Я могу быть не прав и все опасения могут быть напрасными. Но времени на их проверки у меня нет.

WH>А я тебе и не предлагаю. Я просто изложил свои соображения на этот счет.

Ну, а что толку с соображений? Ты что-то конкретное предлагаешь?

Пойми, я не спорю, что в этом что-то есть. Но так же я жопой чую, что в это есть куча проблем, а "правильное решение" (с) где-то по середине. Я так же как ты "почти 100% уверен", что без связи с внешним миром МП — это вещь в себе которая никому не нужна.

VD>>Приведу один пример.

VD>>Ты мне очень красиво расписал как хорош PEG и Packrat.
WH>Я только про PEG писал. С Packrat все было ясно с самого начала.

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

VD>>Как и в данном случае сразу (без тестирования или анализа) заявил, что это офигительно и проблем там нет. Пообещал написать построитель парсеров (там типа работы было не много) который выдавал бы офигительно быстрые парсеры.

WH>Строки давно он матчит. И матчит быстро.

Дык строки давно и успешно матчатся регекспами. И, что характерно, тоже быстро.

WH>Осталось сделать построение дерева и поддержку левой рекурсии.


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

VD>>Понятно куда я веду?

WH>Я конечно понимаю что тебе очень хочется чтобы я что-то написал для немерле. И если ты помнишь я таки даже написал и это даже маленько разогнало компилятор.

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

Знаешь сколько красивых идей я выбросил (за свою жизнь) только потому, что на практике в них оказалось очень много нюансов? R#-помнишь? И это только верхушка айсберга. Алгоритмов было намного больше.

WH>В любом случае я изначально не считал немерле приделом своих мечтаний. Вернее он и близко там не стоял. Просто под .НЕТ ничего лучше нет.


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

Те же ЗТД — это интересная идея. Весьма перспективная. Но законченной концепции и тем более решения на них нет и не будет ближайшие 5 лет.

Лично мне не нужен язык тольтко потому, что в нем реализованы некие ЗТД. Мне нужен язык решающий мои проблемы как программиста. Если ЗТД помогут мне в этом — замечательно. Если нет, ну и хрен бы с ними. В любом случае они должны решать те проблемы которые нужно решать мне, а не я должен подстраиваться под их ограничения. В общем, дизайн не должен вестись от возможностей. Он должен вестись от потребностей.

VD>>Так вот генерировать красивые идеи читая чужие дисеры — это конечно интересно, но довольно бесполезно.

WH>Меня очень давно не устраивают современные языки. По этому я читаю диссеры и генерирую идеи.

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

WH>Начал я это делать еще до того как ты немерлом увлекся.

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

Так можно всю жизнь прождать.

WH>А пока этого нет я буду читать диссиры, генерировать идеи и скармливать эти идеи общественности. Пусть проверяет.


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

Вот простой вопрос. Если у нас есть макросы, то мы можем оформлять их синтаксис с использованием EBNF (как мы это обсуждали). При этом сложность распознавания синтаксиса перекладывается на механизмы автоматического построения парсеров (встроенного в язык). А как быть с метасистемой построенной на базе ЗТД?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.