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

_>>Для ядра это верно, ну а для игровой логики... Даже в стратегиях суммарное количество юнитов редко превышает несколько тысяч, ну и несколько опциональных полей дадут оверхед в десятки килобайт,
V>А как ты считал? По одному Optional на юнит?

Да даже если по несколько, что это меняет?

V>А в сцене могут помимо юнитов дохрена других объектов с nullable-полями?
V>ИМХО, их может быть десятки тысяч в кадре в современной игре.

Десятки тысяч объектов игровой логики это очень много, а графическим nullable и не нужен.

V>А что в игре занимает гигабайты? (интересуюсь)
V>В основном графические ресурсы?

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

V>>>Утилитный код по ссылке можно организовать в виде методов-расширений для INullable<T>.
_>>К сожалению, нельзя. Extension методы для generic интерфейсов c AOT-компиляцией нормально не работают.
V>Можно неработающий пример?

По ссылкам ниже много примеров:
https://docs.unity3d.com/Manual/ScriptingRestrictions.html#AOT
http://www.mono-project.com/docs/advanced/aot/#limitation-generic-interface-instantiation
https://developer.xamarin.com/guides/ios/advanced_topics/limitations/
https://github.com/neuecc/UniRx/wiki/AOT-Exception-Patterns-and-Hacks
Часть проблем можно обойти, иногда поможет увеличить значение trampolines (type 1 и 2: https://developer.xamarin.com/guides/ios/troubleshooting/troubleshooting/) (ценой значительного роста размера исполняемого файла), но общее правило — без излишней необходимости держаться подальше от любой комбинации дженериков и интерфейсов или виртуальных методов, а также value-типов в качестве дженерик-аргументов.

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

_NN>>Люди хотят ничего не ставить и чтобы работало.
VD>В этом отношении у Явы все намного удобнее. Саму Яву можно поставлять в виде каталога внутри основного продукта. Не раз видел, что разные плагины к Эклипсу доступны не только в виде плагина из галереи, но и в виде zip-архива в котором лежит Эклип, Ява и установленный в Эклипс плагин. Тупо качаешь архив, распаковываешь и используешь плагин в Эклипсе. Очень просто получается.
monodevelop дошли до flatpak в линуксах — таким образом появляется и monodevelop и mono райнтайм доступный только для него. Правда запускается загадочно (через flatpak), и прямо сейчас из-за изоляции(?) — запуск процесса по CTRL+F5 с внешней консолью — приводит к ошибке — как минимум эмулятор консоли не лежит где ему надо (ну а системный и что более важно — дефолтный в системе — не используется). Походу задолбались они бороться с этими крутыми пакетными менеджерами. Что ещё раз доказывает "коробочный" продукт не должен иметь зависимостей от системы (кроме необходимых). Так или иначе — с flatpak тоже выходит проще. Но это вообще, просто к слову.

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

F>>Но по голому факту: мэйнстрим фронты используют ужаснейший recursice descent.
V>Это просто декомпозиция грамматик.
Ты можешь называть их как хочешь, я бы сказал наоборот — позволяет динамически видоизменять грамматику (это скорее композиция), ведь ключи компиляции c99,c11 и т.п. напрямую влияют на этот процесс. Ну и это проще отлаживать — ведь стэк содержит всё что надо, так что можно довольно легко "осмотреться".
Понятно, что на основе GLR и других подходов можно добиться даже бОльшего и вроде как и проще, но прийдется как минимум написать толковый генератор парсера с какими-то уникальными расширениями. В итоге, имхо, — проще сопровождать 1-2Мб кода без всяких выворотов, особенно когда сам язык и его грамматика вполне это позволяют. Вдобавок и работают быстро. Для промышленных C/C++ — это вполне оправдано.
Интересно какие парсеры используются в icc и msvc.

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

F>>Ноборот, в GLR говорят совремегный C++ разбирать легче. Но по голому факту: мэйнстрим фронты используют ужаснейший recursice descent.
WH>GLR, GLL, Earley или любым другим алгоритмом, умеющим парсить все контекстно-свободные грамматики разбирать естественно проще чем неким огрызком, которому то одно правило не нравится то другое.
Ну, GLR ещё хорош тем, что он легко комбинируется с другими крамматиками для создания языков с вложенными языками. The Spoofax Language Workbench его и используют (SGLR). Но мне не попалась ни одна статья где бы *GLR был реально быстр по сравнению с другими. Но я с удовольствием бы посмотрел на такой, лучше на примере грамматики c/java-подобного языка, если таковые существуют. Кажется я повторяюсь. Ы.

F>> Я без бюсысли на уого-то из вас наезжать — и твк ясно спор — давний и я тут — лишний. Я просто дал уточнение — что фронты совоеменных языков нмкогда не используют LR. Но фронты развивающихся — юзают.
WH>Просто быстрое начало. В начале разработки нитры тоже в качестве парсера использовался ужос. Но когда нитра заработала ужос выкинули и заменили на нитру.
Ужос — это PEG/Packrat с расширениями? Теперь база на чем? На нём же но ещё большим количеством расширений/оптимизаций? Или это уже можно реально классифицировать как-то иначе?

F>>>> — сложно сообразить вменяемый еррор репортинг;
WH>>>А вот тут пофигу.
WH>>>Парсер нитры не генерирует сообщения об ошибках.
F>> Ты забываешь, что не нитрой единой.
WH>Я ничего не забываю. Просто говорю, что парсеру не обязательно генерировать сообщения об ошибках.
WH>Их можно сгенерировать по полученному АСТ.
WH>Так получается проще и качественней.
Но для того что бы получить АСТ — нужно ещё наколдовать восстановление ошибок, а это ещё одна задача. Вы в нитре же вроде вставляли "недостающие" символы и таким образом получалось "правильное" дерево разбора? Я читал пост/статью но уже всё забыл. Вообще я скорее всего неверно/неясно выразился — я прежде всего имел ввиду восстановление после ошибок. А насчет как и где проще и качественней — ну это уже вопрос к разработчикам того или иного языка. Если рукописный парсер видит ошибку и может её правильно идентифицировать прямо при парсинге — почему нет. Скорее всего и восстановление будет от этого зависеть.

F>> Насчет бутстрапа — мне кажется что любой вменяемый ЯП захочется бутстрапиться. С нитрой *пока* что это не выглядит возможным.
WH>1)Не любой. Например, как ты будешь SQL бутстрапить? Да и зачем?
Я безусловно имел ввиду любой язык общего назначения, в результате компиляции которого появляются исполнимые (объектные) модули.

