Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.01.09 17:20
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

LP>Если серьезно, то не так уж и много (для java):


LP>1. Какой-то сахар на уровне языка, чтобы можно было легко оперировать с соотв. структурами данных (кортежи, односвязные списки)

LP>2. ФВП, удобный синтаксис для их определения. Удобный синтаксис для лямбда-функций. Замыкания.
LP>3. Templates как в С++
LP>4. Сопоставление с образцом

Это называется Scala.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.01.09 18:16
Оценка:
Здравствуйте, thesz, Вы писали:

T>Если честно, то я тебя считаю просто упёртым человеком, совершенно не желающим вставать на точку зрения других и упорствующим в своих заблуждениях. Единственное, что тебя может сдвинуть с места, это твой собственный опыт. Ты в принципе не способен учиться на чужих ошибках и успехах.


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

T>И я разговариваю с тобой, как с таковым человеком.


Дык и я с тобой не как с машиной или животным разговариваю.

T>Кстати, то, что ты записал меня в упёртые функциональщики, которые записывают тебя в императивщики, как раз говорит об узости классификации и нежелании разобраться в явлении. Да и другие люди тоже никуда тебя не записывают. Всё их сопротивление сводится к "не мешай мне учитывать проблемы, которые я считаю важными", вот они тебя и отпихивают "отойди и не мешай своим ФП/ИП", всё остальное происходит в твоём мозгу.


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

T>Ты всем стараешься навязать важность твоих проблем и их решений.


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

T>Да чуть выше — "написать статью ты в принципе не в силах". А оно мне надо, писать статью?


Видимо надо раз в этой теме уже который день тусушеся.

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


Хорошее начинание. Жаль только затеряется оно в куче других страниц.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.01.09 18:25
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>На эту тему кстати есть забавный рассказ "Доклад о вероятности А"... совершенно бесчеловечный эксперимент над читателем


А ссылка есть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 26.01.09 20:53
Оценка:
T>>Кстати, то, что ты записал меня в упёртые функциональщики, которые записывают тебя в императивщики, как раз говорит об узости классификации и нежелании разобраться в явлении. Да и другие люди тоже никуда тебя не записывают. Всё их сопротивление сводится к "не мешай мне учитывать проблемы, которые я считаю важными", вот они тебя и отпихивают "отойди и не мешай своим ФП/ИП", всё остальное происходит в твоём мозгу.
VD>Я тебя никуда не записывал. Если ты себя сам записал, то апеллируй к себе.
VD>Я сказал, то что сказал. Не надо домысливать.

Kewl!

T>>Да чуть выше — "написать статью ты в принципе не в силах". А оно мне надо, писать статью?

VD>Видимо надо раз в этой теме уже который день тусушеся.

В смысле? Который день я уже "тусущеся" в этой теме?

О чем мои комментарии здесь?

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

VD>Хорошее начинание. Жаль только затеряется оно в куче других страниц.

В оглавлении оно присутствует.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: yuriylsh  
Дата: 27.01.09 05:23
Оценка:
Здравствуйте, VladD2, Вы писали:

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


AF>>На эту тему кстати есть забавный рассказ "Доклад о вероятности А"... совершенно бесчеловечный эксперимент над читателем


VD>А ссылка есть?


Здесь. Ссылки на скачивание, я так понимаю, давать здесь запрещено...
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[15]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 07:51
Оценка:
Здравствуйте, VoidEx, Вы писали:

VD>>Ну, а сравнить Хаскель с чем-то более высокоуровенвым и приемущество как-то сразу улетучивается.

VE>С чем например?

С любым языком полноценно поддерживающим ФП.

VE>Только не надо про синтетичность примеров (when-то и в Немерле есть)


Пожалуйста, не буду. Мне бессмысленная пенисометрия уже давно надоела.

VE>и приводить свои примеры


