проект "полёт валькирии"

2 Edmond, ну почему же лишнего?=) очень даже не лишнего!=)))

Ценные весчи, которые я обязательно использую при проектировании компилятора!

 

eXod

Отсутствие как такового синтаксиса - это очень хорошо, я тоже сейчас пишу язык и вижу это как одно из преимуществ.

Скорость иполнения сейчас, это не основное, как мне это не по душе! Современные процессоры слишком быстро набирают скорость и это было одной из причин из-за чего появились скрипты, интерпритаторы, ЯВУ, суперкомпиляторы и т.д. И поэтому это преимущество не особо большое по сравнению с временными затратами на создание описанного тобой, а они колосальны! Сколько библиотек, драйверов устройств и т.п..

Язык должен давать быструю разработку.

Компилируемые скрипты - это вещь, но слишком много библиотек нужно написать, чтобы они стали непосредственным преимуществом.

 

2 Avalonec, из современного оборудования ещё очень много не выжато, так что компилируемые языки ещё не отжыли своё!=)

Теперь немного слов о языке(URAN вот такое название в голову пришло=) ).

Немного про этап компляции. Ну собственно технология "свободный синтаксис"... есть два варианта реализации, за счёт конфиг файлов и за счёт нейронных сетей(НС). Почему мне больше нравица второй? собственно первый этап компиляции представляет собой исчисление предикатов. А именно с этим НС очень давно начали хорошо справлятся!=)Зачем тогда плодить конфиг файлы, если НС сама будет разбирать синтаксис. А с возможностями обобщения и предсказания(а так же функций памяти) у НС мы получаем мошный механихм компиляции! и приходим ко второй основной технологии - "Интеллектуальная Оптимизация". С этого места чуть по подробнее...

Первый этап. Специально обученная НС делает первый проход. собственно компилирует(исчисляет предикаты) в промежуточное представление.(кстати, оно известно только НС и для нас не несёт никакого смысла). На этом этапе возможны исправления большинства синтаксических и некоторых пренципиальных ошибок. Далее код, откомпилированный во внутреннее представление, передаётся второй НС, которая уже обучена производить жёсткую оптимизацию и выдавать всё в опкодах!=) На этом этапе производится принципиальная оптимизация.(ну например разворачивание некоторых циклов, замена call на jmp, там где это возможно и т.п.). Итак мы получили уже откомпилированный и оптимизырованный код. Третьий этап. низкоуровневая оптимизация. Выполняется генетическими алгоритмами.(они как раз для подобного рода задач и созданы(задач оптимизации)).

Плюсы такой схемы работы - исправление многих ошибок(начиная от пропущенной ";" и кончая ошибками в написании самих алгоритмов), мощная интеллектуальная оптимизация на всех уровнях. А при использовании скриптофилософии получаем просто незабываемую весч!=) Естественно НС многомодульны, чтоб их каждый раз не переобучать при введении новых инструкций в процессор. И для каждой платформы можно сделать отдельную НС которая и будет заниматься компиляцией(именно по этому там их и две работает - одна не привязана к платформе, а вторая как бы является драйвером). Ваше мнение, господа?

 

eXod

есть два варианта реализации, ...и за счёт нейронных сетей(НС)

хех, сильно ты загнул

любой, кто пытался научить нейросеть на более сложное, чем отличать белое от черного меня поймет

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

строго формализованная грамматика языка к таковым не относится.



к тому же,рассчет выхода нейрона - это вычисление с плав. точкой, что уже не есть быстро.



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

выбор всех этих параметров уже сам по себе является шаманством, так что я не советовал бы тебе лезть в эту область...

 

2 MAX, уже не первый год лазю в эту область и пока ничего... а какраз для формального языка, который очень схож с исчисление предикатов(по сути компиляция - это и есть исч. пред.) и НС с обратными связями во всю как раз для этого и пользуют!=)

А вот насчёт скорости компиляции я согласен не быстро... но ведь лучше один раз небыстро откомпилировать, чем потом много раз выполнять небыстрый код!=)