WH>2)Нитра уже частично бутстапится.
Хм. Разве не полностью?

WH>Вообще наша философия в том, что каждая задача должна быть решена на языке заточенным на решение этой задачи.
WH>Нитра это набор языков, созданных для разработки компилятора.
WH>Написание компилятора, на языке, который на это не заточен это в лучшем случае в десятки раз больше работы чем на нитре.
WH>Нитру нужно бутстрапить по тому что она сама по себе компилятор. И лучший способ написать нитру это написать её на нитре.
WH>И не по тому что языки обязательно должны бутстрапиться, а по тому что нитра создана для создания компиляторов.
Почему нитра должна быть написана на нитре — мне понятно. Почему ЯОП не должен быть написан сам на себе — непонятно.

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

F>> Так и с нитрой — инструмент на сегодняшнмй — аховый. Я уже спрашивал... Влад очень подробно объяснил. Но, на сейчас: по факту — или ты живешь с рантаймом да ещё под дот нетом или бери любой другой инструмент (удовлетворяющий задаче).
WH>В чём проблема компилятору языка быть написанным на .НЕТ?
В том, что к нему могут быть предъявлены иные требования, чем те, которые ты считаешь удобными.

WH>.НЕТ в нужном объёме сейчас есть везде. И на машину разработчика поставить его не проблема.
На андроиде по факту его нет. А вот нэйтив — есть.

WH>А сгенерированный код может быть любым. И о .НЕТ даже не догадываться. Таким образом в продакшене .НЕТ не нужен.
Парсер / компилятор — может быть частью продукта, поставляемого банально вместе с мобильным приложением.

F>> Ты пойми правильно — мои выпады о стратегии развития и они реальны.
WH>Я просто так и не понял, что у тебя за выпады.
В основном то, что это прибито к дотнету. Я уже спрашивал Влада — Влад подробно всё расписал что нужно предпринять, что бы эта ситуация изменилась. Так этот вопрос можно считать закрытым.

WH>>>Разница в том, что автор ANTLR4 профессор. Ему нужны статьи, а мне от них ни жарко, ни холодно.
F>> Но ими можно доказать людям что впша придумка не фикция.
WH>Нельзя.
Ну людям может быть интересно просто как он устроен и понимать что от него ожидать. Например используется ли backtracking, строится ли лес деревьев и ещё туча вопросов. Врядли кто-то ожидает доскональный алгоритм — но обзорно — вполне.

F>>Это раз. Во-вторых — профессору пришлось потратить 20 лет на эту статью. WH — ты вот недавно предложил человпку парсер в другом форуме — всё супер. Но... если бы ты дал ссылки на внешние ичточникм — было бы хорошо. Но ещё лучше — если бы ты описал все свои чаяния и/или нитра алгорттм в любой доступной тебе форме.Если профессор сука потратил 20 лет на сраный кеш правил и назвал это ALL — неужели ты не можешь что-то подобное совеошить?
WH>Алгоритм нитры это промышленное, а не академическое решение. И как следствие это не красивый алгоритм, а жуткий монстр. Примерно, как IntroSort (сборная солянка из нескольких сортировок) только намного сложнее.
WH>Я устану его описывать.
WH>Тем более что у меня есть желание неслабо его переделать.
WH>Нужно только с духом собраться.
Уже выше написал. Я думаю — достаточно обзорного описания с базовыми принципами.

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

F> Ну, GLR ещё хорош тем, что он легко комбинируется с другими крамматиками для создания языков с вложенными языками. The Spoofax Language Workbench его и используют (SGLR).
Тоже мне рокетсайнс.
Нитра вообще может грамматику во время разбора изменять.

namespace A
{
  using syntax CSharpJson.Extention;//вот тут мы добавили синтаксис json
  
  class Foo
  {
    int Bar()
    {
      var x = json: 
        [1, 
          {
            "prop1": cs: 1 + 1 == 2 ? 42 : 234 * json: { "asdas" : "ssss" } + 123,
            cs : "text"
          }
        ];
    }
  }
}//а вот тут он отключился.
//Если тут будет код, то синтаксиса json в нйм уже не будет.

Вот так выглядит код на нитре который объеденияет грамматики.

namespace CSharpJson
{
  syntax module Extention
  {
    using Nitra.Core;
    using CSharp.Core;
    using Nitra.Tests.JsonParser;

    //вставляем json в выражение C#
    extend syntax CSharp.Core.Expression
    {
      | Json = "json" ":" Nitra.Tests.JsonParser.Value;
    }

    //вставляем C# в значение json
    extend syntax Nitra.Tests.JsonParser.Value
    {
      | CSharpExpr = "cs" ":" CSharp.Core.Expression;
    }
  }
}

F>Но мне не попалась ни одна статья где бы *GLR был реально быстр по сравнению с другими. Но я с удовольствием бы посмотрел на такой, лучше на примере грамматики c/java-подобного языка, если таковые существуют. Кажется я повторяюсь. Ы.
Вот мне тоже не попадались такие статьи.

F> Ужос — это PEG/Packrat с расширениями? Теперь база на чем? На нём же но ещё большим количеством расширений/оптимизаций? Или это уже можно реально классифицировать как-то иначе?
Ужос это рукописный парсер который валился на первой ошибке.
Сейчас для разбора нитры используется сама нитра.

F> Но для того что бы получить АСТ — нужно ещё наколдовать восстановление ошибок, а это ещё одна задача. Вы в нитре же вроде вставляли "недостающие" символы и таким образом получалось "правильное" дерево разбора? Я читал пост/статью но уже всё забыл. Вообще я скорее всего неверно/неясно выразился — я прежде всего имел ввиду восстановление после ошибок. А насчет как и где проще и качественней — ну это уже вопрос к разработчикам того или иного языка. Если рукописный парсер видит ошибку и может её правильно идентифицировать прямо при парсинге — почему нет. Скорее всего и восстановление будет от этого зависеть.
Теоретически лучше всего восстановление после ошибок работает у рукописных парсеров в которые на каждый чих можно вставить костыль.
Но это огромные затраты ресурсов. Десятки человеко-лет для того чтобы рукописный парсер C# стал работать лучше, чем тот что написан на нитре в её нынешнем состоянии. А со временем алгоритмы нитру будут улучшаться, и история с ассемблером и ЯВУ повториться на новом уровне.