А мне больше заняться не чем чем доказывать упертым очевидные прописные истины. Веришь в Хаскель? Ну, так молись и верь. Не буду мешать. А у меня своих дел навалом. Тут пенисометрии по форуму разбросано тонна.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 07:57
Оценка: :)
Здравствуйте, thesz, Вы писали:

T>В смысле? Который день я уже "тусущеся" в этой теме?


Ага.

T>О чем мои комментарии здесь?


А ни о чем. Тупо рекламируешь Хаскель в теме где ему совсем не место и попутно откровенно наезжаешь на окружающих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 08:22
Оценка:
Здравствуйте, thesz, Вы писали:

L>>>Почему наиболее разумно?

LP>>Суть алгоритма состоит в том, чтобы на каждой ноде, удовлетворяющей определенному условию (а именно, которая соединяет два линейных элемента) сделать следующее: заменить элементы, соединяемые этой нодой, новым элементом. Таким образом в императивном решении достаточно удалить эту ноду, эти два элемента и добавить новый элемент, который начинается на нодах, с которых начинались с другой стороны старые два элемента — это ровно три действия. В функциональном решении нужно клонировать каждую ноду, которая не удовлетворят этому условию, в новую схему, то есть получить часть схемы без нод, удовлетворяющих условию.

T>Это не так. Дей1ствия ровно те же. Клонирования большей части нод нет.


Есть, есть.

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


T>Во-во. Выспишься и увидишь, в чём был неправ.


Не вижу
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 08:22
Оценка:
Здравствуйте, FR, Вы писали:

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


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


FR>То есть ты пишешь на Ocaml?



а он есть под jvm? я имею ввиду полноценный компилятор, а не разные хадкорные интеропы
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 08:22
Оценка:
Здравствуйте, VladD2, Вы писали:

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


LP>>Если серьезно, то не так уж и много (для java):


LP>>1. Какой-то сахар на уровне языка, чтобы можно было легко оперировать с соотв. структурами данных (кортежи, односвязные списки)

LP>>2. ФВП, удобный синтаксис для их определения. Удобный синтаксис для лямбда-функций. Замыкания.
LP>>3. Templates как в С++
LP>>4. Сопоставление с образцом

VD>Это называется Scala.


Да, мы его уже немного смотрели. Неплох, но не понравилось, что некоторые java-фичи реализованы не до конца. Например, вложенных аннотации не реализованы, вследствие чего например затрудняется описание jpa-маппингов (в принципе, это мелочи, доменную модель можно и на java сделать).
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 08:23
Оценка: -1
Здравствуйте, LaPerouse, Вы писали:

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


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


LP>>>Если серьезно, то не так уж и много (для java):


LP>>>1. Какой-то сахар на уровне языка, чтобы можно было легко оперировать с соотв. структурами данных (кортежи, односвязные списки)

LP>>>2. ФВП, удобный синтаксис для их определения. Удобный синтаксис для лямбда-функций. Замыкания.
LP>>>3. Templates как в С++
LP>>>4. Сопоставление с образцом

VD>>Это называется Scala.


LP>в принципе, это мелочи, доменную модель можно и на java сделать


Хотя это бред, лучше использовать xml-маппинги
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[16]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 08:43
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Суть алгоритма состоит в том, чтобы на каждой ноде, удовлетворяющей определенному условию (а именно, которая соединяет два линейных элемента) сделать следующее: заменить элементы, соединяемые этой нодой, новым элементом. Таким образом в императивном решении достаточно удалить эту ноду, эти два элемента и добавить новый элемент, который начинается на нодах, с которых начинались с другой стороны старые два элемента — это ровно три действия. В функциональном решении нужно клонировать каждую ноду, которая не удовлетворят этому условию, в новую схему, то есть получить часть схемы без нод, удовлетворяющих условию. Потом для каждой ноды, удовлетворяющей условию, нужно добавить элемент, заменяющий прилегающие к ноде элементы. Я только с командировки вернулся и адски хочу спать, поэтому нет времени сделать набросок.