_________

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

 

Вопрос следующего плана eXod : если реализация компилятора с НС все таки возможна и будет реализуема то как тогда будут поставляться софт для пользователей? В исходных кодах(тогда процес инсталяции будет заключатся в компилировании и потом уже в самой установке), или програмы будут поставлятся в промежуточных состояниях? Я несведущий в НС но наверное эти самые НС при обработке исходника будут вносить некоторую избыточность(для собственных нужд) в промежуточный исходник.

Это я о размерах. Ну а если поставлять уже "экзешник" то тогда нужно ведь заботится о всех его клонах для всех платформ.

Ну незнаю интелектуальная оптимизация это конечно прорыв

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

 

eXod

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



Разбор синтаксиса - это не столь СЛОЖНОЕ занятие, чтобы ПАРУЧАТь его НЕЙРОННЫМ СЕТЯМ!!!



Этап парсинга - это самый лёгкий этап.



А вот на оптимизацию НС - хочеться посмотреть )

Не видел, не видел...



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



Боюсь вы очень плохо понимаете, что говорите.

)

У вас ничего не выйдет. Генетические алгоритмы не способны взять в разработку современную схему CPU - они обладают СЛИШКОМ большим множеством случаев.



Ваш компилятор в лучшем случае скомпилирует программу через 200 млн лет



А в хужшем - никогда.



Тема X синтаксиса - относится не к сложнейшим, а просто к тем, для решения которых требуется НОВЫЙ ПОДХОД, который в современном программировании начисто отсутствует.



И НС - тут кажется слабым решением.



Ищите другое

 

2 Xandr, собственно я изначально предполагал, что программы будут распостранятся в исходниках!=) хотя многим это и не понравиться...(тогда подойдёт распостранение именно промежуточного кода, которые ещё не привязан к платформе, а размер там не намного больше будет(если вообще не меньше)).

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

По поводу геналг. Именно по этому их и надо ограничить!=) вот тут я не говорил, что будет один обобщённый алгоритм, тут для каждой платформы своя модификация...=) текст программы(опкоды/асм) разбивается на блоки(!, а то действительо лет двести...) и эти блоки уже проходят оптимизацию...

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

 

А не пора ли решить проблему "спора о синтаксисе" кардинально? Avalonec уже предложил здесь идею языка без синтаксиса (интересно, что под этим имелось ввиду; "язык должен давать быструю разработку" - это намек на RAD?) - и я с идеей убить синтаксис полностью согласен. В общем, идея такая: программы нужно не писать, а рисовать. CASE-средствами и может быть даже в многомерном пространстве (2-3 традиционных измерения+возможность уйти "вглубь" любого программного модуля). На халяву получим два бонуса: такой подход поощряет идеологически правильное высокоструктурированное и модульное программирование и, кроме того, можно превратить программирование в форму изобразительного искусства

 

Нечто подобное уже есть, причём даже наше российское. Это конечно скорее продвинутый планировшик задач,но возможности у него... большие!=) ссылку не помню=(

Но всё же мне не очень нравица идея отказа от синтаксиса и полный переход на "графические" разработки. Ибо программирование сравнимо с написанием стихов/книг. И самые талантлевые программисты как раз с гуманитарным образованием!=) Да, как бы это странно не звучало, но так оно и есть=)

 

И самые талантлевые программисты как раз с гуманитарным образованием!=)



Да Это обо мне Я такой ))

 

CyberManiac



Идея языка без синтаксиса была предложена в некотором ЯВУ [хех, а хто его помнит, но было такое - точно].



Оснавная идея, которую я предлагал когда-то в XASM (UASM) - микроскриптинг.



В случае UASM (3-версия архитектуры) - речь уже не шла о компиляторе.

Это была сложная система - которая обладала возможность программироваться при помощи специальных скриптов.



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



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



Это значит - что программы сами по себе могли быть хоть нарисованные хоть написанные в тексте.



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