WH>>2)Нитра уже частично бутстапится.
F> Хм. Разве не полностью?
Ещё нет.
Парсер используется нитровский.
Типизация в процессе переписывания на движок нитры.

F> Почему нитра должна быть написана на нитре — мне понятно. Почему ЯОП не должен быть написан сам на себе — непонятно.
По тому что тебе придётся потратить минимум в 10 раз больше усилий чем на нитре для того чтобы получить что-то что хоть как-то работает.
Ты пойми простую вещь. Нитра она как SQL. На ней нельзя писать, что попало. Совсем нельзя. Она заточена исключительно на разработку компиляторов.
И именно это позволяет нитре иметь такое же преимущество при разработке компиляторов как SQL имеет при написании запросов к RDB.

WH>>Короче переписывать компилятор, созданный на нитре на любом другом языке просто глупо. Это огромная работа, которая ничего не даст, а только усложнит поддержку и развитие компилятора.
F> Я об этом и говорю. Впрочем ничего не мешает использовать Нитру только для прототипирования грамматики и/или языка.
Ты говоришь прямо противоположное.
Ты предлагаешь написать код на нитре.
После чего выкинуть код написанный на нитре и переписать его на другом языке.
Твоё предложение звучит как предложение переписать запрос к БД с SQL на язык общего назначения. Ничего хорошего из этого не выйдет.

WH>>В чём проблема компилятору языка быть написанным на .НЕТ?
F> В том, что к нему могут быть предъявлены иные требования, чем те, которые ты считаешь удобными.
Какие конкретно?

WH>>.НЕТ в нужном объёме сейчас есть везде. И на машину разработчика поставить его не проблема.
F> На андроиде по факту его нет. А вот нэйтив — есть.
Тебе не нужен компилятор на андройде. Ибо кросс-компиляцию никто не отменял.

WH>>А сгенерированный код может быть любым. И о .НЕТ даже не догадываться. Таким образом в продакшене .НЕТ не нужен.
F> Парсер / компилятор — может быть частью продукта, поставляемого банально вместе с мобильным приложением.
1)Со временем нитра будет нативной.
2)Это что-то очень узкоспециализированное. Можешь привести пример и оценить объём рынка таких продуктов по сравнению с остальными мобильными приложениями? Больше 0.001% или меньше?
3)Если мне не изменяет память apple тупо запрещает чужие компиляторы и интерпретаторы на их мобилах.

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

Первый вариант ответа — уничтожен телефоном. С...Повторяюсь но короче.

UPD: Первое — было стройнее. Этот ответ более скомканый. Еханый андроид. Больше длинных сообщ никогда не буду писать — после свитча между приложениями он перегружает вкладку — мое недописанное сообщение... его и не было получается как бы. Этот ответ в целом повторяет первое — но т.к. устал! и вообще — реально расползлость не совсем так как изначально и правильно. Иногда ответ по факту предшествует квотации. Но всё равно рядом по смыслу. Сорри.

F>> Ну, GLR ещё хорош тем, что он легко комбинируется с другими крамматиками для создания языков с вложенными языками. The Spoofax Language Workbench его и используют (SGLR).
WH>Тоже мне рокетсайнс.
WH>Нитра вообще может грамматику во время разбора изменять.
Что-то я не понял из примера ничего. Забей.

F>>Но мне не попалась ни одна статья где бы *GLR был реально быстр по сравнению с другими. Но я с удовольствием бы посмотрел на такой, лучше на примере грамматики c/java-подобного языка, если таковые существуют. Кажется я повторяюсь. Ы.
WH>Вот мне тоже не попадались такие статьи.
Интереснее не сколько статьи, а реальные реализации. Вот я нутром чую что компиляция 80к модулей с 800мб исходами — вместо нынешних 2х часов — легко бы уплыла в 3. Но нутро — не показатель. Нынешние 2 часа это конечно реальные плюсы но с LTO. Т.е. они конечно дохера работы делают, но и линковка (кодогенерация) вполне может на пол часика залипнуть но в 2 часа это не входит. Но — интуиция — увы — не показатель. Более того — даже (что скорее всего) — если скорость парсинга тут не столь критична — без реальных докозательств судить банально не о чем. Но это просто работает против GLR т.к. по нему относительно мало инфы. В тоже время, ИМХО, фильтрация его леса — математически определены весьма странно, что опять же не делает его хорошим кандидатом для парсинга тех же плюсиков. Короче то что там вокруг есть куча невнятных работ — это факт. Внятные — остаются таковыми безотносительно темы.

Мне довелось почитать работы про 3х мерные построения фракталов. Приятно было читать всё. Как статьи про парсеры — то вода — то реклама — то значки невнятные. Итого — только половина внятных статей. Остальные нужно под микроскопом разбирать. Имхо — работы по GLR в основном — как раз про микроскоп. Так что не удивлюсь что мы вме не умеем его готовить.

WH>Ужос это рукописный парсер который валился на первой ошибке.
WH>Сейчас для разбора нитры используется сама нитра.
Но ты ж как-то бы мог классифицировать используемый алгоритм?

WH>Теоретически лучше всего восстановление после ошибок работает у рукописных парсеров в которые на каждый чих можно вставить костыль.
Имхо, в рукописниках — там как раз костылей меньше чем можно подумать. Думаю что логично вставлять — минимально необходимые. Мощность же ручных костылей от автоматического восстановления по правилам (или даже совсем без правил) — думаю сравнима. Тут же ж качественный алгоритмический скчаек — RD просто обязаны делать вручную, в то время как генерируемые — нет.

WH>Но это огромные затраты ресурсов. Десятки человеко-лет для того чтобы рукописный парсер C# стал работать лучше, чем тот что написан на нитре в её нынешнем состоянии. А со временем алгоритмы нитру будут улучшаться, и история с ассемблером и ЯВУ повториться на новом уровне.
Я походу чёт лишнего стер. Кратко — не быть тебе евангелистом. Я говорю — вариант использования нитры с zero-work со стороны команды нитры — а ты говоришь что это плохо и десятки человеко лет.