Я правильно понимаю? Тебя смущает, что мы не модифицируем саму структуру, а пользуемся Scheme -> Scheme? Но тогда непонятны твои замечания об оверхеде по синтаксису. Код как раз таки сократится.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 08:47
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Да, мы его уже немного смотрели. Неплох, но не понравилось, что некоторые java-фичи реализованы не до конца. Например, вложенных аннотации не реализованы, вследствие чего например затрудняется описание jpa-маппингов (в принципе, это мелочи, доменную модель можно и на java сделать).


Сам ответил на свой вопрос. Плюс надо учесть, что разработчики открыты для контактов и скорее всего исправят те проблемы которые мешают использовать язык на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 08:48
Оценка:
Здравствуйте, lomeo, Вы писали:

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


LP>>Суть алгоритма состоит в том, чтобы на каждой ноде, удовлетворяющей определенному условию (а именно, которая соединяет два линейных элемента) сделать следующее: заменить элементы, соединяемые этой нодой, новым элементом. Таким образом в императивном решении достаточно удалить эту ноду, эти два элемента и добавить новый элемент, который начинается на нодах, с которых начинались с другой стороны старые два элемента — это ровно три действия. В функциональном решении нужно клонировать каждую ноду, которая не удовлетворят этому условию, в новую схему, то есть получить часть схемы без нод, удовлетворяющих условию. Потом для каждой ноды, удовлетворяющей условию, нужно добавить элемент, заменяющий прилегающие к ноде элементы. Я только с командировки вернулся и адски хочу спать, поэтому нет времени сделать набросок.


L>Я правильно понимаю? Тебя смущает, что мы не модифицируем саму структуру, а пользуемся Scheme -> Scheme? Но тогда непонятны твои замечания об оверхеде по синтаксису. Код как раз таки сократится.


Меня не радует, что Scheme -> Scheme намного более накладна в данном случае (по реализации), чем простая модификация Scheme. Я написал, почему. Попробуй написать функциональный аналог этого же алгоритма без деструктивого изменения scheme, поймешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.01.09 08:49
Оценка:
Здравствуйте, LaPerouse, Вы писали:

FR>>То есть ты пишешь на Ocaml?


LP>

LP>а он есть под jvm? я имею ввиду полноценный компилятор, а не разные хадкорные интеропы

Ocaml не имеет серьезных приемуществ по сравнению с той же Скалой. Фактически Скала — это перенос идей МЛ-я на Яву. А Ocaml перенос (причем плохой) идей ООП в МЛ.

Так что выбирая Скалу вы можно сказать выбираете близкого родственника ОКамла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 09:02
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Императивное — это значит последовательное, разве нет? Ну и плюс отсюда вытекает состояние. Т.е. я не имел в виду именно GUI, интерактивность и т.д. Надо было придумать какой-то пример, вот я его и взял. На самом деле, как мне кажется, нет разницы что именно мы программируем. Если мы можем удобно запрограммировать императивно на Haskell одну вещь, то, наверное, сможем и другую. Т.е. я не вижу, почему твой императивный алгоритм на Haskell запишется хуже, чем на Яве (раз уж ты её приводил в пример). Можно как нибудь раскрыть этот момент?


VD>Да потому что нужны лишние приседания. Даже от твоих примеров (простеньких) уже в сон клонет.


Лишние приседания? Я показывал, что функциональный код для императивных задач может быть даже выразительнее и лаконичнее.

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


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

VD>Ну, а сравнить Хаскель с чем-то более высокоуровенвым и приемущество как-то сразу улетучивается.


Сравнивал. Если ты про Скала/Немерле, то не улетучивалось.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 09:37
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Меня не радует, что Scheme -> Scheme намного более накладна в данном случае (по реализации), чем простая модификация Scheme. Я написал, почему. Попробуй написать функциональный аналог этого же алгоритма без деструктивого изменения scheme, поймешь.


Хорошо, обязательно попробую.
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 10:15
Оценка: 15 (3)
Здравствуйте, LaPerouse, Вы писали:

