Здравствуйте, Sinclair, Вы писали:
S>Какое совпадение! Моя сестра тоже живёт в Новосибирске. Есть у нас что-то общее.
Есть.

S>Именно это я и имел в виду. Возможно, встраивание событий прямо в язык может дать какие-нибудь преимущества, но надо сначала понять, какие недостатки есть в использовании библиотеки.
Из недостатков только то, что это только одна из идей.

S>Зря вы пишете такие ответы. Приведите пример. Тот, что приходит мне в голову телепатически, работать не будет — из-за очевидных конфликтов.
Конфликтов в опознании или в операциях?
В опознании не будет, потому что при лексическом анализе выбирается правило дающее максимально длинную лексему. А операции надо определить и с действительными числами.
B>>А возможные конфликты обнаруживаются анализом формул грамматики.
S>А это уже работает? Или пока только в теории? Потому что я вот сходу не могу сказать, возможен ли такой анализ вообще.
Возможен. Этот алгоритм придуман (кстати, новый), но сейчас работает другой. В двух словах, по по всем правилам создающих лексемы (у меня это отдельный класс, а не нетерминалы), проверяется какой знак может порождать какую лексему и индекс лексемы которую может породить этот знак сохраняется в таблице этого знака.
Теперь встретив знак, мы начинаем следующий знак проверять на принадлежность только лексемам из этой таблицы. И так для каждого знака, пока останется одно правило и не конец лексемы. Конец лексемы, тогда когда встречается знак который не удовляетворяет одному или сразу всем оставшимся правилам. Алгоритм линейный.
Конфликт возможен когда с концом лексемы остается не одно правило. У меня этот вариант допускается.
Выходы из конфликта.
1. Есть реализация лексемы (не знаю дочитал ты до реализации или нет, но она во введении есть). Там можно определить лексему вручную.
2. Выделение конфликта красным цветом. После чего опять вручную определить лексему.
3. На синтаксический разбор запускается сразу несколько вариантов лексем. И уже выбор делается в синтаксическом разборе. Если там выбор не сделан, то опять красный цвет и вручную уточняем лексему.

Выяснить наличие конфликта можно и сразу. Если так поставить задачу.

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

V>А все давно уже предложено и обсуждено. В языках со строгой статической типизацией вызов несуществующего метода не компилируется. Если язык с динамической типизацией — ошибка будет в рантайме. Преимущества и того и другого подхода давно обсуждены многократно, поищи на этом сайте.
А ты удачно все объяснил. Нет смысла искать.

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

V>>Инструкции виртуальной машины выполняет, очевидно, виртуальная машина. И эти инструкции могут представлять из себя что угодно, хоть объекты, хоть списки Лиспа, хоть слова Форта.

К>Выше были "инструкции, которые сами себя выполняют", учитываем твоё утверждение выше, получается виртуальная машиная является инструкцией, так? И интерпретатор форта также является его инструкцией, так?

Задача интерпретатора Форта — это запускать на исполнение "инструкции", то бишь исполняемые слова в терминологии Форта.


V>>Если он пишет транслятор/VM на VB, то в его распоряжении есть только объекты, так что ничего удивительного. "Я его слепила из того что было..."

К>Да пусть хоть пирожки, только пирожки сами себя выполнять врядли смогут, на мой взгляд, или всё-таки есть способ?

Ну да, VM запускает инструкции на выполнение. Разумеется, его "инструкции" должны как-то получать управление. А я думаю, тут все прозрачно было объяснено. Исполняемый код представляет из себя массив объектов, а не кодов. И вот поочередно этим объектам передается управление. Что тут сложного, и в чем принципиальное отличие от Форта/Лиспа?

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

V>Здравствуйте, Курилка, Вы писали:

V>>>Инструкции виртуальной машины выполняет, очевидно, виртуальная машина. И эти инструкции могут представлять из себя что угодно, хоть объекты, хоть списки Лиспа, хоть слова Форта.

К>>Выше были "инструкции, которые сами себя выполняют", учитываем твоё утверждение выше, получается виртуальная машиная является инструкцией, так? И интерпретатор форта также является его инструкцией, так?

V>Задача интерпретатора Форта — это запускать на исполнение "инструкции", то бишь исполняемые слова в терминологии Форта.


V>>>Если он пишет транслятор/VM на VB, то в его распоряжении есть только объекты, так что ничего удивительного. "Я его слепила из того что было..."

