не понял оба предложения. 1.Придётся делать dup входного параметра или замыкания? 2. Какие более базовые операции, чем while / cond?

1) Придется делать dup параметра, перед тем как сделать prepend к замыканию. После этого, правда, можно сделать dup самому замыканию, если оно не становится unduppable. 2) Эээ? Рекурсию отменили?

Можно ещё сделать операцию view для получения слепка линейной переменной на момент вызова

1) Придется делать dup параметра, перед тем как сделать prepend к замыканию. После этого, правда, можно сделать dup самому замыканию, если оно не становится unduppable. 2) Эээ? Рекурсию отменили?

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

это в любом случае сводится к сортам вайла как к сортам рекурсии

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

это в любом случае сводится к сортам вайла как к сортам рекурсии

И блок-то может вообще начинаться с view, после чего его можно использовать где угодно

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

линейные ведь не просто unduppable, они ещё и must use

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

ну как говорил, есть разные замыкания, их гораздо больше, чем два вида

Что мешает запретить для них и drop тоже? Если язык продуман корректно, то у тебя не должно быть способа избавиться от/удвоить линейную переменную на стеке.

И блок-то может вообще начинаться с view, после чего его можно использовать где угодно

что такое view?

#а S -> а #а S кладет на стек копию текущего состояния линейной переменной

#а S -> а #а S кладет на стек копию текущего состояния линейной переменной

ммммммм, совсем запутался. Откуда у линейной переменной копии?

#а - это линейная или интуиционисткая?

Да не у переменной копия, а у её текущего состояния. Переменная дальше может меняться, а копия остаётся "замороженной". Линейная.

Да не у переменной копия, а у её текущего состояния. Переменная дальше может меняться, а копия остаётся "замороженной". Линейная.

Кажется, такое копирование противоречит всему, что я знаю про линтипы. Многие из них просто принципиально не "замораживаемо-копируемы"

Это как readIORef

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

Чтобы ты не мог скопировать саму переменную вместе с её возможностью меняться, но мог выяснить её состояние

Это как readIORef

Но линейная переменная она гораздо дальше, чем IORef в семантике. Что если копия состояния содержит какие-то технические указатели например на хэндл для чтения из файлов и этот снэпшот переживёт закрытие файла?

Ну или если мы говорим о квантовых вычислениях, у нас вообще нет снэпшотов состояния

Тогда надо сделать подкласс линейных типов, которым можно сделать view

Где мы, а где квантовые вычисления :)

Ну на самом деле обычно делают наоборот, просто !А, и функцию !A -> A

ну или точнее !(!A -o A)

вместо viewable - тот факт, что интуиционистскую переменную ты можешь отсекать как линейный разовый срез

Результат перестает быть линейным, или его линейность встроена в -о?

Результат перестает быть линейным, или его линейность встроена в -о?

не, там наоборот A - это линейная, а экспонента !A - многоразовая интуиционистская

А, вот оно что

вообще странно что файервол может так избирательно блокировать

Переменная среды %http_proxy% случайно определена?

Переменная среды %http_proxy% случайно определена?

Ща гляну

Переменная среды %http_proxy% случайно определена?

нет, не определена

Значит действительно чудеса)

да, обидно ) совсем нет идеи как починить )

Проблема.

computeOffsets :: [ASMLine] -> [ASMLine] computeOffsets [] = [] computeOffsets (a:as) = let t = length (uniteBytecode (a:as)) v = foldl (+) 0 [ t - length (bytecode x) | x <- as ] in a {offset = v}: computeOffsets as

t = length (uniteBytecode (a:as)) выполняется много раз, а надо чтоб один. При этом хотелось бы обойтись без do

хотя тут наверное непонятно у меня

uniteBytecode :: [ASMLine] -> String uniteBytecode asm = foldl (++) "" [ bytecode x | x <- asm ]

* encounters line break after let * throw `ParseError`s