LP> Попробуй написать функциональный аналог этого же алгоритма без деструктивого изменения scheme, поймешь.


В общем, написал.

Мне показалось, что здесь удобно использовать Map

> import qualified Data.Map as M


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

> type Node = Int


Элемент у меня хранит ссылки на узлы, в реальной программе будут скорее всего типы Element и ElementEntry. Для нас это неважно, т.к. на алгоритм не влияет. Также для функционального алгоритма не важно конечный ли это тип с полем isLinear или это функция класса типов Element — аналог твоих интерфейсов. Чтобы было покрасивее (паттерн матчинг) я выбрал тип

> data Element = Element { isLinear :: Bool, leftNode :: Node, rightNode :: Node }


Схема — это просто мап.

> type Scheme = M.Map Node [Element]


Определим вспомогательные функции, которые у тебя не показаны.

Во первых, аналог SchemeHelper.getOtherNode. Думаю, у тебя не сильно отличается.

> otherNode :: Element -> Node -> Node
> otherNode (Element _ l r) n
>     | l == n    = r
>     | otherwise = l


Как именно мёрджить элемент я, к сожалению, не знаю — думаю, вопрос предметной области.
Есть отличие — мы мёржим не сам элемент, а его обёртку (ElementEntry), таким образом мёрджим относительно какого то узла. Здесь у нас отличие.

> mergeElement :: Element -> Element -> Node -> Element
> mergeElement e1 e2 n = Element True (otherNode e1 n) (otherNode e2 n)


Удаление узла, всё очень просто. Ещё отличие — нам не нужна функция detachElement.

> removeNode :: Node -> Scheme -> Scheme
> removeNode = M.delete


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

> attachElement :: Element -> (Node, Node) -> Scheme -> Scheme
> attachElement el (ln, rn) = go ln . go rn
>     where
>         go = M.adjust (el:)


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

> isEntrantPoint :: Node -> Scheme -> Bool
> isEntrantPoint _ _ = False


И вот только сейчас аналог твоего кода. Можно сравнивать — страшно или нет.

Во-первых, трансформация по одному узлу (то, что у тебя в цикле). Здесь паттерн матчинг (по Element) помогает, но не сильно.
В случае, если мы используем класс Element, будут функции getLeftNode, getRightNode и т.д. Строчка будет чуть длиннее.

> transformWithNode :: Node -> Scheme -> Scheme
> transformWithNode node s
>     | length els /= 2 || isEntrantPoint node s = s
>     | isLinear el1 && isLinear el2 =
>         let el@(Element _ ln rn) = mergeElement el1 el2 node
>          in attachElement el (ln, rn) s
>     where
>         els@(~[el1, el2]) = s M.! node


И собственно функция.

> transform :: Scheme -> Scheme
> transform s = foldr transformWithNode s nodes
>     where
>         nodes = M.keys s


Никаких наворотов не использовано. Код декларативнее.
Отличие — отсутствие булевого результата легко решается — просто тип функций у нас будет Scheme -> (Bool, Scheme).
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.01.09 10:31
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Удаление узла, всё очень просто. Ещё отличие — нам не нужна функция detachElement.


Наврал, detachElement всё таки нужен. Поэтому сначала

> import Data.List


Затем

> detachElement :: Element -> Node -> Scheme -> Scheme
> detachElement el n = M.adjust (delete el) n


Чтобы пример компилировался, добавить deriving Eq к Element.

Ну и строчка преобразования схемы меняется на

>  in attachElement el (ln, rn) $ detach el1 $ detach el2 $ s
> ...
> where
>     detach el = detachElement el (otherNode el)


Извиняюсь за невнимательность, очень быстро всё писал.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: LaPerouse  
Дата: 27.01.09 11:46
Оценка:
Здравствуйте, lomeo, Вы писали:

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


LP>> Попробуй написать функциональный аналог этого же алгоритма без деструктивого изменения scheme, поймешь.


L>В общем, написал.


L>Мне показалось, что здесь удобно использовать Map