К>>Да пусть хоть пирожки, только пирожки сами себя выполнять врядли смогут, на мой взгляд, или всё-таки есть способ?

V>Ну да, VM запускает инструкции на выполнение. Разумеется, его "инструкции" должны как-то получать управление. А я думаю, тут все прозрачно было объяснено. Исполняемый код представляет из себя массив объектов, а не кодов. И вот поочередно этим объектам передается управление. Что тут сложного, и в чем принципиальное отличие от Форта/Лиспа?

Думается он думает по-естественому, а здесь пытаются сразу притянуть к архитектуре.
Убивая все то что может получится непохожее на другие языки. Так вот Лисп был придуман тогда, когда мозг математика еще не был загажен архитектурой определенного вычислительного корча. Если мыслить узко спускаясь к таким "драйверным" штукам как процессор, память, тип переменной, то выйдет еще один никому ненужный язык, потому что таких уже напридумывали и нариализовывали тысячи.

Если мыслить более широко, то любое поведенье всеравно можно замоделировать на машине тьюринга, даже такое когда все комманды "обьекты" и умеют выполнять себя самостоятельно, выполняются параллельно и процессор здесь для философского поиска вовсе неинтересен.

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

V>Ну да, VM запускает инструкции на выполнение. Разумеется, его "инструкции" должны как-то получать управление. А я думаю, тут все прозрачно было объяснено. Исполняемый код представляет из себя массив объектов, а не кодов. И вот поочередно этим объектам передается управление. Что тут сложного, и в чем принципиальное отличие от Форта/Лиспа?

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

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

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

V>>Ну да, VM запускает инструкции на выполнение. Разумеется, его "инструкции" должны как-то получать управление. А я думаю, тут все прозрачно было объяснено. Исполняемый код представляет из себя массив объектов, а не кодов. И вот поочередно этим объектам передается управление. Что тут сложного, и в чем принципиальное отличие от Форта/Лиспа?

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

Все дело в уровнях абстракций. Машина Тьюринга ничего не знает о паралельно работающих процессах например, которые как бы "думают" что тоже сами по себе и живут в отдельном адресном пространстве ...

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

Ситуация следующая. Мы выяснили что инструкции и значения не объекты. Я их объединил под общим названием потому что они формируются по общим правилам, и единому формату. Теперь возник вопрос как теперь мне все это называть? Объявляется конкурс. Жду предложений..

B>Ситуация следующая. Мы выяснили что инструкции и значения не объекты. Я их объединил под общим названием потому что они формируются по общим правилам, и единому формату. Теперь возник вопрос как теперь мне все это называть? Объявляется конкурс. Жду предложений..

Можно называть (сюрприз!) "инструкции" и "значения". Чем меньше своих слов придумано — тем лучше.

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

PC_>Здравствуйте, Курилка, Вы писали:

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

V>>>Ну да, VM запускает инструкции на выполнение. Разумеется, его "инструкции" должны как-то получать управление. А я думаю, тут все прозрачно было объяснено. Исполняемый код представляет из себя массив объектов, а не кодов. И вот поочередно этим объектам передается управление. Что тут сложного, и в чем принципиальное отличие от Форта/Лиспа?

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

PC_>Все дело в уровнях абстракций. Машина Тьюринга ничего не знает о паралельно работающих процессах например, которые как бы "думают" что тоже сами по себе и живут в отдельном адресном пространстве ...

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

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

К>Пускай себе не знает, только при чём тут уровни абстракции? По-моему дело в элементарной логике. Нарисованный на доске интеграл сам себя не возьмёт, несмотря ни на какие уровни абстракций.

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

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

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

PC_>Здравствуйте, Курилка, Вы писали:

К>>Пускай себе не знает, только при чём тут уровни абстракции? По-моему дело в элементарной логике. Нарисованный на доске интеграл сам себя не возьмёт, несмотря ни на какие уровни абстракций.

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

PC_>Хотя если Вы решили завести разговор про ассемблер и все такое то давайте выкинем например понятие итерация. И будем упорно утверждать что процессор ничего не знает о каких-то там циклах, ведь он всего лишь прыгает по меткам.

Очень показательно — придумать утверждение за оппонента и опровергать его, тем более когда оно никаким боком не относится к обсуждаемому. Такая дискуссия неинтересна, ведите её с batu.

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

B>>Ситуация следующая. Мы выяснили что инструкции и значения не объекты. Я их объединил под общим названием потому что они формируются по общим правилам, и единому формату. Теперь возник вопрос как теперь мне все это называть? Объявляется конкурс. Жду предложений..