F>> Почему нитра должна быть написана на нитре — мне понятно. Почему ЯОП не должен быть написан сам на себе — непонятно.
WH>По тому что тебе придётся потратить минимум в 10 раз больше усилий чем на нитре для того чтобы получить что-то что хоть как-то работает.
Технологически — ты щас говоришь рекламный слоган. На сейчас — нитра — нехилая неотделяемая зависимость которая тянет за собой дотнет. Сколько и кто на что потратит — не суть. Я говорю об технологических ограничениях использования — ты же придумываешь что-то вообще извне. С чего в 10 раз больше-то? Без знания целевого языка — ты вообще не можешь делать оценок.

WH>Ты пойми простую вещь. Нитра она как SQL. На ней нельзя писать, что попало. Совсем нельзя. Она заточена исключительно на разработку компиляторов.
Но разве пользователь не может хотеть компилятор внутриклиентского приложения? Компилятор/транслятор запросов — ныне — широкая практика. А формализма — хватает для использования генераторов парсеров. Ну или ad-hoc.

WH>И именно это позволяет нитре иметь такое же преимущество при разработке компиляторов как SQL имеет при написании запросов к RDB.
Угу. При этом RDB — хочет парсить запрос. При этом лишь одна RDB имеет дотнет. Очень смешно.

WH>>>Короче переписывать компилятор, созданный на нитре на любом другом языке просто глупо. Это огромная работа, которая ничего не даст, а только усложнит поддержку и развитие компилятора.
F>> Я об этом и говорю. Впрочем ничего не мешает использовать Нитру только для прототипирования грамматики и/или языка.
WH>Ты говоришь прямо противоположное.
В общем я на этот тезис ответил выше — про евангелизм. Я сказал можно, я не сказал нужно. Причем это вполне может быть логично и оправдано. Кто заставляет использовать всё сразу? Насколько я знаю — никто.

WH>>>В чём проблема компилятору языка быть написанным на .НЕТ?
F>> В том, что к нему могут быть предъявлены иные требования, чем те, которые ты считаешь удобными.
WH>Какие конкретно?
Дотнет? Я выше сказал — SQL парсер не хочет дотнет в another mysql. Для ЯОП — это вообще смешно. Там как бы хочется кросс-платформной компиляции, при том в минимальных средах. Веры в дотнет как повсеместно доступный продукт — небыло, нет и не будет. Подобно бутстрапу компилятора — бутстрап системы тоже начинается с ограниченного набора тулзов. Тулзы которые имеют тупые технологические ограничения (сюда включается банально слишком сложная машинерия что-бы что-то собрать) — просто покидают список и идут на следующий уровень.
Технология — это возможности, а не ограничения. Так или иначе Влад отлично расписпл что необходимо что-бы сделать Нитру более податливой в этом смысле.

F>> На андроиде по факту его нет. А вот нэйтив — есть.
WH>Тебе не нужен компилятор на андройде. Ибо кросс-компиляцию никто не отменял.
Ещё раз — продукт — есть то что должно встраиваться в любое приложение. Сейчас — продукт — это внешнее приложение под дотнетом со всеми вытекающими ограничениями. Это не так плохо, но это — ограничение. Для мобильного мира — так точно.

F>> Парсер / компилятор — может быть частью продукта, поставляемого банально вместе с мобильным приложением.
WH>1)Со временем нитра будет нативной.
Дай бог. Нитра как раз может крутиться спокойно на ботнете вечно. А вот продукты — нет. Нт скорее всего ввиду устройства — она сама смлжет быть нативной. И то хорошо. Но это не про сейчас. Там работы... больше чем написать 10 парсеров С++ с нуля.

WH>2)Это что-то очень узкоспециализированное. Можешь привести пример и оценить объём рынка таких продуктов по сравнению с остальными мобильными приложениями? Больше 0.001% или меньше?
Это не честно такое спрашивать меня. Спроси себя сам — ответ будет приблизительно той же точности и как результат — ниочём. Тема вообще узкая. Что делает твоих юзеров — до дефолту хотя бы средними а скорее всего — много выше. В итоге — они хотят внятных объяснений/данных и т.п. Иначе просто протолкнуть может быть в сотни раз сложнее. Опять же — чисто ИМХО.

WH>3)Если мне не изменяет память apple тупо запрещает чужие компиляторы и интерпретаторы на их мобилах.
Слышал о swizzling? Без него — в этом прекрастном мире apple — просто невозможно. Так что я бы не поминал их вообще если честно.
Пусть они назовут красным — синий — они всё равно будут ехать на юг и никто серьезно не будет на это недоразуменее обращать внимание.

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

F>> Ну, GLR ещё хорош тем, что он легко комбинируется с другими крамматиками для создания языков с вложенными языками. The Spoofax Language Workbench его и используют (SGLR).
WH>Тоже мне рокетсайнс.
WH>Нитра вообще может грамматику во время разбора изменять.
Я посмотрел пример еще раз. Не увидел где во время разбора — ты показал композицию грамматик и расширение правил, аналогичную в вышеозвученной тулзе. Ну вроде как. Поменять правила во время разбора — это что-то вроде проверки опции компилятора в правилах парсинга. И совсем патология — если эти опции могут меняться динамически — во время разбора. Я мож непонял что-то. Но что ты имел ввиду под изменением прпвил прям во время разбора — я из этого примера точно не понял.

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

_>но общее правило — без излишней необходимости держаться подальше от любой комбинации дженериков и интерфейсов или виртуальных методов

В примере генерик-интерфейс служит исключительно как ограничение для T, а не как целевой тип.
Насколько я понял — это проблемы Mono?


_>а также value-типов в качестве дженерик-аргументов.

А вот сам T непременно должен быть value-type или смысл 90% трюков на генериках пропадает.
Собсно, это единственный эффективный сценарий для генериков дотнета и если он не поддерживается в моно АОТ, то это просто ой. ))

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

F>>>Но по голому факту: мэйнстрим фронты используют ужаснейший recursice descent.
V>>Это просто декомпозиция грамматик.
F> Ты можешь называть их как хочешь, я бы сказал наоборот — позволяет динамически видоизменять грамматику (это скорее композиция)

Пофик.
Разбиваем целое на части — декомпозиция.
Собираем целое из частей — композиция.


F>ведь ключи компиляции c99,c11 и т.п. напрямую влияют на этот процесс.

Да.

F>Ну и это проще отлаживать — ведь стэк содержит всё что надо, так что можно довольно легко "осмотреться".

