>>19584 (OP)
Ты изобрёл макросы.

>>19590
По-сути, в правила Юпиэль - это макросы, но с произвольным синтаксисом. Правила Юпиель можно рассматривать как правила парсера Эрли, но с дополнительной частью в виде замены. Невероятно просто, однако, почему-то это еще никто не реализовал.

Алсо, макросы во всех языках могут работать только с термами языка, а не с произвольными синтаксическими конструкциями. К примеру, лишп. В лишпе макросы могут работать только с s-exp.

>>19584 (OP)
Хуюпель.

>>19600
Два чая адеквату

Yupiel Sama no geboku?

>>19789
Оно самое.

>>19584 (OP)
Имбецилы переизобрели лисп. Спешите видеть.

>>19598
ОП, как мне статически тайпчекнуть то что оно высрет в итоговой программе? Ведь я пишу только исходную программу. Без этого твой язык мне не нужен.

Второе: допустим я написал траспилятор на твоём языке. Потом траспильнул вторым транспилятором. Где гарантии типобезопасности на target?

сделай нормально, иначе можно и на racket макросы бомбить

>>19804

> как мне статически тайпчекнуть то что оно высрет в итоговой программе?

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

Предположим, что мы имеем правило Natural (его определение опустим).
Тогда определение операции (+) над Natural будет очевидным:
Natural :: |x : Natural| + |y : Natural| => (+ |x| |y|)

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

Однако, не скрывая правды, target не обязан быть корректным. Если Source и Target представляют из себя Тьюринг-полный языки, то нельзя исключить левую рекурсию. Как ты понимаешь, это не проблема Yupiel, а проблема остановки.

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

Важно так же отметить, что Yupiel - гибкая штука. Она не накладывает никаких ограничений на код. Нормально делай - нормально будет.

К примеру, для надежной системы нужно соблюсти следующие паттерны:

- Отделить выражения и эффекты.
Не допустить конструкции вида ‹print(x) + print(print(y))›
Есть выражения, которые что-то возвращают, а есть действия/эффекты, которые что-то делают, но сами ничего не возвращают. Взболтать но не смешивать.

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

>>19801
Lisp вообще не про это.

Первое - все лиспы имеют рантайм. Нет лиспа без рантайма. Это сразу выносит на нет возможности бесшовной транспиляции.

Второе - лисп, как и все остальные языки, ограничен синтаксисом, а именно s-exp. Если начнешь расширять s-exp кастомным парсером, то просто создашь ограниченную версию Yupiel.

Третье - лисп это язык (хоть и с мощным метапрограммированием). Yupiel - это метаязык. Как EBNF.

>>19794
Довольно красивая девочка...

>>19590
Грамматику нулевого уровня по Хомскому, если быть точнее.

>>19934
Несешь бред. Грамматика нулевого уровня типа Semi-Thue это иная, очень упрощённая концепция, и что важно неюзабельная концепция. Погугли Thue lang. Yupiel использует CFG (Context Free Grammar), а это нихуя не нулевой уровень.

>>19999

> Pattern => Replacement

У тебя нет ни ограничения по длине слов, а значит это уже не уровень 1, и хотя про уровень 2 уже нельзя говорить, у тебя

> Pattern - набор символов и нетерменалов.

нет ограничений по нетерминалам слева, какой нахуй контекст фри граммар.

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

>>20045

> нет ограничений по нетерминалам слева, какой нахуй контекст фри граммар.

В случае паттерна, исключением из символов является соответственно (=>). Если нужно использовать (=>) как символ используй экранирование (\=>). Тоже касается табов (\t), перевод строки (\n). Так же, для удобства один символ пробела (" ") считается за (whitespace+).
Т.е паттерн "print x" соответствует "print　x", так и "print x".

Что читать, чтобы оперировать такими же терминами как вы?

>>20182
Как минимум Википедию. Важно самому всё пробовать и разбираться.

>>20465
Так а что гуглить то вообще?

>>20475
Для понимания треда:
- Полнота по Тьюрингу.
- Иерархия Хомского.
- Система переписывания.
- Парсинг.
- Алгоритм Маркова и Semi-Thue (Грамматики типа 0).
- Метапрограммирование