T>Можно называть (сюрприз!) "инструкции" и "значения". Чем меньше своих слов придумано — тем лучше.
Так скажи как обозвать все вместе объекты, значения и инструкции.

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


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

Откуда такая непроходимость? Вот есть язык Лисп, который я упомянул уже многократно. Ты примерно представляешь, как работает программа, написанная на этом языке? Фактически — точно так же. Программа после "проглатывания" интерпретатором представляет из себя списки списков объектов. Те объекты, которые имеют тип "функция", имеют метод вроде такого (варианты на managed-языках):

public override LispObject eval(Cons args, Cons context);

Встроенные ф-ии, т.е. реализованные разработчиком, переопределяют этот метод и что-то делают, согласно спецификации. А вот все пользовательские ф-ии представляют из себя экземпляры объекта одного и того же типа, который, при получении управления, т.е. при вызове у него eval() проходит по своему "телу" (тоже список списков) и вызывает каждый список на исполнение, то бишь первый элемент считается ф-ей, у которой вызывается eval, а оставшиеся элементы списка подаются как аргументы. Таким образом, с точки зрения модели работы Лиспа, осуществляют выполнение кода VM Лиспа именно пользовательские ф-ии, в процессе итерирования своего "тела". И в этой модели нет места "внешнему вычислителю", который присутствует в специифкациях .Net или Java VM.

Дай этим объектам-функциям из Лиспа имя "инструкция", и ты поймешь, как работает Лада.

Догадываясь о возможных вопросах — да, еще на этапе трансляции, при формировании "тел" функций, транслятор проверяет, чтобы тело ф-ии было корректным, то бишь первые элементы этих списков имели тип, вроде некоего "ObjectType.Function". Реализации на не-ОО языках используют флаги, указывающие на тип объекта, но общая схема работы примерно такая же.

В Форте тоже похожая схема. Программа состоит из адресов. Интерпретатор Форта последовательно передает управление на эти адреса путем простого вызова (ассемблерная инструкция call). Встроенные ф-ии что-то делают, и в конце идет ret, а вот пользовательские ф-ии содержат первой инструкцией call опять на тот же интерпретатор, который из стека достает адрес возврата, считая, что по этому адресу лежит тело пользовательской ф-ии, то бишь список адресов, по которым в цикле надо пройтись и сделать опять этот call над каждым адресом. Получается, что в Форте аналогично как в Лиспе: каждый код, т.е. каждая инструкция программы — это ссылка на ф-ию, а не код некоего автомата из таблицы.


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

Да ради бога. Уже разжевали и в рот положили неоднократно. Была же затравка: для абстрактной VM, инструкция — лишь абстракция. При чем тут инструкции автомата, то бишь коды, кои представляют из себя ячейки той ленты машины тьюринга? И с чего ты взял, что вычислительный процесс непременно обязательно описать автоматной моделью, и инструкции обязаны быть кодами автомата? Особенно учитывая модные течения, вроде функционального программирования или data-flow процессоры, которое не являются аналогами тьюринг-машины, и где инструкции как раз и представляют из себя фактически обособленные объекты, т.к. содержат код операции и все необходимые данные к ней (вернее наоборот, в терминологии data-flow есть данные, а инструкции к ним идут как признак, tag). И ни на какой ленте эти инструкции не располагаются, они располагаются в "общем котле", и суть работы data-flow порцессора сводится к исполнению одних инструкций и порождению других как результат. Более того, в операциях, где участвует более одного операнда, эта инструкция оказывается "размазанной" по разным данным, и только когда в "общем котле" окажутся все операнды данной уникальной инструкции, все это собирается вместе и подается на вычислитель.

В принципе, коль ты так упираешь, все описанное на модель тьюринга ложится легко и просто, разумеется, ведь описан всего--лишь некий уровень абстракции, и не важно, программно он реализован, как в Форте/Лиспе/Яве, или аппаратано, как матчере дата-фло процессора, разве это интересно? Разве затем выдумываются языки высокого уровня, чтобы оперировать ячейками?

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

B>Так скажи как обозвать все вместе объекты, значения и инструкции.

Токены

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

V>Здравствуйте, Курилка, Вы писали:


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

V>Откуда такая непроходимость?

[cut]

