Metaprog: универсальная графическая среда программирования [в разработке] часть 5

Эта эпопея всё никак не закончится?

Не взлетит.

Кстати, смотрел https://noflojs.org/example/ ?

Про noflo (и viskell) автор сказал, что это - Не более чем системы для прототипирования под джаваскрипт и хаскелл. О системах прототипирования замечание уже было. Его поделие для полноценного программирования.

Да будет рекурсия. Всего лишь функция в функции, тут вопрос лишь как ее воплотить.

Любой рекурсивный алгоритм можно преобразовать в итеративный, так что, если есть циклы, на рекурсию можно забить - её отсутствие никоим образом не уменьшает мощъ твоего языка.

В Си так вроде принято делать для производительности. Но рекурсия тоже по-своему прекрасна, в Лабвью я ее часто использую.

За такой фибоначчи бить надо. Он же весь стек засрет.

Да, у меня есть компонент «вызов сишной функции». Но есть и свои, метапроговские подфункции, в большинстве примеров есть. А в NoFlo свои подфункции есть или только джаваскрипт?

Совершенно верно.

Понтанулся, легче стало? А почему там написано именно так в контексте топика понторезка понять помешала?

Шо уже можно прогаммы записывать в виде звуков, запахов, тактильный ощущений?

Любой рекурсивный алгоритм можно преобразовать в итеративный, так что, если есть циклы, на рекурсию можно забить

Попробуй преобразовать

int search(tree *t, int k)
{
   int r;
   if (t.key == k) return t.val;
   r = search(t.left, k);
   if(r) return r; else return search(t.right, k);
}

Зависит от ЯП. Это же классическая хвостовая, на хаскеле так примерно 70% ПО написано, и стек никуда не выжирается. Если ваш язык не умеет в чистые функции и их оптимизацию – не значит, что алгоритм неправильный.

Хотя данный конкретный алгоритм неэффективен по времени, это да.

Я же ссылку дал. Там свои подфункции: «make squares», «cam to canvas», «draw palette».

Зависит от ЯП. Это же классическая хвостовая

???

В хвостовой последним действием должно быть «вернуть f(...)», а не «вернуть сумму ...».

на хаскеле так примерно 70% ПО написано

Ну запусти

Prelude> f 1 = 1
Prelude> f 2 = 2
Prelude> f n = f (n-2) + f (n-1)
Prelude> f 2000000000

В том и дело, что конкретно это - не хвостовая =)

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

Упс, глянул ещё раз, и понял, шо туплю… Пить надо меньше, надо меньше пить!

Хвостовая - это, например, всеми «любимый» факториал

f(1) = 1
f(n) = n * f(n-1)

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

acc <- n
while n > 2
   n <- n - 1
   acc <- acc * n

что и будет хвостовой рекурсией.

попробуй теперь ту функцию преобразить

Да, согласен, я просто вообще не глядя на код написал пару сообщений, потом дошло.

Любопытно. Однако это все ориентировано на джаваскрипт, а не сишку.

Сделан ли NoFlo «сам на себе» и претендует ли на универсальную среду?

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

И я о том же. Но даже они по-своему ограничены, из-за чего я и задумал Метапрог.

Вот по теме. Вопрос ко всем. Как лучше спроектировать типы для диаграмм? Я про АДТ. Которые нужны хоть в асме, хоть в сишке, хоть в плюсах, хоть в js'е, хоть в хаскелле.

Имхо, основные типы такие:

• Диаграмма (diagram)
• Узел (node)
• Связь (connection)
• Область (area)

Я специально исключил отсюда все типы, необходимые для отрисовки и взаимодействия потому, что там всё специфично для средств отрисовки (gtk, qt, dom, nuklear, winforms...).

Сразу видно, что это частный случай графа, при этом лично я не вижу смысла запихивать всё это в дерево (если не надо тупо копипастить дракон + при удалении одного узла не должны удаляться все связанные узлы). Да и доступ к узлам должен быть прямой. Понятие «главного узла» нам не нужно, а вот в дереве обязателен «главный узел».

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

Имхо, вот мой вариант структур данных (схематически):

type Diagram {
  id: UUID
  nodes: LinkedList<Node*>
  areas: LinkedList<Area*>
}
type Node {
  id: UUID
  metadata: NodeMetaData*
  inputs: LinkedList<Pair<String, Connection*>>
  outputs: LinkedList<Pair<String, Connection*>>
}
type Connection {
  from: Node*
  to: Node*
  typeName: String
}
type Area {
  text: String
  rect: Rect
}
type NodeMetaData {
  name: String
  description: String
  icon: Icon
}

Это псевдокод, который легко превращается в код на языке реализации. Доработки приветствуются.

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

1. Каждая «нода» представляет из себя функцию или конкретное значение или тип. Она обязана иметь тип.
2. «Соединение» нод – применение функции
3. «Область» – определение новой функции (по сути, именование лямбды) или нового алгтипа с помощью соединения нод и придания этой конструкции имени (имя может быть пиктограммой, это не принципиально)
4. «Диаграмма» – совокупность областей, причем некоторые области «внутренние» (т.е. видны только для областей данной диаграммы), а некоторые – внешние (т.е. экспортируются и видны и изнутри, и снаружи)
5. «Программа» – диаграмма, экспортирующая область, именующую аналог main :: IO ()
6. «Библиотека» – диаграмма, экспортирующая несколько областей.

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

У меня так:

https://postimg.cc/8JXwp6GC

Правда в структуре «линия» информация о типе избыточна, используется лишь для цвета.