>>20095
Ииииии, мы изобрели s-expressions.

>>19822
Твой яп наверное не в вакууме работает а в каком-то вычислительном устройстве "рантайме".
С точки зрения теории яп все реальные языки имеют рантайм.
И уже поэтому твои заявления мягко говоря странные.

>>21075

> Ииииии, мы изобрели s-expressions.

Я действительно не понимаю где тут связь.

Чтобы вы поняли, что такое Юпиэль, я приведу пример программы.

# модуль HelloWorld.ypl

Effect :: say |n : Note|! => console.log("|Hi World|")
Letter :: |x : or C D E F G B A|
Octave :: |x : 1 2 3 4 5 6 7 8|
Note :: |l : Letter||o : Octave| => note("|l|", |o|)

# source source.txt
say C4!

# после запуска в консоли "yupiel -m HelloWorld -s source.txt -t target.js" в папочке с проектом появится target.js с таким содержанием:
console.log(note("C", 4))

Теперь понятно, что такое Юпиэль?

> Твой яп наверное не в вакууме работает а в каком-то вычислительном устройстве "рантайме".

Хех, у него действительно нет рантайма. Юпиэль не знает ни о операции (+), ни о IO. Юпиэль занимается транспиляцией только и всё, соответственно "паразитируя" на других языках. Как в примере выше. Используется встроенная в js console.log. Можно транслировать в какой хочешь язык.

>>21153
И в чём основное преимущество такого подхода перед обычными языками? Только сформулируй по делу самый главный тезис

>>19820
спасибо за ответ, ОП.
Извини, что я плохо во всём таком разбираюсь. У меня есть только хотелки сумелок нет

Хотелка 0 (?):
Мне всё-таки кажется что я хочу корректный таргет. Понятно, что source программу я не смогу запустить, а только таргет. Если некорректно был написан сорс, то запуск таргета может выдать непонятную балалайку в консоль и ищи свищи где в сорсе ошибка. Там же будет в этом юпиэле тайп инфиренс, хиндли милнер вот это всё? Я правильно понимаю, что нормальные сообщения об ошибках невозможно получить, так как это проблема останова уже?

Хотелка 1:
Так как это языко-ориентированный язык, хочу писать собственные DSLы (например JSON-подобные (в которых будут в том числе enumerable типы полей)), хочу под каждый такой dsl сгенерированный language server, чтобы в редакторе мне подсказочки выдавало при написании на таком dsl, и говорило валидный у меня файл или невалидный, выдавало где ошибочки. DSL безо всяких вычислений, чисто декларативная простыня чтобы для конфигов. Сможет ли юпиэль в такое?
Я знаю существует Xtext и Jetbrains MPS. Но они выглядят всратыми, даже лень осиливать такое. Кроме того они требуют целые IDE.

Хотелка 2:
хочу писать и запускать домэйн специфик стэйт машины. Xtext такое кажется умеет

Вопрос:
Сущестует ли что-то более лайтвэйт на рынке чем xtext и mps? Просто лень эти читать простыни из документации для того чтобы написать dsl уровня "пук-среньк"

Похвалить:
У юпиэль отличная маркетинговая стратегия: собирать лидов на три строчки синтаксиса

>>22089

> Хотелка 0 (?):

Надо еще думать о возможности создавать прозрачный для кода дебаг. Сильной стороной Yupiel является (будет) прозрачная встраиваемость. Что если в рантайме появился эксепшен? Как фиксить? Над этим стоить думать. Решением может быть:
- На этапе создания DSL: юнит-тесты языка.
- На этапе использования DSL: зависимые типы.

> Хотелка 1:

Будет поддержка Yupiel в каких-нибудь VSCode. Если где-то появилась синтаксическая ошибка, редактор пометит. Для всех остальных фич редакторов не может быть универсального решения. Можно только создать универсальный формат для написания документации, откуда его можно будет транслировать в специфичный формат редактора.

> Вопрос:

Ну, я знаю Racket. Но там тоже ахуеешь всю документацию языка читать.

Единственным решением является, ВНЕЗАПНО, Юпиэль. Не просто так я её решил создать. Если бы был, хотя бы даже шизотреический, язык с свойствами схожими с Юпиэль, то мысль о создании этой утилиты у меня даже бы не появилась.

> У юпиэль отличная маркетинговая стратегия: собирать лидов на три строчки синтаксиса

Хех, это да. Лиды делают DSL, джуны на этих DSL пишут.

>>21153

> Хех, у него действительно нет рантайма. Юпиэль не знает ни о операции (+), ни о IO. Юпиэль занимается транспиляцией только и всё

Это слишком тупой троллинг.
х86 цп знает что такое транспиляция? А +- он знает. Так КАК твой дупель делает транспиляцию на железе с +- и без транспиляции?

Ты на какой доске вообще решил дерьма в уши людям лить придурок?

>>21153

> Я действительно не понимаю где тут связь.

Учи лисп.

>>22231
Ты компиляцию от рантайма отличаешь? Ясен хуй, что транспилятор/компилятор это программа, которая запускается на компьютере. Однако с рантаймом это не связано. Есть этап компиляции/транспиляции, есть рантайм. Yupiel занимается только транспиляцией. Что там в рантайме произойдет уже не забота Юпиэль, а забота какого-то другого компилятора/интерпретатора (V8, ghc, python, к примеру).

>>22235

> Учи лисп.

Чел, я пишу прототип Yupiel на Racket.
Лисп и Yupiel это совершенно разные языки.
Ты где вообще взаимосвязь нашел?

>>22258
Выглядит как типичный лисп.

>>22243

> Чел, я пишу прототип Yupiel на Racket.

Ты используешь лисп для создания dsl чтобы сделать dsl для создания dsl.

> Ты компиляцию от рантайма отличаешь?

Окей, я немного протупил.
Так есть лиспы компилируемые в С, и что теперь?

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

>>21153
По-моему у тебя ошибка в коде.

Интересно как в юпеле записать что в случае чисел от 10 до 20 делать одно, а в случае от 21до 23 другое. Ну например это часть имени функции - делать21 например.

Или как простейшую типизацию описать.

>>21153
Пиздос, а не легче самим ручками написать в .js файле console.log чем описывать его в каком то юпель несколькими строками кода, которые ещё и хуй поймёшь как работают

>В языке есть только одна конструкция - правило. Вся программа на Юпиель представляет из себя список правил вида: Type :: Pattern => Replacement или Type :: Pattern

>первый пример: какие-то стрелки, ООП

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

>>19584 (OP)
Ты переизобрел алгоритм маркова и назвал его своим ЯП?

>>22124

>X0:

>Решением может быть:

>- На этапе использования DSL: зависимые типы.

вот это пожалуйста. можно? голосую за зависимые типы

>X1:

>Будет поддержка Yupiel в каких-нибудь VSCode.

Требуется поддержка не самого юпиел в вскод а автоматическая поддержка созданного dsl. Понятно, что скорее всего одним ypl не обойтись
надо вот так чтоб:
https://youtu.be/5WA8kCdg6Ek?t=997
и как-то так
https://youtu.be/ESRk7NmCDFA?t=608

>Хех, это да. Лиды делают DSL, джуны на этих DSL пишут.
I mean https://en.wikipedia.org/wiki/Lead_generation

> Racket

>я пишу прототип Yupiel на Racket.

А пакеж сорсы. Интересно

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

>>23804

> DSL

Боярское программирование, лол. Что тебе мешает определить что угодно через дефайн и использовать для любой предметной области любой язык общего назначения? Насчёт неточности нейросетей, зря ты веруешь, что rule-based transpiler будет сильно точнее.

>>19584 (OP)
Ты только что PEG.
https://en.wikipedia.org/wiki/Parsing_expression_grammar

>>23825

> Что тебе мешает определить что угодно через дефайн

Ты про #define? Это достаточно хреновый инструмент, на самом деле.

> предметной области любой язык общего назначения?

