LINUX.ORG.RU

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

 , , ,

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

прохфессора мамка из-за комплюктера выгнала. И провод отобрала. Вон сидит с телефончика под анонимчиком.

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

У него просто дебьян (вроде) в кернелпаник свалился. И все исходники самоуничтожились. А пароль от аккаунта, разумеется, мегамозг запомнить ниасилил.

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

Зато с птичками... отдыхать - всегда пожалуйста

птичку_жалко.jpg

rebforce
()

А что там с циклами? Уже 2 недели прошло как автор взялся рисовать циклы и как-то все нет. А еще же условия, алгоритмы всякие...То есть если тратить по 2 недели на такую базовую и простую вещь, то до альфы, или чего-то близко похожего, можно и вообще не дожить.

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

о, точно: bytebeat. тут более развёрнуто. а то сначала на ютубе наткнулся.

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

как интересно. помнится решил запилить простенький интерпретатор и накидал за одну ночь и вот как раз на циклах всё застопорилось. уже не помню чего там не получалось.

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

Лолшто? Циклы — всего лишь синтаксический сахар над условными переходами. То есть если переменные в каком-то виде есть и flow control в виде, образно говоря, if и goto (ну или call/ret) работает, значит, циклы тоже должны.

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

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

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

и до сегодняшних дней не сохранился

Жаль, можно было бы разобраться с циклами (думаю, с адресным стеком проблема решилась бы на раз) и запилить принципиально новый ЯП поюзабельнее метахрени.

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

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

iluha16
()
Ответ на: комментарий от rebforce

запилить принципиально новый ЯП поюзабельнее метахрени.

Реквестирую графический чистый ФП без сборщика мусора, но при этом память-безопасный a-la Rust, если проект будет хотя бы начат, я с радостью присоединюсь.

(После того, как разгребу время для опен-сорца)

balsoft ★★
()
Последнее исправление: balsoft (всего исправлений: 1)
Ответ на: комментарий от balsoft

Ты какого-то мутанта хочешь. Это вообще законно? Чистый ФП без сборщика... Одно это трудно представить.

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

Рабочий день у рабов командировочных, я человек сободный.

А я в любой момент могу выйти к нашему озеру и снять пруф с таймштампом.

Еще похвались тем что лужи можешь пофоткать, я же написал, озеро красивое и в заповеднике.

Deleted
()
Ответ на: комментарий от iluha16

Вангую что загвоздка была в том что ты не сделал стек для адресов возврата, и юзался последний объявленный цикл.

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

Да, академики вроде бы попиливают нечто похожее. На данный момент GC – это самая большая проблема всех ФП языков, её нужно решать. В конце концов, структуры данных в ФП иммутабельны (по крайней мере для программиста), а время жизни для них чаще всего строго определено контекстом, остается только наладить ручное определение времен жизни для случаев, когда вывести невозможно, ну и всякие полуавтоматические RC для случаев, когда и этого недостаточно.

balsoft ★★
()
Последнее исправление: balsoft (всего исправлений: 1)
Ответ на: комментарий от balsoft

https://github.com/melsman/mlkit

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

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

не знаю, как типизированный ФП-чистый типа ML, но лисп на расте уже запилили:

mal-rust поцмортем — это 'make yourself a Lisp на 10500 языках' mal (алсо

ещё есть такие лиспы на ржавчине: JunSuzukiJapan/macro-lisp murarth/ketos «чисто функциональный» etaoins/arret risp описалово rust-elisp

ещё был какой-то с макросами раста и японскими иероглифами. сейчас сходу не вспомню.

типа как в InteLib от А. Столярова, где лисп в С++ транслировался. только тут в раст.

вообще «чисто функциональный» некий DSL (или полноценный недоязычок) на расте с zero-cost abstractions и без GC где не недо — было бы интересно.

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

Region-Based

ага, интересно. и что, прям лайфтаймы раста можно выводить из/в регионов или это ортогонально?

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

А, так это таки ты, неуч? Птички хоть живы остались после твоего «отдыха»?

rebforce
()
Ответ на: комментарий от balsoft

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

Вообще таки надо подумать. Мне щас немного не до того, может, ув. тов. Артурианец к идеям прислушается.

rebforce
()
Ответ на: комментарий от balsoft

Functional Geometry на elixir (+ссылки на реализации Lisp F# Haskell Python) и на Java (проще на C++/Qt портировать)

про «алгебру картинок» и их функционально чистую композицию

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

на CL (можно переписать на расто-лисп-гтк, и добавить своих УГО)

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

чистый ФП без сборщика мусора, но при этом память-безопасный

Вообще у меня были мысли запилить что-то похожее с двумя таргетами:

  1. CHIP-8 (каноническая реализация, принципиально новая VM моего авторства под которую уже готова);
  2. JS/ES6 не слишком нового образца, а именно уровня Gecko 48 (почему так — долго объяснять, но это связано с одним моим мобильным опус-магнумом).

Кстати, очевидно, что если ФП-рантайм без GC будет вменяемо компилироваться и работать в виртуалке CHIP-8 первой спецификации, то на JS он будет лётать аж бегом. По эзотерическим рантаймам определённый опыт трёхлетней давности имеется. Штука полезная, чисто для души.

rebforce
()
Ответ на: комментарий от metaprog

Не на CHIP-8, а с возможностью компиляции под CHIP-8.

Пипец, это же академический образец архитектуры виртуальной машины, который даже на плееры типа Sansa Clip портирован. Стыдно такую классику не знать.

rebforce
()
Ответ на: комментарий от metaprog

Ты почти в каждом сообщении напоминаешь о том, что «Антиметапрог» не готов и вообще мы его не дождемся. Как мне кажется, это свидетельствует лишь о том, что у тебя с твоим метапрогом полная жопа, и релиза не будет, что в принципе было вполне ожидаемо.

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

Та да. Такое ощущение, что его цель вовсе не в написании чего-то своего заключается.

Если бы он хотя бы попытался 100501-ю реализацию той же виртуалки CHIP-8 (базовый сет, без суперчипов и мегачипов) запилить чисто для себя (пусть даже на том же грёбаном лабвью, хотя лично я это слабо себе представляю) и добился бы успешного запуска на ней хотя бы того же Astrododge (самая попсовая игруха под эту платформу из более-менее современных), это бы мозг ой как вправило. И в процессе большинство возникающих вопросов прояснились бы настолько, что и разработка метапрога пошла бы куда бодрее. Но это не путь демагога, понимаешь?

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

Никто не говорил про отмену разработки Метапрога (в отличие от «Антиметапрога», концепт которого был обещан за неделю). Она идет, просто с циклами проблем больше, чем думалось. Но, думаю, за несколько дней они решатся и циклы будут. Опять же, «думаю» не означает «обещаю».

И, все же, хотелось бы увидеть «антиметапрог» на джаваскрипте. Стоп, что-то такое уже есть, уже выше показывали NoFlo. Но, все же, оно чуть-чуть не то, что надо. Хотя, если б не было Лабвью, то, возможно, пилил бы Метапрог на нем. Самая симпатичная из показанных в темах систем после Лабвью и MyOpenLab.

metaprog
() автор топика
Ответ на: комментарий от metaprog

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

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

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

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

Реквестирую графический чистый ФП без сборщика мусора, но при этом память-безопасный a-la Rust, если проект будет хотя бы начат, я с радостью присоединюсь.

Гугли про interaction nets. Например, есть пейпер Visual Programming with Recursion Patterns in Interaction Nets. Или вот Interaction nets: programming language design and implementation, который начинается словами

Interaction nets are a graphical—visual—programming language.

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

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

Индустрии плевать на перспективные разработки, рынок диктует свои условия, приходится подстраиваться под потребителя. Программист привык к императивной парадигме? Поддержим! Невыровненный доступ к памяти? Обеспечим! Программа сегфолтится? Виноват гтк, линукс, интел, да кто угодно, но точно не автор! Дегенерат не может понять смысла написанного? Проблема в письменности!

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

В курсе.

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

И можешь подробнее насчет

автоматически решаются проблемы ленивости/энергичности, сборка мусора становится явной

Если с жадностью/ленивостью я могу себе представить, о чем речь, то вот про явную сборку мусора я вообще не понял.

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

Запилить новый ЯП? Ещё и функциональный? Я пас. Максимум, на что меня хватит - трансляция в готовый ЯП или примитивнейший диалект лиспа. + для меня фп - «замечательно в некоторых ситуациях», но всю программу в функциональной парадигме - не для меня.

По поводу избавления от GC я дилетант, но в голову приходит move semantics из C++, но так, чтобы компилятор сам выводил в простых случаях когда «передавать владение данными» функции. Также неплохо бы сделать reference counting, только не в рантайме, как в С++, а на этапе компиляции, без оверхеда в рантайме. А вот кеширование результатов вызова чистых функций я без понятия как сделать без GC и при этом надёжно.

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

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

Также неплохо бы сделать reference counting, только не в рантайме, как в С++, а на этапе компиляции, без оверхеда в рантайме

Reference counting на этапе компиляции – это lifetimes, суть RC как раз в том, что оно обязано быть в рантайме.

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

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

Максимум, на что меня хватит - трансляция в готовый ЯП

Трансляции в Rust вполне хватит для нишевого язычка.

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

Мне скрины interaction nets не понравились тем, что черно-белые. Цвет в Метарпоге и Лабвью в основном для типов данных. А какие где типы данных в interaction nets? Или там типов как таковых нету?

metaprog
() автор топика
Ответ на: комментарий от arturianec100

Ну я лично, как и ТС, далёк от высоких материй, но, будучи сторонником простых решений, к вопросу могу подойти с другой стороны:

  1. С точки зрения VM существует только джва типа данных - byte (байт) и parcel (всё остальное размером больше байта - строки, флоаты, ссылки на другие функции и т.д.). Соответственно, двум инструкциям VM отводится функциональность задания границ парсела и эскейпинга внутри оного. Как именно эти самые парселы будут интерпретироваться, зависит исключительно от обрабатывающей их функции.

  2. Модель исполнения VM - старая добрая стек-машина (в каждой ячейке стека может быть либо байт, либо парсел). Но с одним но: у каждой функции стек индивидуален и полностью изолирован от остальных. При возврате из функции топ-значение её стека ставится в топ вызывающей, а стек вызванной незамедлительно грохается.

  3. VM содержит разумное количество встроенных функций, в том числе и ФВП, подчиняющихся общим правилам.

Не вижу с такой моделью никаких проблем со сборкой мусора. Совершенно.

rebforce
()
Ответ на: комментарий от iluha16

Не могу ответить в твоей теме из-за идиотского ограничения на одну звезду.

тебе надо сделать спецификацию к каждой консольной команде и разработать парсер генерящий гуй с туевой кучей checkboxов и selectов для каждой имеющейся опции с подсказками что делает каждая опция.

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

кроме того надо продумать как реализовать в гуйне взаимодействие между утилитами по типу pipeов (типа ls | wc).

Тему по подобному вопросу я открыл еще до первой темы по Метапрогу. Разберемся, когда руки дойдут.

metaprog
() автор топика
Ответ на: комментарий от metaprog

Чтобы эффективно и корректно справляться с различиями предлагаемой модели исполнения ЯФП и модели исполнения бинарного кода.

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

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

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