А я и не говорил про чистые функциональные программы. Это лишь подмножество программ, которое (не только оно) красиво ложится на ВП.

Концепцию «областей» я заимствовал из Unreal Engine Blueprints. Это графический аналог комментариев в текстовых ЯП.

Кстати, в диаграммах очень важно отделить «чистые» функции от функций с побочными эффектами, ведь порядок вызова 1-х не важен, а порядок вызова 2-х нужно задавать явно.

Я тут подумал и решил, что метаданные должны быть всего-лишь

Dictionary<String,String>

Я могу читать описания типов данных на многих текстовых языках и на графических UML диаграммах. Содержание этой схемы мне непонятно. Уверен, многим другим тоже непонятна эта схема.

Кстати, в диаграммах очень важно отделить «чистые» функции от функций с побочными эффектами, ведь порядок вызова 1-х не важен, а порядок вызова 2-х нужно задавать явно.

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

чистые функции задают порядок выполнения побочных эффектов

В средах, где бОльшая часть функций - с побочным эффектом, так не получится. Мне нравится как это реализовано в UEB. Я за мультипарадигменность.

А вообще, ваша аватарка намекает на любовь к функциональщине.

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

Я вот сейчас налаживаю циклы. Из-за побочного эффекта (который долго пришлось дебажить) я отказался от сишного инкремента (х++) в функции «+1» и использую вместо него (х+1).

Ну что, обрисую и я схему.

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

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

Стрелку, не начинающуюся ни из одного узла будем называть входной, а узел, на контуре которого такая стрелка заканчивается будем называть входным. Узел, на контуре которого не начинается ни одна стрелка, будем называть выходным.

Такая схема переносится на любой язык, любую машину. И выполняется хоть последовательно, хоть параллельно.

В средах, где бОльшая часть функций - с побочным эффектом, так не получится

В этом и заключается основное умение грамотного хаскелиста – декомпозировать «функции с побочным эффектом», выделив побочный эффект в сторонку и оставив как можно больше функций чистыми. Очень тупой пример, который демонстрирует принцип:

Вместо

greet :: String -> IO ()
greet = putStrLn . ("Hello, " ++) 

main = greet =<< readLn

писать

greet :: String -> String
greet = ("Hello, " ++)

main = putStrLn . greet =<< readLn

Отличий не вижу. И то, и другое - абракадабра из английского и спецсимволов..

приветствие :: Строка -> ВводВывод ()
приветствие = вывестиСтроку . присоединить . "Привет, "

main = прочитатьСтроку >>= приветствие

vs.

приветствие :: Строка -> Строка
приветствие = присоединить "Привет, "

main = вывестиСтроку . приветствие =<< прочитатьСтроку

где

Строка = String
ВводВывод = IO
присоединить = mappend
прочитатьСтроку = getLine
вывестиСтроку = putStrLn

Отличий не вижу. И то, и другое - абракадабра из английского и спецсимволов..

А как тебе такая запись того же кода?

🙂⁞□→□
🙂≈✋×
♡≈○⨀🙂⥢●

Как я графически изображу рекурсию - я знаю, но это я сделаю с применением столь нелюбимого матана и абстракций.

Через Y-комбинатор? Но для этого нужны функции как объекты первого класса. Я бросил следить за метапрогом в середине второй темы, там хотя бы указатели на функции появились? Кстати, на Rosetta Code есть пример Y-комбинатора на C.

Любой рекурсивный алгоритм можно преобразовать в итеративный, так что, если есть циклы, на рекурсию можно забить

Попробуй преобразовать

Достаточно ввести тип stack. Но будет не так красиво, да.

Похоже на APL :D

Шутка уже была пошучена, причем в прошлый раз я использовал валидный haskell.

Попробуй преобразовать

У меня для таких случаев как раз есть программа специальная - gcc. Я бы выложил результат, да он в экран не влезает. Или выхлоп gcc не канает в качестве результата преобразования?

Неверно. В твоей реализации после рекурсивного вызова происходит ещё умножение. Можно переписать с использованием хвостового вызова следующим образом:

f'(0, acc) = acc
f'(n, acc) = f'(n-1, n * acc)

f(n) = f'(n, 1)

Доопределил факториал нуля заодно.

Указатели на функции - уже давно, коллбеки используются во всех примерах с гтк. Читай шапки тем.

И все равно понятнее не стало. Где справка при наведении мышкой, где интерактивная обучалка без чтения RTFM? И где программирование через графические блоки, а не символы, хоть буквенные, хоть смайлики?

Кроме шуток: есть ли в Си цикл по элементам структуры? Например, для сериализации. Сначала берется и сериализируется первый элемент, потом второй, третий итд.

Кроме шуток: есть ли в Си цикл по элементам структуры? Например, для сериализации.

О, так, глядишь, теме к десятой ТС обратит наконец внимание на нормальные ЯП со вменяемыми циклами.

Где справка при наведении мышкой

В вашем IDE

где интерактивная обучалка без чтения RTFM

На http://tryhaskell.org/

А так-то на ваших картинках тоже не будет справки при наведении мышки и интерактивной обучалки, если открывать их в feh

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

Вам нужно – вы и допишите поверх.

Type help to start the tutorial

Его ввести надо ручками. Там нету кнопки «help»!

Шучу. есть. Покликаю-потыкаю.

Шутка уже была пошучена, причем в прошлый раз я использовал валидный haskell.

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

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

Чуть ли не общепринятый стандарт показа структуры данных в графике - UML диаграммы.

У себя я планирую сделать много разных вариантов визуализации. Вместо тысячи слов как всё будет предпочитаю показать хотя бы сырой прототип. Когда он будет.