Здравствуйте, 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 тупо запрещает чужие компиляторы и интерпретаторы на их мобилах.