Это только в тривиальных вещах, типа высокоуровневых объявлений.
А математические вложенные выражения с вызовами ф-ий отродясь было удобней восходящим разбором парсить.
Там и стек разбора более удобен для "осмотреться", бо в нём уже присутствуют свернутые однозначные нетерминалы. Сравнить с нисходящим разбором, где в каждый момент времени имеем лишь один из потенциальных вариантов.


F> Понятно, что на основе GLR и других подходов можно добиться даже бОльшего и вроде как и проще, но прийдется как минимум написать толковый генератор парсера с какими-то уникальными расширениями.

Фишка в том, что все мейнстримовые генераторы парсеров умеют генерить LR-разбор (LALR/GLR). А вот дополнительно LL(k), или обобщенный LL(1), т.е. Эрли — лишь считанные единицы из них. И такое жжж не спроста. (С)


F>В итоге, имхо, — проще сопровождать 1-2Мб кода без всяких выворотов, особенно когда сам язык и его грамматика вполне это позволяют.

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


F>Вдобавок и работают быстро. Для промышленных C/C++ — это вполне оправдано.

Быстро — это когда без откатов, т.е. LR-семейство.
Для LL(1) быстро будет только на заведомо однозначных выражениях — ну вот объявление типа, например. Такую ерунду легко парсить ручным LL(1-2) парсером (т.е. с предпросмотром на 1-2 лексемы).


F>Интересно какие парсеры используются в icc и msvc.

Я же сказал, сегодня практически ВСЕ коммерческие компиляторы С, С++, шейдерные диалекты С, встраиваемые диалекты С и С++ — все они пользуют EDG С/C++ front end.

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

F> Мне довелось почитать работы про 3х мерные построения фракталов. Приятно было читать всё. Как статьи про парсеры — то вода — то реклама — то значки невнятные. Итого — только половина внятных статей. Остальные нужно под микроскопом разбирать. Имхо — работы по GLR в основном — как раз про микроскоп. Так что не удивлюсь что мы вме не умеем его готовить.
А GLR никто не умеет готовить. Ибо если его можно было приготовить, то трепло бы не трепалось, а давно бы показало быстрый GLR.

F> Имхо, в рукописниках — там как раз костылей меньше чем можно подумать.
Я их видел и писал... так что про костыли в них знаю довольно хорошо.

WH>>Но это огромные затраты ресурсов. Десятки человеко-лет для того чтобы рукописный парсер C# стал работать лучше, чем тот что написан на нитре в её нынешнем состоянии. А со временем алгоритмы нитру будут улучшаться, и история с ассемблером и ЯВУ повториться на новом уровне.
F> Я походу чёт лишнего стер. Кратко — не быть тебе евангелистом. Я говорю — вариант использования нитры с zero-work со стороны команды нитры — а ты говоришь что это плохо и десятки человеко лет.
Похоже у одного из нас очень серьёзные проблемы с русским языком.

F>>> Почему нитра должна быть написана на нитре — мне понятно. Почему ЯОП не должен быть написан сам на себе — непонятно.
WH>>По тому что тебе придётся потратить минимум в 10 раз больше усилий чем на нитре для того чтобы получить что-то что хоть как-то работает.
F> Технологически — ты щас говоришь рекламный слоган.
Я говорю про свой и не только свой опыт.

F>На сейчас — нитра — нехилая неотделяемая зависимость которая тянет за собой дотнет. Сколько и кто на что потратит — не суть. Я говорю об технологических ограничениях использования — ты же придумываешь что-то вообще извне. С чего в 10 раз больше-то? Без знания целевого языка — ты вообще не можешь делать оценок.
Если целевой язык это нитра вид в профиль, то будет сравнимо.
Если же это очередной язык общего назначения, то затраты вырастут в десятки раз. К гадалке не ходи.

WH>>Ты пойми простую вещь. Нитра она как SQL. На ней нельзя писать, что попало. Совсем нельзя. Она заточена исключительно на разработку компиляторов.
F> Но разве пользователь не может хотеть компилятор внутриклиентского приложения? Компилятор/транслятор запросов — ныне — широкая практика. А формализма — хватает для использования генераторов парсеров. Ну или ad-hoc.
Тут точно проблемы с русским. Ибо эти абзацы вообще не связаны.

WH>>2)Это что-то очень узкоспециализированное. Можешь привести пример и оценить объём рынка таких продуктов по сравнению с остальными мобильными приложениями? Больше 0.001% или меньше?
F> Это не честно такое спрашивать меня.
Ты же утверждаешь, что компиляторы на мобилах нужны. Вот я и хочу узнать насколько они нужны.

F>Спроси себя сам — ответ будет приблизительно той же точности и как результат — ниочём. Тема вообще узкая. Что делает твоих юзеров — до дефолту хотя бы средними а скорее всего — много выше. В итоге — они хотят внятных объяснений/данных и т.п. Иначе просто протолкнуть может быть в сотни раз сложнее. Опять же — чисто ИМХО.
Вообще не понял, что тут написано.

WH>>3)Если мне не изменяет память apple тупо запрещает чужие компиляторы и интерпретаторы на их мобилах.
F> Слышал о swizzling? Без него — в этом прекрастном мире apple — просто невозможно. Так что я бы не поминал их вообще если честно.
F> Пусть они назовут красным — синий — они всё равно будут ехать на юг и никто серьезно не будет на это недоразуменее обращать внимание.
Причём тут swizzling? Мы про необходимость компиляторов на мобилах говорим.

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

F> Я посмотрел пример еще раз. Не увидел где во время разбора — ты показал композицию грамматик и расширение правил, аналогичную в вышеозвученной тулзе.

using syntax CSharpJson.Extention;//вот тут мы добавили синтаксис json

Вот эта строчка изменяет грамматику.

F>Ну вроде как. Поменять правила во время разбора — это что-то вроде проверки опции компилятора в правилах парсинга. И совсем патология — если эти опции могут меняться динамически — во время разбора. Я мож непонял что-то. Но что ты имел ввиду под изменением прпвил прям во время разбора — я из этого примера точно не понял.
Вот так на C# нельзя. C# такой синтаксис не понимает.

      var x = json: 
        [1, 
          {
            "prop1": cs: 1 + 1 == 2 ? 42 : 234 * json: { "asdas" : "ssss" } + 123,
            cs : "text"
          }
        ];