L>
>> import qualified Data.Map as M
L>


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


L>
>> type Node = Int
L>


L>Элемент у меня хранит ссылки на узлы, в реальной программе будут скорее всего типы Element и ElementEntry. Для нас это неважно, т.к. на алгоритм не влияет. Также для функционального алгоритма не важно конечный ли это тип с полем isLinear или это функция класса типов Element — аналог твоих интерфейсов. Чтобы было покрасивее (паттерн матчинг) я выбрал тип


Ага, ElementEntry (у меня это называется Pin), это "ножка" элемента, с помощью которой он присоединяется к ноде.

L>
>> data Element = Element { isLinear :: Bool, leftNode :: Node, rightNode :: Node }
L>


Соответственно, LinearElement — это элемент, имеющий только два Pin-a. LinearElement, вместе с другими типами элементов, реализует интерфейс IElement (например, есть еще трансформаторы Transformer и т. д.). Для данного алгоритма это неважно, твой Element вполне сойдет.

L>Схема — это просто мап.


L>
>> type Scheme = M.Map Node [Element]
L>


Хорошо.

L>Определим вспомогательные функции, которые у тебя не показаны.


L>Во первых, аналог SchemeHelper.getOtherNode. Думаю, у тебя не сильно отличается.


L>
>> otherNode :: Element -> Node -> Node
>> otherNode (Element _ l r) n
>>     | l == n    = r
>>     | otherwise = l
L>


В общем, верно. У меня немного сложнее — элементы могут иметь более двух пинов и данная функция реализуется как частный случай для LinearElement (см. у меня в коде приведение к типу LinearElement), но это непринципиально.

L>Как именно мёрджить элемент я, к сожалению, не знаю — думаю, вопрос предметной области.


Да, это неважно. На самом деле считается сопротивления элемента, токопередача и пр.

L>Есть отличие — мы мёржим не сам элемент, а его обёртку (ElementEntry), таким образом мёрджим относительно какого то узла. Здесь у нас отличие.


L>
>> mergeElement :: Element -> Element -> Node -> Element
>> mergeElement e1 e2 n = Element True (otherNode e1 n) (otherNode e2 n)
L>


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

L>Удаление узла, всё очень просто. Ещё отличие — нам не нужна функция detachElement.


Ок, исправление я видел.

L>Добавляем элемент. Поскольку добавляется он к уже имеющимся в схеме узлам, то здесь тоже ничего сложного.


L>
>> attachElement :: Element -> (Node, Node) -> Scheme -> Scheme
>> attachElement el (ln, rn) = go ln . go rn
>>     where
>>         go = M.adjust (el:)
L>


L>Не знаю, к сожалению, что это значит, думаю, не особо важно для того, чтобы показать алгоритм, верно?


L>
>> isEntrantPoint :: Node -> Scheme -> Bool
>> isEntrantPoint _ _ = False
L>


Это точка входа в схему. Непринципиально.

L>И вот только сейчас аналог твоего кода. Можно сравнивать — страшно или нет.


L>Во-первых, трансформация по одному узлу (то, что у тебя в цикле). Здесь паттерн матчинг (по Element) помогает, но не сильно.

L>В случае, если мы используем класс Element, будут функции getLeftNode, getRightNode и т.д. Строчка будет чуть длиннее.

То есть будут if-ы, как у меня. Ладно, это непринципиально.

L>
>> transformWithNode :: Node -> Scheme -> Scheme
>> transformWithNode node s
>>     | length els /= 2 || isEntrantPoint node s = s
>>     | isLinear el1 && isLinear el2 =
>>         let el@(Element _ ln rn) = mergeElement el1 el2 node
>>          in attachElement el (ln, rn) s
>>     where
>>         els@(~[el1, el2]) = s M.! node
L>


L>И собственно функция.


Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?). Поэтому, чтобы создать измененную копию схемы, мне нужно на порядок больше действий. Но зато у меня реализация эффективнее с точки зрения скорости выполнения и памяти.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.