Здравствуйте, Ночной Смотрящий, Вы писали:

V>>В интерпретаторе спектрумовского Бейсика всё аналогично.
НС>Нет, совсем нет. Там именно исходная программа, просто в закодированном виде. Если по современному, то просто поток токенов.

Как я и думал, собсно.
Для некоторых команд проца IBM/360 аргументы тоже представляют себя эдакие токены.


НС>>>Непонятно. Что значит отделения и зачем он в этом топике?
V>>Это значит, что в практике IT редко встречается так, что язык диктует способ своей реализации.
НС>Но тот бейсик как раз демонстрирует обратное.

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


V>>Конечно, возможно.
V>>В первую очередь, возможно принципиально.
НС>То что это, по сравнению с expression tree так и не получило достойного применения как бы намекает, что вариант с перегрузкой операторов и шаблонами имеет существенные недостатки.

Вообще-то получило.
Интроспекция дерева выражений Boost.Proto может происходить не только в рантайм, но и в момент компиляции через диспетчеризацию на шаблонах, т.к. любое выражение полностью статически типизировано и представляет из себя "плоский" граф, построенный на value-type в терминах дотнета.

Например, выражение expr:

auto x= _1;
auto y = _2;
auto expr = sin(x*10 + y*20);

порождает (на пальцах если) примерно такую структуру:

sin_(plus_(mul_(arg_<0>, const_<10>()), mul_(arg_<1>, const_<20>)))

На шарпе это примерно так:

struct SinFn<TExpr, TCtx> 
    where TExpr : struct, IExpr, IConvertibleToDouble 
          TCtx : struct, ICalcContext
{
    private TExpr _arg;

    public SinFn(TExpr arg) {
        _arg = arg;
    }

    public DoubleValueExpr Invoke(in TCtx ctx) {
        return Math.Sin(_arg.Invoke(ctx).ToDouble());
    }
}

struct IntBinPlusOp<TExpr1, TExpr2, TCtx> 
    where TExpr1 : struct, IExpr, IConvertibleToInt 
          TExpr2 : struct, IExpr, IConvertibleToInt 
          TCtx : struct, ICalcContext
{
    TExpr1 _arg1;
    TExpr2 _arg2;
    ...    
    public IntValueExpr Invoke(in TCtx ctx) {
        return _arg1.Invoke(ctx).ToInt() + _arg2.Invoke(ctx).ToInt();
    }
}

и т.д.
(я когда-то сделал такой калькулятор на value-типах в середине нулевых, как вышли генерики, где-то валяется)

Через конкретную реализацию CalcContext передаются связанные переменные (внешние захваченные или аргументы из сигнатуры), к которым (переменным) в нужных местах происходит обращение.

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

Эффективность её интерпретирования в плюсах на порядок выше эффективности интерпретирования Expression<T> (до компиляции).

Соответственно, основное применение Boost.Proto — это compile-time генерация кода из некоего DSL (Boost.Proto, в отличие от Expression<T> позволяет переопределять дефолтную грамматику, доступные операторы, терминалы/нетерминалы, "ключевые слова" и т.д.).
В т.ч. можно в compile-time производить трансформацию AST, т.е. "компиллировать" свой DSL.

И напротив, связка linq/expression/queryable с подключаемыми провайдерами — чисто динамическая вещь.

Можно ли аналогичное сделать в С++, т.е., породить такое AST, которое возможно будет итерировать в рантайм не шаблонным кодом, а через систему интерфейсов (с целью динамической трансформации AST подключаемыми в рантайм провайдерами)? — можно. Библиотека Boost.Proto и разработана с целью расширять дефолтные типы узлов AST, обогащая их требуемыми признаками.

Почему не было сделано?
Предположу, что по той причине, что работа с БД давно уехала с клиента на сервер и даже на веб-сервер, где плюсы не в топе популярности.
Когда плюсы теряли популярность в вебе, средний пинг по планете был 50-100 ms, т.е. экономия единиц ms и даже единиц десятков ms ничего не давала.
К тому же, основные задержки по-прежнему в БД.


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

