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

НС>>>>Там не совсем тот P-код. Там просто упакованноое в удобное для интерпретации представление AST было
V>>>Там коды "инструкций" Бейсика.
НС>>Там коды ключевых слов.
V>В ассемблере тоже "коды ключевых слов".

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

НС>>Все. На Р-код это похоже исключительно в силу того, что на Р-код похож сам исходник того бейсика.
V>Да пофик.

Нет, не пофик. Мы обсуждали идею прежде всего, а не особенности реализации. А идеи там не было.

V>>>Мой поинт был в отделении понятия "язык программирования", как совокупности ситнаксиса и семантики от способа реализации этой семантики на стадии исполнения кода
НС>>И при этом ты привел в пример спектрумовский бейсик в котором никакого отделения синтаксиса не было, был просто вынос стадии парсинга на этап сохранения строки в память.
V>Ну, дык, отличный пример отделения языка от реализации.

Непонятно. Что значит отделения и зачем он в этом топике?


НС>>Но вы тут опять с терминами устроили кашу, уж не знаю, случайно или намеренно. Р-код это непосредственно императивные инструкции и это отдельная песня.
V>Это ты озвучиваешь своё эвристическое понимание.
V>P-код — это то же, что и псевдокод. Всё.

Bytecode (also called portable code or p-code) is a form of instruction set designed for efficient execution by a software interpreter.
...
Since bytecode instructions are processed by software, they may be arbitrarily complex, but are nonetheless often akin to traditional hardware instructions: virtual stack machines are the most common, but virtual register machines have been built also.

https://en.wikipedia.org/wiki/Bytecode

С бла бла бла не по теме все как обычно.

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

V>>Если речь про структурное построение, а не про арифметические или логические вычисления,
S>Вы зря противопоставляете эти две концепции.

Э, нет, ты сказал что сказал — вполне однозначно.


S>Во всех трёх строчках происходит одно и то же — конструируется новое значение на основе старого, старое остаётся неизменным.

Это потому что ты косноязычный, не владеешь терминологией.
Пытаешься "объяснить на пальцах", в то время как для объяснения инвариантности природы термов (лямбд и переменных) необходимо пользоваться терминологией, например, из лямбда исчисления Чёрча.

Чтобы потом не бегать за людьми и не канючить "да я не это имел ввиду, да меня не так поняли!", а потом и вовсе обиженно "да вы просто сами ничего не понимаете!"


S>То, что первая и вторая строчка = "арифметические операции", а третья — "структурное построение", ещё менее важно, чем различия в синтаксисе между оператором + и вызовом метода.

Уфф...
Вот в голове у тебя крутится, прям вижу вращающиеся шестеренки... а сформулировать ты не в состоянии... испанский сплошной стыд...

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

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

Но стоит ввести иммутабельность, и тогда мы можем построить через две аналогичные ф-ии чтение и для ссылочных типов. Ву а ля!
(ввиду того что ID(a)=a сколь угодно транзитивно)

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

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

НС>В ассемблере — мнемоники. Ты, видимо, хотел написать машинный код.

Я написал как это видит "процессор". ))
Ты же тоже на системотехника учился, т.е. у тебя был курсовик разработки процессора с ограниченным набором инструкций (инструкции выдавались по вариантам).
По вариантам так же была реализация на микропрограмме из ПЗУ или железным автоматом.
Вот прямо в любой из этих реализаций код инструкции — это то, по чему именно твоя схема проводила диспетчеризацию.

Как изначально железячник в первой стадии своей карьеры, я в упор не вижу принципиальной разницы программной, микропрограммной или аппаратной диспетчеризации таких кодов в процессе исполнения закодированной программы. Это вид сбоку одного и того же, строгое отображение некоего автомата на различные техники (подробности) его реализации.


НС>Нет — там не просто коды. Там еще и определенный бинарный формат, абсолютные и относительные числовые смешения вместо меток

Блин, ну как и виды адресаций в ЦПУ.
Вот есть специальный регистр — указатель команд.
В интерпретаторе спектрумовского Бейсика всё аналогично.