Который, естественно, привязан к своей экосистеме? Нет, спасибо.

> Насчёт неточности нейросетей, зря ты веруешь, что rule-based transpiler будет сильно точнее.

"Rule-based" означает, что система завязана на точной математической логике. Я даже планирую добавить в STD Yupiel рационалы, вместо дырявых float.

>>23832

> Ты только что PEG.

Так Юпиэль это CFG, я уже весь тред это говорю. Можно сказать, что Yupiel это продукт, как NPM к примеру. Пакетные менеджеры и до этого существовали, никто же не говорит, что NPM Inc. создало велосипед. Когда создавалась Scala никто не говорил, что разработчики Scala изобрели ФП, тоже самое с Clojure и Racket.

Алсо, Yupiel это не PEG. В PEG невозможны создания грамматик с левой рекурсивной частью типа: Expr -> Expr "*" Expr, а в Yupiel возможны, потому что под капотом Earley, а не PEG.

>>23841

> потому что под капотом Earley, а не PEG.

Лисп у тебя под капотом.

ОП, давай скорей пиши. Уже давно такое надо. Сразу его в индустриальные задачи и будем монетизировать бабло грести лопатами. DSLы будем писать для домохозяек. DSLы для управления башенными кранами, авторучками и газовыми горелками. DSL чтобы выйти из дома, открыть дверь, потушить свет в коридоре. DSLы в терминах бизнес сущностей, чтобы мышкой программировать серверлес приложения в реальном времени разворачиваемые на облаке. ДСЛ для неба и даже для велосипеда

>>25675
DSL для DSL'ей забыл

Я так понимаю пока что:

LispMacro :: s-exp --> s-exp
YPL :: ypl-expression --> any_target

>>19584 (OP)
Зачем ты изобрел лисп?

>>27295
Почитай тред. Устал объяснять.

>>27295
как в лисп ты заведёшь any_target?

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

>>20521
А пока вы читаете ваши хуерархии хуёмского, нормальные люди зарабатывают деньги на Javascript. Поссал на задротов.

Всем привет, с вами Гоша Дударь, сегодня мы будем учить юпиль за 1 час

POC делается за вечер https://pastebin.com/YQLp47gT по внятному описанию. У ОПа какая-то каша в синтаксисе >>19584 (OP), такое ощущение, что он примеры на ходу придумывает. Вот это >>22496 я вообще не знаю, как воспринимать.

>>29123
Мда, будь я ОПом мне было бы очень обидно и стыдно - когда твою идею реализуют за вечер, пока ты дрочишься с ракетом и споришь в треде...

>>29123
Чел, у тебя есть один огромных размеров прокол. У тебя там синтаксис должен соответствовать синтаксису хаскелла.

>>29351
Оно вообще делается на голом Хаскеле:

import Text.Parsec hiding (letter)
main = either (putStrLn . show) (putStrLn) . parse effect "-" =<< getContents

effect = do { string "say"; spaces; n <- note; string "!"; () ==> "console.log(" ++ n ++ ")" }
letter = l oneOf "CDEFGBA"
octave = l oneOf "12345678"
note = do { l <- letter; o <- octave; () ==> "note(\"" ++ l ++ "\", " ++ o ++ ")" }

l p a = do { c <- p a; return $ c:[] }
infixl 0 ==>
_ ==> b = return b

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

Проблема всех этих метакомпиляторов в тулинге. Начиная от внятных сообщений об ошибках и заканчивая поддержкой редакторов. Что в Yacc, что в C preprocessor, что в шаблонизаторах, что в других подобных. Задумка ОПа, кстати, больше всего похожа на OMeta. У которой была та же проблема с тулингом, и которая в итоге выродилась в никому ненужный Ohm. JetBrains придумали MPS и вроде сделали автогенерацию тулинга, но у них там вообще всё своё, включая уёбищный редактор. Впрочем, я давно его смотрел, не знаю, как сейчас.

Давайте уже быстрей пишите. Хоть на хаскеле хоть на чём

Если все равно нужно все писать вручную, тогда не ясно, чем это >>22496 лучше foreign function interface в idris'е.