data ASMLine = ASMLine -- String String { instr :: String , operand :: String , bytecode :: String , offset :: Int } deriving (Eq)

ну мне удобнее line break after let

строчки экономлю

оно 100% законно

Да так даже читаемее, на самом деле. > bytecode :: String Я вот не помню. Любая ли байтовая последователность ли представима в виде Char? foldl (++) "" можно смело заменить на concat или mconcat. Экономишь туалетную^W бумагу для принтера?

ага, спс

> Любая ли байтовая последователность ли представима в виде Char? да, но зачем

Во, ещё лучше! uniteBytecode = (bytecode =<<)

код считает оффсеты строчки от начала

а получаются оффсеты от конца

foldl (+) 0 заменимо на sum

Во, ещё лучше! uniteBytecode = (bytecode =<<)

э, это че?

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

t - length (bytecode x)

type String = [Char] bytecode :: ASMLine -> String => bytecode :: ASMLine -> [Char] concatMap :: (a -> [b]) -> [a] -> [b] (flipped concatMap) assume a ~ ASMLIne, b ~ Char => concatMap bytecode :: ASMLine -> [Char] => concatMap bytecode :: ASMLine -> String

В общем, uniteBytecode = concatMap bytecode, что выражает

@termslang чтобы не считать два раза, можно протащить параметр-аккумулятор длины

И попытайся выразить через foldl или foldr

Всю computeOffsets, я имею ввиду. Кстати, зачем compute? Почему просто не offsets?

Мы ж не в жаве

потому что оно будет меняться тыщу раз

Что будет меняться-то? У нас тут иммутабельность и функциональная чистота, вроде как

Достаточно просто написать в документации, что оно O(n^2), например

у меня все норм с иммутабельностью

вот main

module Main where import System.Environment import Emasm main :: IO () main = getArgs >>= return . head >>= readFile >>= return . parseAsmFileContents >>= return . unfoldPseudoasm -- >>= return . splitInitSection >>= return . computeBytecode -- >>= return . uniteBytecode -- >>= return . addLoader -- >>= print >>= mapM_ print

Технически, можно сделать zip... господи

offsets больше звучит как переменная

У нас тут своя атмсфера и переменные живут в модулях Data.IORef и Control.Concurrent. Ты из принципов не используешь do-syntax?

говорят это плохо

Кто?

https://wiki.haskell.org/Do_notation_considered_harmful

Исходную задачу можно сделать, как zip asmLines (scanl _offset [] (map bytecode asmLines)), и останется реализовать только _offset.

https://wiki.haskell.org/Do_notation_considered_harmful

там не написано, что плохо, написано что иногда плохо

Ньюкомерс майт think

Если поискать, можно и мнение о том, что Monads considered harmful найти. Зачем верить всему подряд?

Ну понятно. Кто автор?

ну без монад никак же

а без do можно

аргументация норм вроде

И без монад можно, какие проблемы

+1, на продолжениях всё делать, как в '92 было

как в Node.js

Надо на самом деле надо прочитать просто эту статью в вики

и там примерно во втором абзаце, в топике Didactics написано, что имеется ввиду

А не только её заголовок :)

ну где-то кроме монад do лепить точно не надо

а где-то кроме монад в хаскелле можно?

там побочные жффекты описываются

ApplicativeDo ?

Где-то кроме монад заюзать do-нотацию будет затрднительно, потому как оно переписывается в вызовы (>>=) и (>>), ну и (*>), да

В общем, нормально все с do-нотацией, ее вполне можно использовать, часто она улучшает читаемость кода.

В monadic expression описывается последовательность действий, если что

ApplicativeDo ?

о, норм, не видел такого

Вброшу https://blog.jle.im/entry/io-monad-considered-harmful.html

На самом деле клево было бы в целом просто отвязать do-нотацию от монад, аппликативов и привязать просто к оператору >>=

{-# language RebindableSyntax #-}?

https://ocharles.org.uk/blog/guest-posts/2014-12-06-rebindable-syntax.html @termina1