НС>Нет, не пофик. Мы обсуждали идею прежде всего, а не особенности реализации. А идеи там не было.

По-моему, ты пытаешься всё упрощать, и по той лишь причине, что Бейсик "примитивный недоязык".
Да пофик, какой язык.
Машинка исполнения Бейсика — это автомат, разработанный в лучших традициях, как грится.


НС>Непонятно. Что значит отделения и зачем он в этом топике?

Это значит, что в практике IT редко встречается так, что язык диктует способ своей реализации.
Это было насчёт "возможно ли получение AST исходника в С++".
Конечно, возможно.
В первую очередь, возможно принципиально.
Во-вторую можно рассуждать, как это сделать, используя уже имеющие ср-ва.
Всё это я перечислял.


НС>>>Но вы тут опять с терминами устроили кашу, уж не знаю, случайно или намеренно. Р-код это непосредственно императивные инструкции и это отдельная песня.
V>>Это ты озвучиваешь своё эвристическое понимание.
V>>P-код — это то же, что и псевдокод. Всё.

НС>

НС>Bytecode (also called portable code or p-code)

НС>https://en.wikipedia.org/wiki/Bytecode

Термин байткод появился еще позже.
Да, это всё синонимы.

Я вижу, что ты пытаешься утверждать, что байт-код таковым является только для виртуальных машин очень низкого уровня. ))
Но этого ограничения в реальности не существует.
Тем более, что в те года существовали даже реальные системы команд очень высокого уровня, например IBM/360.
Там уровень многих инструкций повыше уровня инструкций мейнстримовых x64 или PowerPC.

Кароч, позволю себе назвать вот эти натягивания спекуляциями.

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

Но степень абстрагирования не навязывается, ес-но.

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

V>Блин, ну как и виды адресаций в ЦПУ.
V>Вот есть специальный регистр — указатель команд.
V>В интерпретаторе спектрумовского Бейсика всё аналогично.

Нет, совсем нет. Там именно исходная программа, просто в закодированном виде. Если по современному, то просто поток токенов.

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

Но тот бейсик как раз демонстрирует обратное.

V>Конечно, возможно.
V>В первую очередь, возможно принципиально.

То что это, по сравнению с expression tree так и не получило достойного применения как бы намекает, что вариант с перегрузкой операторов и шаблонами имеет существенные недостатки.

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

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

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

V>fist class citizen — это мем.
:wut:

V>Хотя бы расположение бит и их итерпретация.

Так и что в этом неизвестного?

V>Например, far указатель унутре составной, часть бить отвечает за сегмент, часть за смещение сегмента.
V>Простая конкатенация бит адреса не создаёт реальный адрес, поэтому сравнивать произвольные far адреса нельзя.
V>Можно сранивать адреса только из одного сегмента.
V>Или более строго — из одного выделенного по malloc блока.

Вот видишь, тебе это известно, тогда что неизветсно?

V>Ты привёл из вики, т.е. совершил напрасный труд. ))

V>И почему ты споришь со мной?
V>Там коллега сказал, что Expression<T> — это первоклассная сущность.
V>Ну вот и спроси у него, чем его Expression<T> первокласснее моих неких MyExpression<T>?

Ничем, это булево свойство.

V>Косвенность не волнует только в иммутабельных системах типов, а иначе волнует, конечно.

Не для определения «first-class citizen»

V>Это какая-то нестандартная Схема? ))

Стандартная R6RS.

V>Любые примитивы из стандарта, навроде let, могут быть реализованы как встроенные.

И что?

V>Показанная тобой реализация предназначена для динамического исполнения машинкой, ес-но.

что? Какое ещё динамическое исполнение, если фаза expand происходит до компиляци?

V>Поэтому, опять мимо.

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

Или хотя бы стандарт почитай:

Macro uses (see section 9.2) are expanded into core formsat the start of evaluation (before compilation or interpretation) by a syntax expander.

— http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-13.html#node_chap_10

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

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-х студентов.
В итоге, ни на одном из этапов разработки мы не выходили на низкий уровень, кроме собственного уютного примитивного байт-кода.

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

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