Как выяснилось, Синклер имел ввиду и вовсе AST-выражения, которые хотел передать удалёному ендпоинту, т.е. оно ближе к коду Бейсика, а не к низкоуровневому байт-коду. ))


НС>Если тебе хочется придумать собственную трактовку — ради бога

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


НС>но тогда все твои возражения теряют релевантность. И образуется именно та логическая каша, про которую я написал.

Э-э-э, я думал, ты в курсе, откуда ноги растут.
На пальцах, зачем некоторые горе-компиляторостроители используют байт-код:

Был у нас коллективный курсовик для всей группы на 3-м курсе, в рамках которого была разработана учебная ОС.
В состав ОС входило много чего плюс компилятор учебного советского языка (нц/кц, если помнишь) в байт-код стековой машинки.

Угадай с одного раза, зачем мы компиляли в байт-код?
Очевидно же — потому что мы были не способны за трудоёмкость курсовика (плюс небольшой свой опыт) компилять это всё в машинный код x86 со всеми его бесконечными спецификациями.
Это нетривиальная задача — порождать "ассемблерный код" реального нехилого проца.

Зато на языке высокого уровня (Си) написать интерпретатор своего упрощённого байт-кода — как два пальца об асфальт выделенной группе из 3-х студентов.
В итоге, ни на одном из этапов разработки мы не выходили на низкий уровень, кроме собственного уютного примитивного байт-кода.

Разумеется, в исходниках эта разработка была более-менее переносима на другие платформы, а значит байт-код получался автоматически переносимым.

Но это мы, студенты-третьекурсники.
А когда мне показывают, что похожий по технике Паскаль был разработан взрослыми инженерами... Реакция была как на кислый лимон.
Те тоже не стали пачкать ручки оптимизацией и низким уровнем, бгг.
Вы, ребят, даже не сообразили, на что даёте ссылки. ))

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>В интерпретаторе спектрумовского Бейсика всё аналогично.
НС>Нет, совсем нет. Там именно исходная программа, просто в закодированном виде. Если по современному, то просто поток токенов.

Как я и думал, собсно.
Для некоторых команд проца IBM/360 аргументы тоже представляют из себя эдакие токены.


НС>>>Непонятно. Что значит отделения и зачем он в этом топике?
V>>Это значит, что в практике IT редко встречается так, что язык диктует способ своей реализации.
НС>Но тот бейсик как раз демонстрирует обратное.

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


V>>Конечно, возможно.
V>>В первую очередь, возможно принципиально.
НС>То что это, по сравнению с expression tree так и не получило достойного применения как бы намекает, что вариант с перегрузкой операторов и шаблонами имеет существенные недостатки.

Вообще-то получило.
Интроспекция дерева выражений Boost.Proto может происходить не только в рантайм, но и в момент компиляции через диспетчеризацию на шаблонах, т.к. любое выражение полностью статически типизировано и представляет из себя "плоский" граф, построенный на value-type в терминах дотнета.

Например, выражение expr:

auto x= _1;
auto y = _2;
auto expr = sin(x*10 + y*20);

порождает (на пальцах если) примерно такую структуру:

sin_(plus_(mul_(arg_<0>, const_<10>()), mul_(arg_<1>, const_<20>)))

На шарпе это примерно так:

struct SinFn<TExpr, TCtx> 
    where TExpr : struct, IExpr, IConvertibleToDouble 
          TCtx : struct, ICalcContext
{
    private TExpr _arg;

    public SinFn(TExpr arg) {
        _arg = arg;
    }

    public DoubleValueExpr Invoke(in TCtx ctx) {
        return Math.Sin(_arg.Invoke(ctx).ToDouble());
    }
}

