LINUX.ORG.RU

Glasgow Haskell Compiler 6.10.1

 ,


0

0

Вышел долгожданный релиз наиболее распространенного компилятора языка Haskell — Glasgow Haskell Compiler 6.10.1.

В новой версии:

И многое другое!

Страница GHC

>>> Анонс



Проверено: Shaman007 ()
Ответ на: комментарий от www_linux_org_ru

>1. То что делается на монадах в Хаскеле, можно прямо сделать в С++, тоже на монадах или прямее ( MayBe монада на С++: http://kerneltrap.org/node/7488 )

ну ни фига ж себе прямее

>2. Как сделать в хаскеле то, что прямо делается в плюсах, например, как там самому наваять монаду для че-нить совсем непроцедурного... ну например SDL нам дает прямой доступ к двумерной видеопамями, как для этого написать монаду(монады)?

вообще задачи не понял. можно то же самое, но по-человечески? :)

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

>> ...на монадах или прямее ...

> ну ни фига ж себе прямее

берем словарь и выясняем значение слова "или"

> вообще задачи не понял. можно то же самое, но по-человечески?

Упрощенно совсем: есть у тебя char videomemory[1600*1200*4] -- это двумерная память прямо видеодаптера; ее надо из хаскеля напрямую адресовать, дабы там линии чертить хотя бы и квадратики-кружочки рисовать. А еще перед тем, как адресовать и рисовать, ее надо залочить, а порисовав -- отдать лок.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от jtootf

>> ...на монадах или прямее ...

> ну ни фига ж себе прямее

Если тебя синтаксис плюсовый испугал -- то в общем я согласен, он ужасный, но у хаскеля не сказал бы что намного лучше.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

В смысле у хаскеля синтаксис поприятнее чем у с++, но не намного.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

2 www_linux_org_ru ктото там писал про гланды через жопу. это чтото вроде функционального программирования на C++ и массивов на haskell, да?

anonymous
()
Ответ на: комментарий от www_linux_org_ru

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

[s]А программист на ассемблере[/s]

Вот-вот, это значит, что компилятор C++ ничего за программиста не проверит.

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

> и это состояние можно менять более прямым и ясным способом, чем монады.

WTF?

modify (здесь функция состояние -> состояние) - это сложно?

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

> [s]А программист на ассемблере[/s]

А что может программист на ассемблере, чего не может программист на С++?

> Вот-вот, это значит, что компилятор C++ ничего за программиста не проверит. Серьёзно, попробуй сделать STM на языке, который не видит разницы между чистыми и нечистыми функциями. Получится говно.

STM = software transactional memory ?

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Miguel

> Вот-вот, это значит, что компилятор C++ ничего за программиста не проверит. Серьёзно, попробуй сделать STM на языке, который не видит разницы между чистыми и нечистыми функциями. Получится говно.

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

> 2 www_linux_org_ru ктото там писал про гланды через жопу. это чтото вроде функционального программирования на C++ и массивов на haskell, да?

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

Но в результате я по крайней мере пойму, чего мне в плюсах не хватает.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

Та же STM - вполне маленькая. Вот тебе чуть-чуть упрощённый вариант:

Есть набор переменных в памяти. Для простоты будем считать, что все они - типа int.

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

Конкретнее, нужны следующие примитивы:

а) Прочитать данную переменную - на входе - какой-то идентификатор переменной, на выходе - значение.

б) Записать значение в данную переменную - на входе - идентификатор переменной и значение, на выходе - ничего.

в) Выполнить некое вычисление АТОМАРНО. То есть, внутри этого вычисления мы можем забыть о существовании других потоков, и ничего не сломается.

Ну, например (псевдокод):

atomically {c := read counter; write counter (c+1)}

При этом, если несколько потоков выполняют этот код одновременно, то счётчик будет увеличен на 1 столько раз, сколько раз код будет выполнен. Информация не должна теряться. Кроме того, не должны возникать взаимоблокировки.

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

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

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

> STM эту задачу решает. Однако при этом возникает следующая вещь: вычисление внутри atomically может быть произведено несколько раз. Грубо говоря, STM перезапускает вычисление, если, производя запись в переменную, выясняет, что в эту переменную писал кто-то ещё. Если при этом сайд-эффектом вычисления является запуск ракет, то я не уверен, что повторение этого несколько раз - тот эффект, который нам нужен.

Я понял задачу. Посмотрю, можно ли на плюсах написать что-то похожее. Хотя есть замечания:

А если наш побочный эффект -- это не запуск ракет, а сбор статистики или отладка? (Как с этим в хаскеле?)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Miguel

Я немного отвлекусь и опишу случай (почти из жизни), когда STM имхо не подходит, а нужна именно блокировка.

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

Здесь случай "обе нити запросили один адрес" не подходит именно из-за экономии ресурсов (сайт лимитирует к-во скачанных страниц в час с одного прокси). Если какая-то нить уже залочила адрес для закачки, другая не должна его повторно качать. Конечно, все зависит от вероятности коллизий, но она м.б. достаточно большой, *особенно* если мы качаем не "все что на глаза попадется", а пытаемся полностью скачать сначала одну маленькую часть сайта, потом другую, ... Именно из-за этого, когда маленькая часть сайта заканчивается, вероятность коллизии будет весьма большой.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>случай (почти из жизни), когда STM имхо не подходит

А кто сомневался, что они есть?

>а нужна именно блокировка

Вот для этой задачи (imho) блокировка не нужна.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

> А кто сомневался, что они есть?

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

> Вот для этой задачи (imho) блокировка не нужна.

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Я в этой ветке форума очень неточно выражался.

STM я понимал как "STM в функциональном стиле", т.е. STM без локов и с перезапуском с новыми данными вместо лока. Так что:

1. Мой пример показывает необходимость STM с локами, т.е. STM в процедурном стиле.

2. Хотелось бы увидеть пример STM в функциональном стиле, из жизни или почти из жизни.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>Предложи, как эту задачу решать без блокировки отдельных адресов

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

DonkeyHot ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.