Здравствуйте, D. Mon, Вы писали:

DM>Тут переменные a и b ссылаются на один объект в памяти, это переменные ссылочного типа.

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

В твоём примере a и b — это не ссылочный тип, это специальный тип переменной объектного типа, это алиас.
Устроена эта переменная с т.з. системы типов примерно так же, как Box<> в Rust.

Чем алиас отличается от ссылочного типа? Тем что его значение недоступно.

Для пущего понимания смотри в модуль Array:

val make : int -> 'a -> 'a array
Array.make n x returns a fresh array of length n, initialized with x. All the elements of this new array are initially physically equal to x (in the sense of the == predicate). Consequently, if x is mutable, it is shared among all elements of the array, and modifying x through one of the array entries will modify all other entries at the same time.

Правильно ли я понимаю выделенное, что мутабельная переменная ВСЕГДА имеет ссылочную семантику?
То бишь, сама-то ссылка получается иммутабельная, верно?
А время жизни значения по ссылке обслуживается по GC.
Вот и весь трюк.

Учите матчасть, как грится.
(Сам я первый раз в жизни на это посмотрел — сплошное ЧТД )


DM>Мы вызываем метод, мутирующий объект b

Именно так.
Я тут Владу в соседнем сообщении объяснял:

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

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

http://www.rsdn.org/forum/philosophy/6709456.1

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

Так вот, в твоём oCaml этот самый индекс может быть присвоен переменной лишь однажды.
Даже если переменная якобы мутабельна (медитировать над выделенным выше).

Именно поэтому Box<> в Rust описан как некая структура, внутреннее поле-указатель которого иммутабельно, т.е. присваивается лишь однажды.


DM>Не выйдет, как ни старайся, в языке Окамл ссылки не бывают нулевыми и объекты нуллами.

Индекс не обязан быть 0-м, чтобы быть невалидным.
Просто в OCaml работает GC, и пока на объект есть ссылка, он будет жить.
Вот и весь фокус, повторюсь.


DM>Пример третий: Раст. Там есть ссылки вроде &T, это тоже ссылочный тип, тоже не включает null. Там есть Box<T> ("A pointer type for heap allocation." — первая же строка в описании), который хоть и описан как struct

Так почему он "хоть и описан как srtuct"? ))


DM>на самом деле имеет специальную поддержку со стороны компилятора (см. ключевые слова box, owned_box и пр.) и фактически является указателем с дополнительным поведением. И он тоже всегда ненулевой.

Фактически он является чем описан — структурой.
Аналогом в С++ являются известные тебе умные указатели, которые вводят гарантии сугубо прикладного типа, не даваемые системой типов языка. Т.е., другим способом было бы невозможно выразить вот это "дополнительное поведение".

Смотрю, в Rust умных указателей более одного, например есть slice.
Такой же "умный указатель" с семантикой ссылочного типа, но это НЕ ссылочный тип.
Всё прям как в С++. ))

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


DM>Короче, давай засунь null в переменную объектного типа в окамле, в &i32 в Расте и в String в Котлине. Или GTFO.

1. Rust запрещает aliased mutable reference.
Объяснять — почему?
Или уже догадался?
Потому что алиас может стать невалидным в какой-то момент, если "кто-то" грохнет память по той же самой ссылке.

2. Таки в unsafe можно творить что угодно:

fn index(idx: usize, arr: &[u8]) -> Option<u8> {
    if idx <= arr.len() {
        unsafe {
            Some(*arr.get_unchecked(idx))
        }
    } else {
        None
    }
}

Это пример ошибки из доки, в правильной программе должно быть сравнение на строгое '<'.
В итоге, легко получить невалидную ссылку.
ЧТД.


V>>Разве тебя не впечатлило, что я еще в глаза не видя этого Rust сразу сказал, где у тебя ошибка?
DM>У меня что-то с глазами сегодня. Я что-то не вижу ошибки, извини.

Ты ошибся в утверждении, что Box<> — это ссылочный тип.
На самом деле в системе типов языка это лишь некая структура — smart pointer.


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

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


V>>Почитал далее — всё ясно. Они разнесли nullable и non-nullable ссылочные типы по ТИПАМ, а не по значениям одного и того же типа.
V>>ЧТД. Нубы. Ниасилили ЗТ. ))
DM>Это я тут должен говорить ЧТД и называть тебя нубом. Ибо тут именно ты сел в лужу.

Ты можешь называть что угодно чем угодно.
Пока что лишь ты путал ссылочный тип с его эмуляцией на типах-значениях.


V>>Потому что T+1 != T+1+1
V>>Дальше озвучивать или уже догадался?
DM>Ты опять вперед забегаешь. Давай сперва начало: Option<T> — это не тип, это конструктор типа, функтор, шаблон типа, генерик (выбери знакомое слово). Покажи, где джавский или шарповый string это генерик.

Таак, что у нас тут? ))
"Генерик"... — вообще не при чём.
Никто не мешает делать "строгие" реализации OptionalString и т.д.

"Конструктор типа"... — это некий параметрический тип + мн-во его типовых переменных.

"Покажи, где джавский или шарповый string это генерик"... — вообще мимо.
Эдаким "генериком" у нас является "null", который приводится и к string и к любому другому типу объекта.

Блин, я вижу ВСЕ знакомые слова, но не вижу смысла во всём сказанном. ))

Кароч, плевать на то, что Option<T> — это генерик. Это не принципиально ни разу.
Намек был на то, что в С++ можно оперировать типами T*, T**, T*** и везде прекрасно работает nullptr, а в C# — нельзя.
Для таких вещей надо создавать уже некую прикладную структуру.
Можно Optional<T>, а можно так:
class Box<T> { public T Value; }


DM>Там плохие, неправильные определения. Они не описывают ссылочных типов как минимум в трех упомянутых выше языках.

Они описывают в Rust.
В oCaml было обнаружено того хуже — получили ссылочную семантику на простых мутабельных значениях.


DM>Давай еще подкину:
DM>4) &int в С++

Ссылка может быть невалидной.


DM>5) ref int в D

Аналогично.


DM>Ссылочные типы? Еще как ссылочные. Содержат null / None / Nothing ? Нет.

// C++
bool isNull(int & x) { return !&x; }

int * a = NULL;
int & b = *a;
cout << isNull(b) << endl;