Предпологается, что UASM устроен так, что на нём можно описать некий скрипт, который каки-то образом способен обрбатывать поток. И при этом - скрипт (совокупнсть ключевых слов или чего-ещё) не обязан быть полным. Скрипт например мог бы состоять только из ОДНОЙ конструкции IF.

Другой скрипт - занимался бы типизацией данных, а третий скрипт - циклами.



Таким образом исходный текст программы представлял собой безумную смесь РАЗЛИЧНЫх скриптов, которые взаимодействовали с друг другом через потоки данных (которые стандартизованы для UASM).



Эта идея действительно является передовой. Уверен, что её воплатят в жизнь если не сегодня, то лет через 10.



Доказательство этому - этот топик.



Первая статья о XASM появилась около 5 лет назад на сайте wasm.zite.ru ^))



Теперь уже через 5 лет - подобная идея появилась в голове ещё одного человека. Что означает - что идея безусловно верная

 

eXod

Совершенно не верно!

Хотя среди физиков - есть хохма, что лучшие поеты - это физики.



Некоторые люди - понимают смысл этой хохмы )



А потом...

Смотря что под программистом понимать.



Есть



1. Кодеры

2. Алгоритмисты

3. Эксперты и Аналитики



А вот Архитекторы - никогда не принадлежали к чему либо конкретно.



Ни капли не сомневаюсь - засадите меня за ту же химию, дайте проблему....

и мы будем искать выход.





Например:

идея XASM обязана своему появлению отнюдь не ассемблеру - а изучению аеродинамических процессов, и полуночным рассуждениям о распределении информации.



)))))))))



и не было никакого тут программирования

 

Да програмирование в 3D это круто! Если кто смотрел фильм "Операция рыба-меч" так там чувак трояна лепил примерно в такой же среде . Да, но не надо забывать

что все эти выкрутасы с НС и граф девелопменгом в конечном

итоге должны быть понятны как самому програмеру так и другим, которые будут разбиратся в его исходниках. Ведь всем известно что очень важно знать как компилятор згенерил код, как преобразовал адреса, вызовы, и т.д. А с этими наворотами с НС и 3D я боюсь что будт сложновато даже самому создателю предугадать что же компилер там натворил . Так что ребята, код должен быть прежде всего

понятным, а уж потом быстрым и гибким... иначе все эти навороты сведут КПД к нулю .

 

eXod:

>Нечто подобное уже есть, причём даже наше российское. Это конечно скорее продвинутый планировшик задач,но возможности у него... большие!=) ссылку не помню=(



Я видел другое: средство разработки, которое представляло функции WinAPI в виде компонентов, которые можно было соединять связями, указывающими откуда и куда передаются данные. Эта штука генерила исходник на Delphi, но т.к. модульность там не предусматривалась и документации не было почти никакой, написать что-то достаточно сложное было очень затруднительно.



>Но всё же мне не очень нравица идея отказа от синтаксиса и полный переход на "графические" разработки. Ибо программирование сравнимо с написанием стихов/книг.



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



Xandr:



>что все эти выкрутасы с НС и граф девелопменгом в конечном

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



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

 

2 Xandr, по поводу понятности кода - я тут согласен с CyberManiac. Конечный исходник(т.е. опкоды) нужно знать по большей части только для дизасемблирования(читай "взлома") =) программ. Ну ещё с тормозами и глюками... но это скорее будет ошибка в компилируемом исходнике.



2 CyberiaManiac, хм... мда, пожалуй ничего против такого программирования я не имею. Мне кажется, что надо предоставить каждому человеку то средство, которым ему будет удобнее пользоваться. Например тебе удобнее кодить в графическолм варианте, а я вот замучусь... мне удобнее "обычным" языком. Так что, даешь выбор!!! =))

 

Рябята, а можно вопрос так сказать локальный и по существу



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

 

кхм, кхм...

я задумываю написать две версии компилятора...

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

 

А что XWindows уже не подходит?

 

Edmond ну так я это и имел в виду )