LINUX.ORG.RU

отображение объект на память в haskell

 ,


0

7

Добрый день! Подскажите, есть ли в haskell принципиальная возможность «отобразить» объект некоторого типа на произвольный адрес в памяти? Т.е., имея зарезервированную область памяти, выбрать в рантайме какой объект там будет храниться (стандартными средствами или подключаемой библиотекой)


Ответ на: комментарий от jcdr

В стандартном хаскеле — нет. В недрах GHC, емнип, были какие-то «primitive» и «unboxed» типы. Можно ли их отображать на память — не знаю

buddhist ★★★★★ ()

тоже недавно мелькала такая мысль (в смысле «а можно ли»). чисто из любопытства. Но хаскель-репорт открыть руки не дойдут.. ты б прочитал, если есть время, да рассказал..

AndreyKl ★★★★★ ()

Мощные у тебя грибы. На тему подписался.

DELIRIUM ☆☆☆☆☆ ()

отобразить - Storable, как храниться в общем случае нельзя, можно контролировать боксинг при помощи {-# UNBOX #-}.

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

и чем он поможет в том, чтобы указать, как хранятся данные? Они все так хранятся:

https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects

Дальше есть уровень извращений, можно по идее складывать объект в ByteArray# или unboxed tuples, но и там возможности достаточно ограничены, и это не будет честным Haskell Value, так что работать как обычно не получится.

Так что простой ответ это можно частично контролировать layout через bang pattern и прагму {-# UNBOX #-}, но с т.з. сишника это все для бедных.

qnikst ★★★★★ ()

Не очень понятен набор предполагаемых действий над таким отображением. Для каких целей это нужно? Сборщик мусора работает с Haskell heap и двигает объекты. Вычислитель перезаписывать граф в Haskell heap. Нужно ли сохранять эти свойства?

В GHC можно выделять разную память: heap, pinned heap, stack, foreign memory (malloc, mmap).

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

Хотел сказать, что прямое управление памятью — удел, как ни странно, языков с прямым управлением памятью, а в этом вашем хачкеле и памяти-то никакой нет, одни функции да их применения-композиции.

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

что прямое управление памятью

А есть принципиальное отличие между прямым и косвенным управлением памятью? Ты, скармливая GC те или иные объекты можно считать, что управляешь памятью.

filequest ()
Ответ на: комментарий от Softwayer

а в этом вашем хачкеле

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

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

Следишь за мной да? Это хорошо. За тобой тоже следят.

Dennis7 ()
Ответ на: комментарий от filequest

Ну в хаскеле я не создаю никаких объектов в памяти и, соответственно, никому их не скармливаю. Код наподобие

map f (x:xs) = (f x) : map f xs
map _ [] = []
определяет функцию, а какие объекты где компилятор создаст при её вызове — его дело. Может, это поведение где-то и специфицировано, но оно для меня не имеет значения (по крайней мере, до тех пор, пока не настаёт время оптимизировать производительность) — насколько я понимаю, в этом и есть суть декларативности языка.

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

Реальность конечно же сильно отличается от идеала. Вопросы про управление памятью не исчезают, но уходят в другую плоскость и начинают требовать других компромиссов. Не зря же Haskell в управление памятью принёс новый термин «space leak».

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

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

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

P.S. У тебя скобки вокруг f x лишние.

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