Всем доброго времени суток!Подскажите пожалуйста, какой минимальный набор функций (лексем?) должен включать в себя интерпретатор lisp, чтобы по средствам библиотек макросов и функций (в исходниках) он (интерпретатор) мог обеспечить функциональность равную стандартному common lisp?

Это должен быть компилятор :)

Почему именно так?
Я имею ввиду конструкции языка. Какие конструкции языка нельзя воссоздать с помощью других конструкций языка (например с помощью макросов)? Какой минимальный набор конструкций нужен для воссоздания всех стандартных конструкций?
Например
(cond
  (test-1 form*)
      .
      .
      .
  (test-N form*))
не является обязательной конструкцией, т.к. cond можно воссоздать с помощью макросредств на основе if.

Common Lisp это большой язык, и дело не только в языковых конструкциях. Простого ответа и короткого списка инструкций получить нельзя :) Да и зачем?

http://www.faqs.org/faqs/lisp-faq/part1/section-6.html

Неужели нет информации о том, что входит в ядро lisp, а что реализуется как макросы, всякие либы и т.д. и т.п.?
Просто у меня появилась идея написать маленький и быстрый интерпретатор минимального количества конструкций lisp'а, чтобы на нём написать компилятор lisp'а.
Особенность интерпретатора в том, что использованные хотя бы раз макросы и т.д. он компилирует в оверлеи и подгружает в оперативку когда нужно; получается, что любые "надстройки" не будут проигрывать по скорости стандартному минимуму.
Если в компиляторе реализовать несколько стандартных библиотек (для GUI, I/O, и др.) для разных ОС и несколько модулей кодогенеоации для разных аппаратных платформ, то в результате можно будет компилировать и кросскомпилировать любую прогу на lisp'е под любую ОС и аппаратную платформу вообще без изменения исходника проги. Причём на выходе будет маленький размер и высокая степень оптимизации кода.
Если всё вышеперечисленное никому не надо или/и не реально (в последнем сомневаюсь), то ответ на мой вопрос поможет мне хотя бы прикрутить специально заточенный интерпретатор lisp'а к ассемблеру в качестве макроязыка.

Большое спасибо,  andy128k! Хоть и на английском, но зато кратко.
P.S. Интересно, может ещё кто-нибудь что-нибудь посоветует...

Идея собственно в:> результате можно будет компилировать и кросскомпилировать любую прогу на lisp'е под любую ОС и аппаратную платформу вообще без изменения исходника проги. Причём на
> выходе будет маленький размер и высокая степень оптимизации кода.

> результате можно будет компилировать и кросскомпилировать любую прогу на lisp'е под любую ОС и 
> аппаратную платформу вообще без изменения исходника проги.

Я не пойму, о чем речь. SBCL (и не он один) компилирует исходный код в машинный для различных платформ. Может быть там нет функции make-image-for-target-platform, но наверное прежде всего потому, что не понятно как этим можно реально пользоваться и нет на неё нет спроса.
> Причём на  выходе будет маленький размер и высокая степень оптимизации кода.
Если речь о Common Lisp, то выбирет пожалуйста только одно :) Либо поясните, как собираетесь этого добиться, ведь множество учёных мужей за десятки лет к этому так и не пришли, SBCL быстр и обеспечивает высокую степень оптимизации кода, но маленьким его никак не назовёшь.

Есть способ компиляции, который позволяет сгенерировать быстрый и компактный код не зависимо от входного языка (в смысле прикрутить что угодно можно, главное чтобы приводилось к единому внутреннему представлению проги). Главный недостаток такого метода компиляции - он жутко медленный.
В чём суть:
1) Исходник преобразуется в промежуточное представление.
Здесь программа разбивается на блоки вида: данные из вне -> таблица -> вызов внешней функции (прерывания). Где "таблица" - таблица соответствующих значений передаваемых вызываемой функции в зависимости от входящих данных. "Данные из вне" - ни что иное как возвращаемые значения из вызванных ранее функций, прерываний или данные переданные ОС программе при запуске последней.
2) Поиск наиболее подходящего по скорости и размеру алгоритма реализации зависимостей каждого блока в отдельности.
3) Генерация машинного кода с учётом особенностей платформы (избежание ошибок кэша, правильное построение последовательностей машинных команд и т.д.).
4) Линкуем результат предыдущей операции в исполняемый файл (будь то хоть kernel.bin).
Как Вам идея?