struct IntBinPlusOp<TExpr1, TExpr2, TCtx> 
    where TExpr1 : struct, IExpr, IConvertibleToInt 
          TExpr2 : struct, IExpr, IConvertibleToInt 
          TCtx : struct, ICalcContext
{
    TExpr1 _arg1;
    TExpr2 _arg2;
    ...    
    public IntValueExpr Invoke(in TCtx ctx) {
        return _arg1.Invoke(ctx).ToInt() + _arg2.Invoke(ctx).ToInt();
    }
}

и т.д.
(я когда-то сделал такой калькулятор на value-типах в середине нулевых, как вышли генерики, где-то валяется)

Через конкретную реализацию CalcContext передаются связанные переменные (внешние захваченные или аргументы из сигнатуры), к которым (переменным) в нужных местах происходит обращение.

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

Эффективность её интерпретирования в плюсах на порядок выше эффективности интерпретирования Expression<T> (до компиляции).

Соответственно, основное применение Boost.Proto — это compile-time генерация кода из некоего DSL (Boost.Proto, в отличие от Expression<T> позволяет переопределять дефолтную грамматику, доступные операторы, терминалы/нетерминалы, "ключевые слова" и т.д.).
В т.ч. можно в compile-time производить трансформацию AST, т.е. "компиллировать" свой DSL.

И напротив, связка linq/expression/queryable с подключаемыми провайдерами — чисто динамическая вещь.

Можно ли аналогичное сделать в С++, т.е., породить такое AST, которое возможно будет итерировать в рантайм не шаблонным кодом, а через систему интерфейсов (с целью динамической трансформации AST подключаемыми в рантайм провайдерами)? — можно. Библиотека Boost.Proto и разработана с целью расширять дефолтные типы узлов AST, обогащая их требуемыми признаками.

Почему не было сделано?
Предположу, что по той причине, что работа с БД давно уехала с клиента на сервер и даже на веб-сервер, где плюсы не в топе популярности.
Когда плюсы теряли популярность в вебе, средний пинг по планете был 50-100 ms, т.е. экономия единиц ms и даже единиц десятков ms ничего не давала.
К тому же, основные задержки по-прежнему в БД.


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

Как выяснилось, Синклер имел ввиду и вовсе AST-выражения, которые хотел передать удалёному ендпоинту, т.е. оно ближе к коду Бейсика, а не к низкоуровневому байт-коду. ))


НС>Если тебе хочется придумать собственную трактовку — ради бога

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


НС>но тогда все твои возражения теряют релевантность. И образуется именно та логическая каша, про которую я написал.

Э-э-э, я думал, ты в курсе, откуда ноги растут.
На пальцах, зачем некоторые горе-компиляторостроители используют байт-код:

Был у нас коллективный курсовик для всей группы на 3-м курсе, в рамках которого была разработана учебная ОС.
В состав ОС входило много чего плюс компилятор учебного советского языка (нц/кц, если помнишь) в байт-код стековой машинки.

Угадай с одного раза, зачем мы компиляли в байт-код?
Очевидно же — потому что мы были не способны за трудоёмкость курсовика (плюс небольшой свой опыт) компилять это всё в машинный код x86 со всеми его бесконечными спецификациями.
Это нетривиальная задача — порождать "ассемблерный код" реального нехилого проца.

Зато на языке высокого уровня (Си) написать интерпретатор своего упрощённого байт-кода — как два пальца об асфальт выделенной группе из 3-х студентов.
В итоге, ни на одном из этапов разработки мы не выходили на низкий уровень, кроме собственного уютного примитивного байт-кода.

Разумеется, в исходниках эта разработка была более-менее переносима на другие платформы, а значит байт-код получался автоматически переносимым.

Но это мы, студенты-третьекурсники.
А когда мне показывают, что похожий по технике Паскаль был разработан взрослыми инженерами... Реакция была как на кислый лимон.
Те тоже не стали пачкать ручки оптимизацией и низким уровнем, бгг.
Вы, ребят, даже не сообразили, на что даёте ссылки. ))