Лень сегодня еще и на D смотреть, но вангую, что там можно так же.

В общем, даже не в этом дело. Ссылка в С++ — это тоже лишь алиас, это не ссылочный тип, т.к. иммутабельна и значение самой ссылки узнать невозможно. Т.е., получаем "прозрачность", т.е. отсутствие ссылочной семантики. Даже по стандарту компилятор С++ НЕ гарантирует, что переменная-ссылка типа будет именно переменной, а не именно алиасом (т.е. символьным оозначением) одного и того же.

По-определению, переменная — это именованный адрес, в котором хранится некое значение. Для ссылки С++ прямо стандартом утверждается, что это НЕ так.

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

V>В примере генерик-интерфейс служит исключительно как ограничение для T, а не как целевой тип.
V>Насколько я понял — это проблемы Mono?

Да, это ограничения Mono AOT. Unity разрабатывают свой бэкенд IL2CPP, но насколько я знаю на данный момент у него те же ограничения.
При этом на PC JIT не запрещен, так что здесь проблем нет.

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

V>В твоём примере a и b — это не ссылочный тип, это специальный тип переменной объектного типа, это алиас.

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

V>Чем алиас отличается от ссылочного типа? Тем что его значение недоступно.

А зачем нужна переменная, значение которой недоступно? В твоем мире фантазий наверняка очень интересно живется.

V>Правильно ли я понимаю выделенное, что мутабельная переменная ВСЕГДА имеет ссылочную семантику?

Насколько я помню, в окамле примерно так и выходит, да.

V>То бишь, сама-то ссылка получается иммутабельная, верно?

Какая? В твоей цитате был пример про массив, его элементы я могу менять, т.е. в нем все "ссылки" мутабельные.

V>А время жизни значения по ссылке обслуживается по GC.
V>Вот и весь трюк.
V>Учите матчасть, как грится.
V>(Сам я первый раз в жизни на это посмотрел — сплошное ЧТД )

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

DM>>Не выйдет, как ни старайся, в языке Окамл ссылки не бывают нулевыми и объекты нуллами.
V>Индекс не обязан быть 0-м, чтобы быть невалидным.

Ну при чем тут невалидность? Тебя несет в сторону.


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

Очень просто: ты себя обманываешь. Тебе кажется, что ты в чем-то разбираешься, но окружающие видят, какую чушь ты несешь. У нас уже руки устали лицо закрывать. Я не знаю, это Даннинг-Крюгер или какое-то расстройство, тут доктор нужен, чтобы определить точнее, как же так получается, что ты так смело рассуждаешь о том, с чем не знаком. Поэтому я, пожалуй, поскипаю большую часть твоего ответа, тут нужна помощь другого рода специалистов.

V>Блин, я вижу ВСЕ знакомые слова, но не вижу смысла во всём сказанном. ))

Вот-вот. Не видишь, а несешь что-то.

V>Кароч, плевать на то, что Option<T> — это генерик. Это не принципиально ни разу.

Это принципиально.

V>В общем, даже не в этом дело. Ссылка в С++ — это тоже лишь алиас, это не ссылочный тип,

Отличная фантазия, поздравляю!

V>По-определению, переменная — это именованный адрес, в котором хранится некое значение.

Азы теории типов и PLT даже рядом не стояли, я понял. Оставлю тебя в твоем мирке.

Здравствуйте, D. Mon, Вы писали:

V>>В твоём примере a и b — это не ссылочный тип, это специальный тип переменной объектного типа, это алиас.
DM>Ну какой еще нафиг алиас, где ты вообще взял это слово?


Ясно.
Можно завершаться.

Алиас — это символьное обозначение одного и того же.
Например, в твоём примере a и b — это одна и та же переменная, а не две.
Учите матчасть.


DM>А зачем нужна переменная, значение которой недоступно?

Верно, не нужна. Значение a и б тебе НЕ доступно.
Т.е. тебе недоступно собсно значение индекса.

Я же тебе говорил уже, что ссылки в том же С++ имеют семантику алиаса.
Т.е., если ты объявил вот так несколько ссылок на одно и то же значение:

int a = 42;
int & b = a;
int & c = b;

То С++ прямо в стандарте предупреждает, что не обещает, что b и c будут разными переменными.
Более того, он вообще не обещает, что будут переменные b и c, он прямо говорит, что скорее всего никаких переменных b и c НЕ будет, а скорее всего будет только переменная a.


V>>Правильно ли я понимаю выделенное, что мутабельная переменная ВСЕГДА имеет ссылочную семантику?
DM>Насколько я помню, в окамле примерно так и выходит, да.

И даже СЕЙЧАС ты не понял, что это означает?
Этот вопрос сверхмегапринципиальный. ))

Потому что получается наборот — мутабельная переменная размещается на куче, но при этом НЕ имеет никакой ссылочной семантики.
А происходящее в array — это лишь побочный эффект такого положения вещей, когда в ФП-язык привносят ср-ва для повышения эффективности — возможность "линейного" расположения данных в памяти.

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

WH>>>2)Попробуй вернуть этот вектор в функцию main таким образом, чтобы тип сохранился.
DM>>Не умею.
WH>А зависимые типы умеют.

Код в студию.

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

WH>>>Код на хаскеле который читает с консоли число и создаёт вектор тип которого зависит этого числа в студию.
DM>>Извините, что встреваю в вашу цивилизованную ученую дискуссию, но такой код как раз несложно пишется:
WH>1)Ты очень вольно интерпретируешь слово зависит.

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

Ты не верил именно в это, т.е. НЕ понимал системы типов Хаскеля.


WH>Тип Vec не параметризуется терминалом. А значит зависимым не является просто по определению.


Учись читать код.


WH>2)Попробуй вернуть этот вектор в функцию main таким образом, чтобы тип сохранился.

Тебе уже ДО демонстрации кода сказали, как "вернуть" прочитанное значение в Хаскеле — через полиморфный колбэк.
В примере этот колбэк показан — это toList.
toList параметризуется неким n, значение которого зависит от терминала.
Т.е., любому типу n ставится в соответствие уникальное натуральное число, потенциально не ограниченное.
ЧТД.

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

WH>>>"type-level literals" это литералы, превращённые в типы.
V>>Это параметры типов прямо по определению.
WH>

WH>Numeric literals are of kind Nat, while string literals are of kind Symbol. This feature is enabled by the XDataKinds language extension.