>> Подскажите пожалуйста, какой минимальный набор функций (лексем?) должен включать в себя интерпретатор lisp

Если смотреть с точки зрения Lisp-1 без макросов, то это quote, atom, eq, cons, car, cdr, if плюс defun. Маккарти их и использвал в качестве лисп-ассамблера и писал eval такго вида. Но тут подразумевается только элементарный тип - списки. Можно в принципе построить алгебру чисел и строк на основе списков - числа как списки T и NIL, играющие роли 0 и 1 , а строки как списки тахих чисел вроде номеров символов :) Только по сложности (в смысле O), это совсем не корошо. Ну а в Lisp-2 нужно ещё добавить defvar, т.е. разделить пространство переменных и функций.
Как макросы реализовать на этой основе - честно говоря не представляю, ведь макросы это ещ

нифига не понял, но соглашусь с archimag в том, что кроссплатформенные оптимизирующие компиляторы CL уже есть, но совместить это с маленьким размером рантайма не получится

>make-image-for-target-platform, но наверное прежде всего потому, что не понятно как этим можно реально пользоваться и нет на неё нет спроса.
Скорее, сложность в реализации — но вот, например, в Lucid CL эффективная кросс-компиляция была реализована. В SBCL же проблема в "нечистоте" компилятора, который делает сайд-эффекты.

>1) Исходник преобразуется в промежуточное представление.
С этим однозначно согласен.
> Здесь программа разбивается на блоки вида: данные из вне -> таблица -> вызов внешней функции (прерывания). Где "таблица" - таблица соответствующих значений передаваемых вызываемой функции в зависимости от входящих данных. "Данные из вне" - ни что иное как возвращаемые значения из вызванных ранее функций, прерываний или данные переданные ОС программе при запуске последней.
Если честно, не понял, что имелось в виду.
Вообще, есть описания устройств различных компиляторов лиспа — Lucid, CMU CL.

вообще, штуки, которые нельзя никак реализовать в рамках CL это "специальные операторы"
http://www.lispworks.com/documentation/HyperSpec/Body/03_ababa.htm#clspecialops
хотя, конечно, на практике IO, например, тоже не реализуешь просто так.

>> Подскажите пожалуйста, какой минимальный набор функций (лексем?) должен включать в себя интерпретатор lisp

Если смотреть с точки зрения Lisp-1 без макросов, то это quote, atom, eq, cons, car, cdr, if плюс defun. Маккарти их и использвал в качестве лисп-ассамблера и писал eval такого вида. Но тут подразумевается только элементарный тип - списки. Можно в принципе построить алгебру чисел и строк на основе списков - числа как списки T и NIL, играющие роли 0 и 1 , а строки как списки тахих чисел вроде номеров символов :) Только по сложности (в смысле O) это совсем не хорошо. Ну а в Lisp-2 нужно ещё добавить defvar, т.е. разделить пространство переменных и функций.
Как макросы реализовать на этой основе - честно говоря не представляю, ведь макросы это ещё и синтаксис не укладывающийся в лисп синтаксис. Если делать синтаксис макросов в обычном стиле - запятая и собака как функции, тогда наверно можно сделать. Но, как видете, это опять не корошо :)
>> Если в "lisp на lisp-е", то именно так практически все реализации и делают :)
Да, особенно SBCL и CLisp в чём-то, определяют базу, а остальное наращивают на самом лиспе - полезно почитать, eval and friend и все дела :)

>> Есть способ компиляции
А можно пример для Лиспа, а то не совсем понятно как такой рефлективный язык можно разбить на "блоки".
Кстати, недавно тут про трансляцию лисп->си упоминалось, а как вам такая идея?