Могу задать аналогичный вопрос.
В принципе ты сам пишешь про интерпретатор и абстрактную VM, т.е. фактически отделяешь "исполнителя кода" и код, но при этом у тебя функции сами себя выполняют.
Тогда как в лиспе — code is data, т.е. входные данные для некоего интерпретатора.
Но если вам нравится так смотреть — ради бога, только на мой взгляд это очень грубая логическая ошибка.
И никто при этом не отрицает языков высокого уровня, да и непонятно зачем и при чём тут ячейки?

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

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

B>>Так скажи как обозвать все вместе объекты, значения и инструкции.

PC_>Токены
Проверка выглядит так. В системе Lada все токены!
По аналогии все-объекты. Но, у нас же не все объекты. Звучит?
Будем ждать еще варианты.
Кстати, пришли свой док на vympel2001@yahoo.com
Мне не удалось открыть то, что скачал.

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

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

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

B>>>Так скажи как обозвать все вместе объекты, значения и инструкции.

PC_>>Токены
B>Проверка выглядит так. В системе Lada все токены!
B>По аналогии все-объекты. Но, у нас же не все объекты. Звучит?
B>Будем ждать еще варианты.
B>Кстати, пришли свой док на vympel2001@yahoo.com
B>Мне не удалось открыть то, что скачал.

прислал

B>>>Ситуация следующая. Мы выяснили что инструкции и значения не объекты. Я их объединил под общим названием потому что они формируются по общим правилам, и единому формату. Теперь возник вопрос как теперь мне все это называть? Объявляется конкурс. Жду предложений..

T>>Можно называть (сюрприз!) "инструкции" и "значения". Чем меньше своих слов придумано — тем лучше.
B>Так скажи как обозвать все вместе объекты, значения и инструкции.

Как обозвать вместе трактор, воздух и клетку? хм... Это разные вещи. Нет никакого смысла их объединять под каким-то названием.

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

T>>>Можно называть (сюрприз!) "инструкции" и "значения". Чем меньше своих слов придумано — тем лучше.
B>>Так скажи как обозвать все вместе объекты, значения и инструкции.

T>Как обозвать вместе трактор, воздух и клетку? хм... Это разные вещи. Нет никакого смысла их объединять под каким-то названием.
Еще труднее трактор, нежность и бегом.
Но, у нас есть общие свойства. Все это имеет двоичное представление, и формируется это представление по единым правилам из такого понятия как байт. Потому все имеет единый формат, и в памяти и для хранения.
Задача стоит так. Крылатое "все есть объекты", заменить на более подходящее по причине того, что не все у нас объекты. Вот это и смысл. У нас что-то конкретно есть. Как его назвать?

T>>>>Можно называть (сюрприз!) "инструкции" и "значения". Чем меньше своих слов придумано — тем лучше.
B>>>Так скажи как обозвать все вместе объекты, значения и инструкции.

T>>Как обозвать вместе трактор, воздух и клетку? хм... Это разные вещи. Нет никакого смысла их объединять под каким-то названием.
B>Еще труднее трактор, нежность и бегом.
B>Но, у нас есть общие свойства. Все это имеет двоичное представление, и формируется это представление по единым правилам из такого понятия как байт. Потому все имеет единый формат, и в памяти и для хранения.

На разных этапах жизни программы эти вещи имеют и не имеют каких-то общих свойств.

Вот и надо рассматривать разные этапы. Когда программа хранится на диске — объектов, значений и инструкций ещё нет. Потому что в файле может храниться ошибочная последовательность байтов, из которых невозможно распарсить что-либо. Во время парсинга — ну байты прочитались в токены, которые потом станут объектами или инструкциями или ещё чем-то... Токен это общее название, но не для объектов, значений и инструкций, а для тех последовательностей символов, которые потом станут этими О,З,И. Во время выполнения — да, очень большая разница между значениями и инструкциями. Нужно им общее название? Опять не нужно, потому что и интерпретатор и пользователь совершенно отдельно ими оперируют. Если надо передать значение в функцию, я пишу значение. Если надо вызвать метод, я пишу имя объекта. Если надо кинуть исключение, я пишу инструкцию.

B>Задача стоит так. Крылатое "все есть объекты", заменить на более подходящее по причине того, что не все у нас объекты. Вот это и смысл. У нас что-то конкретно есть. Как его назвать?

То есть вам нужно крылатое выражение ради крылатости? Ещё раз: объекты, значения, инструкции. Вне какого-то осмысленного контекста (например про модель выполнения) эти вещи не имеют общего названия.

Вы сначала объясните (хотя бы себе) зачем нужно выражение "всё есть X". Зачем всё под одну гребенку. Что это даёт?