WH>Род(kind) это множество типов. Прямо по определению.

Класс типов — это тоже мн-во типов, и?
Сорт типов — это тоже мн-во типов, и?
Просто эти мн-ва ортогональны друг другу.

WH>Те значения рода — это типы прямо по определению.

Как и "значения" классов типов и сортов.


V>>Смотри, ты рядом говорил о том, что ЗТ могут работать с БЕСКОНЕЧНЫМИ значениями величин.
WH>Разбирать твой бред у меня нет никакого желания. Ибо ты необучаем.

Говорил или не говорил? Да/нет?


WH>Код на хаскеле который читает с консоли число и создаёт вектор тип которого зависит этого числа в студию. Трепло.

ЗА оскорблениями пытаешься спрятать свою некомпетентность?
Такой код только на моей памяти разбирали на этом сайте минимум трижды — тебе это ГОВОРИЛОСЬ.
Тебе надо, чтобы за тебя искали?
Ну и рядом привели уже.


WH>>>Наоборот. Я обвиняю вас именно в том, что вы переключились с первого на второе. Да ещё и не понимая предмет.
V>>Предметная область там была — НЕКИЕ формулы вычислений.
WH>Разговор был про генерацию кода. Я показал зачем мне она нужна.

Ты так и не показал зачем. Ты показал ровно обратное — пример, в котором кодогенерация не нужна.
Т.е., при том, что она иногда нужна (и мы оба это утверждали), ты умудрился привести самый неудачный пример, чем и подставился под насмешки.


WH>Вы на пару с гапертоном попытались выставить меня некомпетентным.

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


V>>Например, у твоего альфа-бленда есть пару сотен алгоритмов наложения (из исходного базиса):
V>>http://www.gamedev.ru/code/terms/Blending
WH>Ой блин... Это вообще к делу не относится.

Если ты напираешь на семантику формул, то относится.
Это демонстрация того, почему в семантику твоих формул никто и не собирался втыкать.
Потому что — да какая нафик разница?
Этих алгоритмов альфа-бленда — сотни.

Задача у тебя была простая:
— есть некое множество типов-структур с полями, кодирующими цвет;
— есть некое функциональное отображение, которое из двух значений структуры делает одно (если через линейную интерполяцию, или из 3-х через квадратичную и т.д.). Применяется такая формула дважды — по горизонтали и по вертикали.

Примитивщина.
Никакой кодогенерацией тут и не может пахнуть, пока речь о С++.
Для других каких-то языков еще может быть...
Но для С++... ))


WH>>>И сделано это было исключительно с целью доказать, что кодогенерация не нужна.
V>>Т.е., замени одну формулу на другую и ДЕЙСТВИТЕЛЬНО станет не нужна???
V>>Ты хоть сейчас понял, что ты сказал?
WH>Ты точно не понимаешь, что говоришь.

Да все всё понимают.
Свободен.

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

WH>>>>2)Попробуй вернуть этот вектор в функцию main таким образом, чтобы тип сохранился.
DM>>>Не умею.
WH>>А зависимые типы умеют.
V>Код в студию.
Думаешь напугал? Этой фразой только трепло типа тебя напугать можно.
Код на idris.

module Main
import Data.String
import Data.Vect

intToNat : Int -> Nat
intToNat 0 = Z
intToNat x = S(intToNat (x - 1))

getNat : IO Nat
getNat = do
  resp <- getLine
  case parseInteger {a = Int} resp of
     Just value => pure (intToNat value)
     Nothing => do
       putStrLn "error"
       getNat

makeVect : (size : Nat) -> a -> Vect size a
makeVect Z _ = Nil
makeVect (S(x)) v = v :: (makeVect x v)

zipVect : Vect size a -> Vect size b -> Vect size (a, b)
zipVect Nil Nil = Nil
zipVect (x1 :: v1) (x2 :: v2) = (x1, x2) :: zipVect v1 v2

main : IO ()
main = do
  putStrLn "Hello world"
  size <- getNat
  let vect1 = makeVect size size
  let vect2 = makeVect size "^_^"
  putStrLn (show vect1)
  putStrLn (show vect2)
  putStrLn (show (zipVect vect1 vect2))

если
let vect2 = makeVect size "^_^"
заменить на
let vect2 = makeVect (S(size)) "^_^"
то получим

hello.idr:34:33-38:When checking right hand side of main with expected type
        IO ()

When checking an application of function Main.zipVect:
        Unifying size and S size would lead to infinite value

Твоя очередь. Повтори на хаскеле.

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

WH>>>>"type-level literals" это литералы, превращённые в типы.
V>>>Это параметры типов прямо по определению.
WH>>

WH>>Numeric literals are of kind Nat, while string literals are of kind Symbol. This feature is enabled by the XDataKinds language extension.

WH>>Род(kind) это множество типов. Прямо по определению.

V>Класс типов — это тоже мн-во типов, и?
V>Сорт типов — это тоже мн-во типов, и?
V>Просто эти мн-ва ортогональны друг другу.
У меня просто цензурных слов нет.
Ты же вообще ничего не понял.
Сорт типов это пять. Я под столом. Это означает что про теорию типов ты не знаешь ничего от слова совсем.
Есть вот такая иерархия:
term : type : kind : sort : ...
значение : тип : род : сорт : ...
А классы типов тут вообще не при делах. Они вообще не о том.

V>Ты так и не показал зачем. Ты показал ровно обратное — пример, в котором кодогенерация не нужна.
Ты даже не понял о чём мой пример был.
Он был не про альфаблендинг.

V>Если ты напираешь на семантику формул, то относится.
V>Это демонстрация того, почему в семантику твоих формул никто и не собирался втыкать.
V>Потому что — да какая нафик разница?
V>Этих алгоритмов альфа-бленда — сотни.
При масштабировании изображений алгоритм ровно один.

V>Задача у тебя была простая:
Задача у меня была преобразование между различными цветовыми пространствами.
А альфабленд уже следствие твоей попытки что-то мне доказать.

V>Примитивщина.
V>Никакой кодогенерацией тут и не может пахнуть, пока речь о С++.
V>Для других каких-то языков еще может быть...
V>Но для С++... ))
Гонять N^3 для 22х различных цветовых пространств на шаблонах С++ на компиляторах десятилетней давности... ну-ну.