> Как Вам идея?
Я чем больше читал, тем меньше понимал, в чем идея.
1. Если вы хотите написать свою имплементацию лиспа с возможностью компиляции в машино-зависимый код, то возникает вопрос, а чем ваша реализация будет лучше и быстрее копиляции в других имплементациях лиспа, как бесплатных версий, так и коммерческий (lispworks, franz)? То есть а зачем, с какой целью хотите это делать?
2. Кросскомпиляция. Я понимаю ее как возможность скомпилировать в машинный код находясь на платформе А (операционная система, hardware, etc) под некоторую другую платформу B, которая отлична от А. Я могу ошибаться, поэтому поправьте меня если я не прав, но такое в Лиспе сделать, скажем так, трудно (невозможно?), так как одна из основополагающих концепций Лиспа это "Data As Program / Program As Data", то есть данные программы и сама программа неделимы, поэтому Лисп программы могут сами себя изменять/строить в процессе своего выполнения. То есть в процессе компиляции скомпилированные на начальном этапе функции могут вызываться на последующих этапах компиляции чтобы скомпилировать новый код, который в свою очередь так же может использоваться для построения программы. Поэтому, если что то находясь под платформой А было скомпилированное под платформу B и потом это что-то нужно вызвать, то как написанное/скомпилированное под B будет работать под А?
3. Если нужна возможность "написать один раз и запустить везде", то почти все текущие на данный момент имлементации Лиспа поддерживают это, так как охватывают множество платформ. В силу понятных причин (коммерческая поддержка) у LispWorks и Allegro CL с этим лучше всего (охват множества платформ).

> А можно пример для Лиспа, а то не совсем понятно как такой рефлективный язык можно разбить на "блоки".Можно в программе выделить "точки" соприкасания с системой (ввод/вывод полюбому будет либо через API, либо через прерывания, либо прямое чтение/запись в память). Потом полностью проинтерпретировать всю программу со всеми возможными вариантами входных данных (любые варианты возвращаемых системой значений) и записать в таблицу при каких входных значениях какие выходные получаем.
А т.к. полноценная программа с вводом и выводом данных последовательно вызывает функции ОС (программа=ядро пока не рассматриваем), то интерпретировать можно по отдельности тот кусок программы, который находится между двумя ближайшими вызовами внешних функций.


Надеюсь так более ясно?

> нифига не понял, но соглашусь с archimag в том, что кроссплатформенные оптимизирующие компиляторы CL уже есть, но совместить это с маленьким размером рантайма не> получится
RunTime в топку! Все в исходниках, где на самом низком уровне абстракции непосредственный вызов системных API.

> 1. Если вы хотите написать свою имплементацию лиспа с возможностью компиляции в машино-зависимый код, то возникает вопрос, а чем ваша реализация будет лучше и быстрее> копиляции в других имплементациях лиспа, как бесплатных версий, так и коммерческий (lispworks, franz)? То есть а зачем, с какой целью хотите это делать?
Дизассемблировав программу на ЯВ я не хочу видеть код, который я могу написать лучше, пусть компилятор будет умнее меня, на много умнее.


> 2. Кросскомпиляция. Я понимаю ее как возможность скомпилировать в машинный код находясь на платформе А (операционная система, hardware, etc) под некоторую другую платформу B, которая отлична от А. Я могу ошибаться, поэтому поправьте меня если я не прав, но такое в Лиспе сделать, скажем так, трудно (невозможно?), так как одна из основополагающих концепций Лиспа это "Data As Program / Program As Data", то есть данные программы и сама программа неделимы, поэтому Лисп программы могут сами себя изменять/строить в процессе своего выполнения. То есть в процессе компиляции скомпилированные на начальном этапе функции могут вызываться на последующих этапах компиляции чтобы скомпилировать новый код, который в свою очередь так же может использоваться для построения программы. Поэтому, если что то находясь под платформой А было скомпилированное под платформу B и потом это что-то нужно вызвать, то как написанное/скомпилированное под B будет работать под А?


Почему программа на ассемблере может в процессе работы сама себя переписывать, а на lisp'е нет? А если реализовать такую возможность, чтобы программа написанная на лиспе и скомпилированная в машинный, работающая без всякого RunTime, если ей нужно себя переписать переписывала себя прямо в машинных кодах? И для этого даже не нужно включать в программу целый компилятор с линкером на пару, достаточно полиморфного движка, причём для каждой проги разного.

to R1DDLE:
Подозреваю, что у вас какое-то очень неверное представление о лисп вообще, и о Common Lisp в частности :) Поэтому разговор идёт, по сути, на разных языка, ну или О разных языках.
> Дизассемблировав программу на ЯВ я не хочу видеть код, который я могу написать лучше,
> пусть компилятор будет умнее меня, на много умнее.
Ну, дык, в чём проблема, ставите SBCL, пишите функцию, смотрите сгенерированный машинный код, если что не так - пишите патч и отправляет разработчикам, зачем свою реализацию для этого делать то?
> Почему программа на ассемблере может в процессе работы сама себя переписывать, а на lisp'е нет?
Ну, вообще-то так и происходит, кто сказал, что не может?
> работающая без всякого RunTime
Как это? RunTime и C-ных программ есть, и у ассеблерных, как это без него? Только в случае с CL он должен включать в себя и, собственно, компилятор, и перемещающий сборщик мусора, плюс есть такие вещи, как динамическое связывание или там обработка условий. Много чего, поэтому он и большой.

