Discreet · and · discrete.

So, this is hardly news:

Dynamic Applications From the Ground Up
Don Stewart and Manuel M. T. Chakravarty
School of Computer Science and Engineering
University of New South Wales
Sydney, Australia

Accepted for the Haskell Workshop, 2005.

Abstract
Some Lisp programs such as Emacs, but also the Linux kernel (when fully modularised) are mostly dynamic; i.e., apart from a small static core, the significant functionality is dynamically loaded. In this paper, we explore fully dynamic applications in Haskell where the static core is minimal and code is hot swappable. We demonstrate the feasibility of this architecture by two applications: Yi, an extensible editor, and Lambdabot, a plugin-based IRC robot. Benefits of the approach include hot swappable code and sophisticated application configuration and extension via embedded DSLs. We illustrate both benefits in detail at the example of a novel embedded DSL for editor interfaces.

Про кодирование и сравнение АТД.

Пока у меня мысль использовать Template Haskell.

Сперва создаётся функция: f :: T1 -> T2 -> T3 -> ... -> ((T1,T2,...,Tm),(Tm+1,...,Tn)); f a b ... = expr where ..., ни один из параметров не должен содержать переменные типа (мы не можем для них вывести какой-то способ кодирования и нам неизвестен их размер). Затем с помощью reify мы получаем структуру этой функции и выводим, как параметры связаны между собой.

С одной стороны мы имеем обычную функцию Haskell, которую можно проверить вручную или с помощью QuickCheck. С другой стороны мы имеем её структуру, которую можно перевести в структуру функции Verilog или VHDL.

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

При этом типы данных вполне могут быть полиморфными, вот только параметризованые неполиморынми типами. Можно указывать кодирование вариантов с помощью типов данных наподобие data EncodeWide a = EncodeWide a (очень широко и неэффективно), data EncodeReuseWires a = EncodeReuseWires a (данные вариантов могут пересекаться), data EncodeCompact a = EncodeCompact a (варианты кодируются в двоичной системе счисления, данные могут пересекаться). Например: readRegFile :: Cmd (EncodeReuseWires RegNum) -> Cmd (EncodeWide WORD).

Осталось реализовать и проверить (начинаю медленно посыпать голову пеплом).

PS
Запись чисел в виде 5=11111, 7=1111111, 128=1-повторенное-128-раз - это всё равно кодирование в позиционной системе счисления, только по основанию 1. По-моему.

5 = 1^4+1^3+1^2+1^1+1^0. ;)

Забрал из Озона Продюсеров. Мел Брукс рулит. ;)

Ещё мне интересно, какие есть метрики производительности программиста за исключением количества строк.

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

Есть ещё functional points, но пока непонятно, как их использовать. Если я всё правильно понимаю, по уровню языка (при использовании его конкретным человеком) и функциональному разбиению (с учётом используемых библиотек) я могу оценить размер программы в лексемах.

Остаётся вопрос, чем это лучше простого количества строк.

Разве, что более научно. ;)

Давным-давно я написал статью по разборщики на потоковых процессорах.

Так вот, работают они совершенно нелинейно. Простой разборщик наподобие \n -> prun (pmany (ptoken '1' `ppar` ptoken '2')) (replicate n '1') работает за квадратичное от n время.

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

Не могу доказать и не могу построить исключающий ppar.

Если представить себе, что мы собираемся делать System Haskell или HHDL (Haskell Hardware Description Language), то возникает вопрос о представлении алгебраических типов с помощью проводов.

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

Например, вариантный тип Maybe будет представлен как

selector_Nothing
selector_Just
bus_Just_argument

а вариантный тип... кого бы взять в пример?..

Вот такой вариантный тип:

data FloatInput =
        TwoFloats {f1::HFloat, f2::HFloat}
    |   SingleDouble { dbl :: HDouble }
data HFloat = HFloat { fsign :: Bit, fexp :: Bits8, fmant :: Bits24 }
data HDouble = HDouble { dsign :: Bit, dexp :: Bits11, dmant :: Bits52 }

будет представлен довольно объемно:

selector_TwoFloats
bus_f1  | bus_fsign -- шина в один бит, селектор TwoFloats опущен.
        | bus_fexp
        | bus_fmant
bus_f2  | bus_fsign
        | bus_fexp
        | bus_fmant
selector_SingleDouble
bus_dbl | bus_dsign
        | bus_dexp
        | bus_dmant

Итого - 1+23+32+1+64 - 130 бит.

Можно шины для dbl и f1+f2 совместить, получится уже 66 бит. Если же закодировать выбор между TwoFloats и SingleDouble всего одним битом, то получится еще меньше - 65 бит.

При этом получается куча вариантов кодирования.

Тип со многими вариантами:

data Example =
        V1
    |   V2 Int
    |   V3 Int
    |   V4 Int Int
    |   V5 Int
    |   V6 Int Int Int

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

Например, прямое кодирование - по сигналу на селектор, - дает наибольшую скорость декодирования. Если мы закодируем номера вариантов одним и тем же количеством бит, то скорость дешифрации и затрачиваемая энергия будет примерно одинаковой. Мы также можем кодировать номера селекторов каким-нибудь перекошеным кодом: V1 -> 0000, V2 -> 1000, V3 -> 1100, V4 -> 1101, V5 -> 1110 и V6 -> 1111. Тогда декодирование команд буде происходить в случае (допустим, часто встречающихся) V1 очень быстро и энергосберегающе, а редкие V3, V4, V5 и V6 нас не волнуют. ;)

Кодов можно подобрать великое множество, с самыми разными распределениями (см. например, это).

Так вот. Способ кодирования можно кодировать (тавтология или каламбур, хехе) с помощью обертки в определенный тип. Например, data StraightCode a = StraightCode a означает кодирование селекторов передаваемого типа методом "провод-селектор." data UniformCode a - кодирование с помощью равномерно распределенных кодов. И data EliasCode a - декодер будет длиннее для вариантов, у которых больше номер.

По-моему, мысль. ;)

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

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

Про OCaml как-то упоминал kouzdra.

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

Кстати, что хотел сказать товарищам с RSDN: Gaperton наш с potan начальник.

Точнее, то, о чем долго думал я - свершилось!

А думал я вот, о чем.

Была такая интересная операционная система EROS - Extremely Reliable OS. В ней было всего два интересных момента - это безопасность программирования и отказоустойчивость.

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

Программы для нее писались на C++. Для обеспечения секретности использовались какие-то специальные приемы по раздаче прав (capabilities, способности). Товарищи долго ее развивали, писали диссеры и статьи на эту тему, а потом вдруг сказали, что что-то у них там изначально не то было. И переключились на новые проекты (CaprOS и Coyotos).

А думал я о том, что хорошо бы это дело на Хаскеле переписать. ;)

По многим причинам. Одна из которых - отсутствие опасных операций наподобие преобразований типов в языке.

Вот та статья по ссылке про такую попытку и рассказывает.