Наработок у меня нет, т.к. хочу выяснить как можно больше ньюансов, чтобы решить в каком виде это делать.
Хорошо, рассмотрим пример.
> К примеру возьмём определение функции, возвращающей замыкание. Эффект от вызова такой функции будет определятся контекстом вызова. У нас есть входная цепочка в
> определённом синтаксисе, опуская токенизацию и прочее будем считать что она у нас уже в виде дерева.
Допустим, что функция получает число, а результатом её работы является строка. При чём известно ограничение на входное значение (например указано, что входное значение типа dword). Наш компилятор берёт эту функцию и интерпретирует для каждого входного значения от 0 до 65536, а получаемые на выходе строки записывает в виде ассоциативного списка, в котором строка полученная на выходе ассоциируется с числом заданным на входе.
Потом анализируя такой список можно подобрать подходящий под конкретную ситуацию алгоритм и сгенерировать адекватный код (ведь проанализировав программу вызывающую это функцию, можно прийти к выводу, что входными значениями могут быто только 0 и 65536 к примеру).

Все равно я вас не понимаю, вернее вопрос вот такой -- для чего вам это все? Для какой конкретно задачи? Какую задачу вы решали, что текущие имплементации Лиспа вас не устроили?
> И для этого даже не нужно включать в программу целый компилятор с линкером на пару, достаточнополиморфного движка, причём для каждой проги разного.
У меня ощущение, что вы мыслите "не-лисповским" мышлением. А движок в Лиспе самый универсальный и очень простой -- это EVAL, описанный в 1958 году by John McCarthy. :)

> У меня ощущение, что вы мыслите "не-лисповским" мышлениемВы правы! Так и есть. Я мыслю в командах процессора. И я хочу не только высокоуровневый гибкий и универсальный язык, но и качество выходного кода.
Мне нужен компилятор, который сможет распознать, когда я пишу MyWindow0.Show() я хочу чтобы он сгенерировал
push hMyWindow
call [ShowWindow]
а не пару килобайт кода, где 20 функций вызывают друг друга пока не дойдут до выше указанных 2-х машинных команд...
P.S. Как хотелось бы объеденить высокое качество кода (компактность при максимальном быстродействии) со скоростью и удобством разработки.

MyWindow0.Show() это не по лисповски, нужно как-то (call-method 'show 'my-window) :) шучу.
Я имел в виду совсем другой пример, в общих словах - очень высокоуровневой абстракции, которую трудно выразить на языке машинных команд. В этом всё и дело - то о чём вы говорите, то есть транслятор который найдет коду на лиспе лучшее (причем нетривиальное) соответствие на языке низкого уровня это основной камень преткновения, что-то вроде ИИ в трансляции...
Ещё про перебор всех возможных значений значений аргумента для получения таблицы всех возможных значений функции - это только для квантового компьютера разве что :)

> когда я пишу MyWindow0.Show() я хочу чтобы он сгенерировал
А при чём тут, собственно, лисп? В такой вид вызов в CL точно никогда транслироваться не будет.
> а не пару килобайт кода, где 20 функций вызывают друг друга
> пока не дойдут до выше указанных 2-х машинных команд...

Вы реальный машинный код, который генерит тот же SBCL смотрели или нет? Может уже давно всё придумали и сделали, а?

>Вы реальный машинный код, который генерит тот же SBCL смотрели или нет?
+++

Я тоже не понимаю, причем тут Лисп, и Common Lisp в частности? Если относительно программирования вы мыслите в командах процессора, то пишите на ассемблере, если вам так удобнее и продуктивнее.
В чем проблема вообще? И можно примеры программы на Лиспе, которую вы писали и после откомпилировали, где вам не понравилось то, как компилятор сгенирировал машинный код?

Ну не я писал, что для GUI'шного Hello world на лиспе нужен в лучшем случае почти метр. Так пишут на многих форумах и статьях по всему инету. Если уже есть, нечто очень приближённое к тому, о чём пишу я, то пожалуйста дайте ссылочку. :)И проблема собственно в том, что я на ассемблере могу хорошо оптимизировать тривиальные вещи. для не тривиальных есть оптимизирующие ЯВП. но сейчас упор делается на скорость разработки, скорость компиляции и сборки проекта, а не на скорость его выполнения. Все знают, что это выгодно железоклепателям, но мне не нравится...

С лиспом на практике ещё не сталкивался. "Для разминки мозга" попрактикуюсь однозначно. Но в своих проекта применять не буду, если он не впишется в мои, пусть и идеализированные, представления.

> Ну не я писал, что для GUI'шного Hello world на лиспе нужен в лучшем случае почти метр.
> Так пишут на многих форумах и статьях по всему инету.

Я не знаю, откуда взялся метр. Для sbcl сам факт его запуска требует от 30 метров. Дело в том, что CL это не Си, для которого компилятор отдельно, а программа отдельно. Любая программа на CL, включает в себя и компилятор. В CL вообще такого понятия как программа нет :) (я не шучу) Лиспу всегда нехватало ресурсов ибо нагружали его сложными задами, и его оптизировали, долго и нудно, но оптимизировали скорость выполнения. И нельзя получить все преимущества лисп не заплатив за это определённую цену, так просто не бывает...

archimag, большое спасибо за краткое и ясное разъяснение! Теперь до меня многое дошло (кто-то сейчас подумал "наконец-то" :) ).
Вот он, главный косяк языка. Теперь я понимаю, почему многие стараются идеи lisp'а внедрить в другие языки, а не сам lisp куда-то внедрить. Но всё же пока критичным параметром будет время компиляции так всё и останется.
Всем большое спасибо! Надеюсь из этой темы полезное для себя вынес не только я :)

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

:)

Я понимаю, что вы тут все асы, а я хрен с бугра, но я ведь и не утверждал, что я разбираюсь в лиспе. Я просто выяснил то, что хотел и всё :)

> Вот он, главный косяк языка.
Нет, это главная его сила :)
> Но всё же пока критичным параметром будет время компиляции так всё и останется.
Вам определённо надо с ним порадоботать, а то будете распространять неверные представления, ну какое ещё время компиляци? По скорости работы, при всех своих наворотах, современные реализации могут вполне тягаться с скомпилированным C++.
> Теперь я понимаю, почему многие стараются идеи lisp'а внедрить в другие языки, а не сам lisp куда-то внедрить
Опять неверно :)

lisp, на мой взгляд, самый перспективный и гибкий язык. Просто читая pcl, я нашёл всё, чего так не хватало в других ЯВУ. Но те принципы компиляции программ, которые используются сейчас (естественно я не знаю обо всём, что сейчас используется) уже устарели. Они остаются актуальными лишь из-за экономической выгоды для тех, кто правит балом (производители железа и средств быстрой разработки).Я не собираюсь распространять какое-либо мнение о лиспе, пока не познаю его.
archimag, объясните пожалуйста мне, почему технологии лиспа заимствуют в другие языки, а сам язык не используется так активно как C++. Хотя что С++, что лисп не самые простые для изучения языки (вывод сделан в сравнении объёма в страницах спецификаций обоих языков).

> Но всё же пока критичным параметром будет время компиляции так всё и останется.
В Лиспе как раз нет проблем со временем компиляции, хотя сравнивать то, что понимается под компиляцией в Лисп имплеметнациях и в мире C/C++ не совсем правильно. Так же нет проблем c компиляцей в Smalltalk, Forth. Все это, включая Лисп -- "другие миры".
Кстати, вам с вашей любовью к низкоуровневому программирования стоит, я думаю, обратить взор на Forth и идеи его создателья Chuck Moore.  Но Forth так же "выносит" мозг. Так же, хорошая книга по Forth есть тут http://thinking-forth.sourceforge.net/
А не используют массово Лисп по другим причинам и эти причины больше связанны с бизнесс-процессами массовой разработки софта и технологиями подхода к разработке.

Спасибо за совет, на forth я как-то и не обращал внимания.

SP-Forth http://spf.sourceforge.net/  (российская разработка, очень и очень хороша, я бы сказал одна из лучших на данный момент под windows)
Русское комьюнити http://www.forth.org.ru/ 

> Теперь я понимаю, почему многие стараются идеи lisp'а внедрить в другие языки, а не сам lisp куда-то внедрить
>> Опять неверно :)
Кто-то говорил - "В каждом языке программирования есть маленький интерпретатор лиспа", это кстати правда :)
Насчёт exe - можно писать сырые байты в файл, это и будет исполнимый файл, например на вин. минимальная программа - 2 байта. Потом определить свой ассемблер как функции записи байтов, и обвернуть всё в COFF (или PЕ) формат - написать макрос. В рамках такого языка, который вы сами создали для своей задачи, упомянутый gui hello-world будет настолько минимален, насколько возможно. Это конечно не компиляция, но ассамблер в лиспе.
Другой подход - смотреть на лисп-программы как на скрипты (сообщения), которые посылаются лисп-серверу на выполнение. Т.е. .lisp и .fasl файлы - родные для _лисп_-среды, в то время как executable - родные для ОС. Есть некая линия водораздела и не требуется переводить что-то из одной сферы в другую, за исключением специальных случаев - желания сохранить образ лисп-среды, или вызова функций из dll.

> Насчёт exe - можно писать сырые байты в файл, это и будет исполнимый файл, например на вин. минимальная программа - 2 байта. Потом определить свой ассемблер как функции записи байтов, и обвернуть всё в COFF (или PЕ) формат - написать макрос. В рамках такого языка, который вы сами создали для своей задачи, упомянутый gui hello-world будет настолько минимален, насколько возможно. Это конечно не компиляция, но ассамблер в лиспе.
Вот на счёт этого я и говорю. И так же с помощью макросов можно поднять уровень абстракции к прмеру с "ассемблера в лиспе" до "Pascal (C++, х.з., ...) в лиспе" и т.д. до "Лисп в лиспе" :)
P.S. Трудно представить насколько это будет тормознуто, но интересно попробовать.

> Допустим, что функция получает число, а результатом её работы является строка. При чём известно ограничение на входное значение
> (например указано, что входное значение типа dword). Наш компилятор берёт эту функцию и интерпретирует для каждого входного
> значения от 0 до 65536, а получаемые на выходе строки записывает в виде ассоциативного списка, в котором строка полученная на
> выходе ассоциируется с числом заданным на входе.
> Потом анализируя такой список можно подобрать подходящий под конкретную ситуацию алгоритм и сгенерировать адекватный код
> (ведь проанализировав программу вызывающую это функцию, можно прийти к выводу, что входными значениями могут быто только
> 0 и 65536 к примеру).
Методика просто жесть. У меня есть подозрения, что такая оптимизация даже в сишных программах применима где-то в 1% случаев.

Это может работать как способ перехода их сферы-лиспа в сферу-ос, выражаясь таким спецфичным языком.
1. Это нужно писать на лиспе, возможно с добавлением функционала на си в виде dll. Функционал обычный, так что никакой тормознутости не должно быть.
2. Как результат - генерация си/pascal/asm которые тоже совсем не тормознутые.
З.Ы. кстати такие проекты уже есть если что :) но я не пробовал, ничего сказать не могу - только собственные игрушечные упражнения.

>> Это может работать как способ перехода их сферы-лиспа в сферу-ос
Это я про своё сообщение а не про "методику" :) которой нужна сложность ч.з.с. О

> Методика просто жесть. У меня есть подозрения, что такая оптимизация даже в сишных программах применима где-то в 1% случаев.
Если бы такая оптимизация повсеместно проводилась в прогах на C++ (Delphi, etc) в масштабе программы (а не функции как в примере), то в результате получался бы код такого же качества как на чистом С + API без RunTime. Естественно для этого в проект должны включаться не либы, а исходники либ и исходники RunTime библиотек.

>> Если бы такая оптимизация повсеместно проводилась в прогах на C++ (Delphi, etc) в масштабе программы (а не функции как в примере), то в результате получался бы код такого же качества как на чистом С + API без RunTime. Естественно для этого в проект должны включаться не либы, а исходники либ и исходники RunTime библиотек.
На чём основано такое утверждение? Расчеты, тесты, мистическое ясновидение?

> На чём основано такое утверждение? Расчеты, тесты, мистическое ясновидение?

Если бы Леонардо всё тестил, что ему приходило в голову, то мы бы о нём не узнали вообще...

Вообще, если представить предложенное мной преобразование в голове, то результат очевиден.