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

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

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

T>Вы сначала объясните (хотя бы себе) зачем нужно выражение "всё есть X". Зачем всё под одну гребенку. Что это даёт?
Вот для того и надо что на разных этапах вот это все имеет единый формат. А на вопрос зачем это нужно отвечаю. Единый алгоритм выделения памяти, единый формат файлов. Описание формата содержится в самом файле. Отсюда следует что файл можно грузить и редактировать всеми, всегда и везде. Участок программы который обычно грузит сочиненные пользователем данных отсутствует напрочь. Как и отсутсвуют команды ввода-вывода и обмена между приложениями. Этот же формат служит протоколом обмена. Так как формат описывается парсером, при приеме можно проверять синтаксис и семантику принимаемых данных. Это вкратце, что дает единый формат. А по большому счету это глобализация данных. Кто бы, что не написал и не создал можно использовать в любом другом месте не напрягаясь на какие-то приложения. Необходимость в приложениях при таком подходе отутсвует напрочь. Вообщем есть плюсы у такого подхода.
Я ответил на вопрос что это дает?

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

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

T>>Вы сначала объясните (хотя бы себе) зачем нужно выражение "всё есть X". Зачем всё под одну гребенку. Что это даёт?
B>Вот для того и надо что на разных этапах вот это все имеет единый формат. А на вопрос зачем это нужно отвечаю. Единый алгоритм выделения памяти, единый формат файлов. Описание формата содержится в самом файле. Отсюда следует что файл можно грузить и редактировать всеми, всегда и везде. Участок программы который обычно грузит сочиненные пользователем данных отсутствует напрочь. Как и отсутсвуют команды ввода-вывода и обмена между приложениями. Этот же формат служит протоколом обмена. Так как формат описывается парсером, при приеме можно проверять синтаксис и семантику принимаемых данных. Это вкратце, что дает единый формат. А по большому счету это глобализация данных. Кто бы, что не написал и не создал можно использовать в любом другом месте не напрягаясь на какие-то приложения. Необходимость в приложениях при таком подходе отутсвует напрочь. Вообщем есть плюсы у такого подхода.
B>Я ответил на вопрос что это дает?

Да, вполне ответили. Смотрите выше про рассматривать разные этапы. При хранении и передаче, всё — данные. Значениями, объектами и инструкциями они становятся в работающей программе.

Ещё пример — описание грамматики языка. Что-то вроде:

Statement := ForStmt | ReturnStmt | IfStmt | ...
Value := Integer | String | ...
Object := ...
Expr := Value | Object # вот здесь у объектов и значений есть общее имя — выражение

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

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

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


T>Да, вполне ответили. Смотрите выше про рассматривать разные этапы. При хранении и передаче, всё — данные. Значениями, объектами и инструкциями они становятся в работающей программе.

T>А в отрыве от контекста, повторю, нет смысла искать для них общее название. Потому что оно ничем не вооружает.
Вот я и предлагаю что б это было единым на всех этапах. От редактирования, транслирования и хранения. И даже написал как это делается. Посмотри введение. Только вот слово объект не подходит.

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

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

К>[cut]

К>Могу задать аналогичный вопрос.
К>В принципе ты сам пишешь про интерпретатор и абстрактную VM, т.е. фактически отделяешь "исполнителя кода" и код, но при этом у тебя функции сами себя выполняют.

Это ты решил поиграть в Капитана Очевидность? Мы же, вроде, коллеги на этом форуме, все прекрасно знают, что происходит.

Обычно говорится, что данная ф-ия делает "то-то и то-то". Ну так принято, причем в таком ключе ведется даже начальное преподавание программированию.

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

ОК. С терминологией у человека не ахти, вместо термина "инструкция" лучше бы взял термин "операция" или "функция". ИМХО, сие не принципиально, ибо термин "инструкция" означает команда/директива, а представление команды необязательно должно быть в виде числового кода, как ты привык.


К>Тогда как в лиспе — code is data, т.е. входные данные для некоего интерпретатора.

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

К>Но если вам нравится так смотреть — ради бога, только на мой взгляд это очень грубая логическая ошибка.

Не обязательно окружающих считать идиотами.

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

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

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

К>>[cut]

К>>Могу задать аналогичный вопрос.
К>>В принципе ты сам пишешь про интерпретатор и абстрактную VM, т.е. фактически отделяешь "исполнителя кода" и код, но при этом у тебя функции сами себя выполняют.

V>Это ты решил поиграть в Капитана Очевидность? Мы же, вроде, коллеги на этом форуме, все прекрасно знают, что происходит.

V>Обычно говорится, что данная ф-ия делает "то-то и то-то". Ну так принято, причем в таком ключе ведется даже начальное преподавание программированию.

V>А мы, коллеги, прекрасно понимаем, что "то-то и то-то" делает не сама ф-ия, а процессор, на который подали скомпиллированный из ЯВУ в объектное представление код, разложенный по сегментам, загруженный затем загрузчиком ОС, с подправленными адресами, с выделенной и настроенной таблицей виртуальной памяти для сегментов, с выделенным стеком для потока, и еще кучу вещей, на пару абзацев. И какой смысл говорить каждый раз об этих банальностях? Тем более, что если VM пишется на ЯВУ, то создатель самой VM абстрагирован от подробностей архитектуры конкретной машины, для него самым низким уровнем абстракции являются элементы используемого ЯВУ, для рассматриваемого случая — объекты и их методы. Как представлена инструкция в его VM? Да так же как ф-ия в Лиспе, в виде объекта. Как передается управление этой инструкции? Да вызовом некоего метода навроде eval(). Кто это вызывает? Его ядро, функциональность которого может быть размазана по разным объектам и этим "инструкциям" в том числе. В предыдущем сообщении показал пример из Лиспа, где работа VM, по-сути, происходит в коде пользовательских ф-ий, итерирующих ("вычисляющих" в терминах Лиспа) собственное тело.

То, что VM выполняет пользовательские функции, не делает VM этими самыми функциями.

V>ОК. С терминологией у человека не ахти, вместо термина "инструкция" лучше бы взял термин "операция" или "функция". ИМХО, сие не принципиально, ибо термин "инструкция" означает команда/директива, а представление команды необязательно должно быть в виде числового кода, как ты привык.

Переименование ничего бы не дало, про числовой код я нигде ничего не писал, зачем приписывать мне свои домыслы?

К>>Тогда как в лиспе — code is data, т.е. входные данные для некоего интерпретатора.

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

С чего вдруг обратное стало неверно? Я вполне могу использовать код как данные, тем более если мы практически стопудово работаем в рамках фон-неймановской архитектуры.

К>>Но если вам нравится так смотреть — ради бога, только на мой взгляд это очень грубая логическая ошибка.

V>Не обязательно окружающих считать идиотами.

Довольно самокритично, ошибаются все, а про идиотов в моих словах ничего не было.

P.S. Консенсуса не намечается, поэтому удалюсь.

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

К>То, что VM выполняет пользовательские функции, не делает VM этими самыми функциями.

Извини, но теперь точно непроходимость... Я же на пальцах уже объяснил на примере Лиспа и Форта. Там функциональность VM размазана по "встроенным" функциям/словам соответственно для Лиспа/Форта. Пользовательская ф-ия — это тоже встроенный объект, который содержит список других ф-ий, опять же, не важно, встроенных или нет, ибо они все имеют один и тот же интерфейс. Аналогично для Форта.

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

Справедливости ради, многие реализации Лиспа тоже имеют эту особенность, то бишь цикл read-eval уже на самом Лиспе написан. Не знаю, переживет ли твой разум сие открытие, но выглядит все так, будто VM сама на себе написана... Угу, даже собственно ПАРСЕР, который считается чуть ли не основным элементом любого языка-интерпретатора...


К>Переименование ничего бы не дало, про числовой код я нигде ничего не писал, зачем приписывать мне свои домыслы?

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


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

К>С чего вдруг обратное стало неверно? Я вполне могу использовать код как данные, тем более если мы практически стопудово работаем в рамках фон-неймановской архитектуры.

Обратно вообще-то — это данные как код. Следим внимательнее. Кстати, Лисп, как и Форт, могут работать и на гарвардской архитектуре. Достаточно, чтобы архитектура могла делать jump/call по адресу, полученному из области данных. Правда, для гарвардской получается не так эффективно для Форта, потребуется костыль, но реализовать можно. Даже на дотнете Форт сделали, но там вообще через ж-у, ибо стек возвратов эмулировать пришлось, а то верификатор не пропускает ф-ии, изменяющие указатель стека после своей работы.


К>P.S. Консенсуса не намечается, поэтому удалюсь.

Да откуда консенсус в терминологических спорах? Термины, они ведь как аксиомы, идут без доказательств, так что бесполезно что-либо доказывать.

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


V>>А как же Форт?
S>Также, как и везде — есть форт-машина, которая исполняет инструкции.

А вот и нет, инструкции исполняет центральный процессор, даже в случае шитого кода.

В Форте вообще нет никакой внешней VM, она существует только в голове как элемент абстракции и как реализация цикла read-eval(-print). Там просто jump/call на слова Форта (инструкции), и вот они сами свой код и исполняют с т.з. этой абстрактной VM. Повторюсь, понятное дело, что тела этих инструкций исполняет процессор, или же низлежащая VM, если у нас некий Форт для Java/.Net, но этот уровень абстракции уже не интересен этой VM — с её уровня абстракции слова исполняются сами.


S>Архитектура машины внятно описана, instruction set — тоже. Наличие шитого кода никак не опровергает instruction immutability.

Так в Лиспе тоже, все ф-ии и замыкания иммутабельны, после создания их входным парсером, но представляют из себя объекты, даже если реализация Лиспа написана на С (классическая пара ф-ии+экземпляр структурированных данных). Чем Лада-то не угодила? Или тебя смущает, что иммутабельные объекты похожи на абстрактные типы данных? И что с того? Если в наличии ОО-язык, то АТД описываются с помощью ОО-конструкций. Ибо, парадигма программирования и некий использованный ЯВУ не обязательно имеют идентичный набор характеристик, особенно если для разработки был использован язык общего назначения, типа VB.Net.

Я лично вижу, что идет неприятие исключительно из-за того, что базовый исполнительный элемент VM для языка Лада был обозван "инструкцией". Не "замыкание" как в Лиспе, ни "слово" как в Форте, а вот "инструкция". ИМХО, оно столько обсуждения не стоило. По мне термин "слово" для Форта — куда как более спорно.

Я хочу сказать, что концепция языка Лада безусловно интересная. Это такой сплав реактивного и логического программирования. Автору пока не хватает информации, но думает он в правильном направлении. Возможно, в процессе реализации задумки (если он ее не бросит) подтянется и профессионализм, он посмотрит на реализации других языков (знания об устройстве интерпретатора Лисп/Схемы must have, это уровень 0), и ему станет более ясна собственная концепция. Понятно, что тут работы не на год и даже не на два. Так же было бы интересно реализовать язык-близнец, но в С-подобном синтаксисе, ибо он гораздо популярнее, чем VB-подобный. Возможно, даже многое в этом синтаксисе станет людям понятнее по естественным причинам "натренированности" глаза.

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

B>Обычно (и привычно) группирование объектов осуществляется скобками. Собственно для этого их и придумали. В системе используются круглые («)» и «(»), квадратные («[» и «]»),), фигурные («{» и «}»),), текстовые (««» и «»»),) и именные («"») скобки.
B>С назначением текстовых и именных скобок мы уже познакомились.

У тебя неправильный подход к объяснению. Ты вводишь понятие (группы) и начинаешь с того, как задать группу с помощью скобок. Это не академический подход, а подход в книжках типа "С++ за 21 час". Какая разница, какими скобками задаются группы, если у тебя все равно нет интерпертатора, в котором ты можешь попробовать?
Забудь про скобки для начала. Объясни, что такого группа. Зачем она нужна. В каких задачах группа могла бы быть полезной. И уже потом расскажи, что синтаксически группа задается так-то и так-то, вот пример.

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

V>А вот и нет, инструкции исполняет центральный процессор, даже в случае шитого кода.
Передергиваем-с?
Процессор исполняет свои инструкции. А не инструкции форт-машины.
V>В Форте вообще нет никакой внешней VM, она существует только в голове как элемент абстракции и как реализация цикла read-eval(-print).
Как, впрочем, и в дотнете.
V>Там просто jump/call на слова Форта (инструкции), и вот они сами свой код и исполняют с т.з. этой абстрактной VM.
Это реализация.
V>Повторюсь, понятное дело, что тела этих инструкций исполняет процессор, или же низлежащая VM, если у нас некий Форт для Java/.Net, но этот уровень абстракции уже не интересен этой VM — с её уровня абстракции слова исполняются сами.
И тем не менее, есть стек слов, есть стек данных, есть понятие текущей исполняемой инструкции. Это и есть описание состояния VM.

S>>Архитектура машины внятно описана, instruction set — тоже. Наличие шитого кода никак не опровергает instruction immutability.

V>Так в Лиспе тоже, все ф-ии и замыкания иммутабельны, после создания их входным парсером, но представляют из себя объекты, даже если реализация Лиспа написана на С (классическая пара ф-ии+экземпляр структурированных данных).
Для того, чтобы быть объектом, недостаточно иметь ссылку на функцию в экземпляре структурированных данных.

V>Чем Лада-то не угодила? Или тебя смущает, что иммутабельные объекты похожи на абстрактные типы данных? И что с того? Если в наличии ОО-язык, то АТД описываются с помощью ОО-конструкций. Ибо, парадигма программирования и некий использованный ЯВУ не обязательно имеют идентичный набор характеристик, особенно если для разработки был использован язык общего назначения, типа VB.Net.
Но мы говорим не о конкретной реализации, а о "математике", которая лежит в основе. Например, в C++ нет понятия "интерфейс"; однако при проектировании некой системы имеет смысл различать классы и интерфейсы.
Последовательность использования терминологии — залог правильного понимания.

V>Я лично вижу, что идет неприятие исключительно из-за того, что базовый исполнительный элемент VM для языка Лада был обозван "инструкцией".
Неприятие идёт исключительно из-за того, что базовый исполнительный элемент был обозван "объектом". Из-за чего возникает множество некорректных утверждений, вроде "у любого объекта есть свойство Result".
А также из-за того, что базовые исполнительные элементы имеют изменяемое состояние; при этом в качестве примеров приводятся не интуитивно ожидаемые "аггрегатор" или "триггер", а старые добрые императивные for, if, и так далее.

Не "замыкание" как в Лиспе, ни "слово" как в Форте, а вот "инструкция". ИМХО, оно столько обсуждения не стоило. По мне термин "слово" для Форта — куда как более спорно.
Дело не в спорности слова. Термин "слово" для Форта единожды определён, и используется непротиворечиво. В нём нет тенденции называть "словом" всё подряд.

V>Я хочу сказать, что концепция языка Лада безусловно интересная. Это такой сплав реактивного и логического программирования. Автору пока не хватает информации, но думает он в правильном направлении.
Возможно. Я пока фундаментальных проблем в самом языке не вижу. Я просто пока не могу понять, как именно это работает.

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

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


V>У тебя неправильный подход к объяснению. Ты вводишь понятие (группы) и начинаешь с того, как задать группу с помощью скобок. Это не академический подход, а подход в книжках типа "С++ за 21 час". Какая разница, какими скобками задаются группы, если у тебя все равно нет интерпертатора, в котором ты можешь попробовать?
V>Забудь про скобки для начала. Объясни, что такого группа. Зачем она нужна. В каких задачах группа могла бы быть полезной. И уже потом расскажи, что синтаксически группа задается так-то и так-то, вот пример.
Могет быть. Я подумаю.

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

V>>В Форте вообще нет никакой внешней VM, она существует только в голове как элемент абстракции и как реализация цикла read-eval(-print).
S>Как, впрочем, и в дотнете.

Да нет, в дотнете есть спецификация процессора с набором инструкций.

S>И тем не менее, есть стек слов, есть стек данных, есть понятие текущей исполняемой инструкции. Это и есть описание состояния VM.

Только стек данных и стек возвратов. Состояния стека и есть описание состояния. Понятия текущей исполняемой инструкции нет — это за рамками. Спецификации Форта вообще ограничиваются весьма высокоуровневыми вещами, в отличие от VM .Net.



S>>>Архитектура машины внятно описана, instruction set — тоже. Наличие шитого кода никак не опровергает instruction immutability.

V>>Так в Лиспе тоже, все ф-ии и замыкания иммутабельны, после создания их входным парсером, но представляют из себя объекты, даже если реализация Лиспа написана на С (классическая пара ф-ии+экземпляр структурированных данных).
S>Для того, чтобы быть объектом, недостаточно иметь ссылку на функцию в экземпляре структурированных данных.

Тем не менее, если в распоряжении ОО-язык, то все вокруг — объекты.

S>Но мы говорим не о конкретной реализации, а о "математике", которая лежит в основе.

Ну, с этим проблемы, и то, больше терминологического плана.

S>Например, в C++ нет понятия "интерфейс"; однако при проектировании некой системы имеет смысл различать классы и интерфейсы.

В С++ понятие интерфейса совпадает с оным для обычного ООП — это видимый АПИ типов. А различать стоит действительно интерфейсы (только не в рамках интерфейсов дотнета/явы/дельфи) и реализующие типы. В С++ со всем этим полный порядок, т.к. реализует несколько видов полиморфизма, в отличие от явы/дотнета.

S>Последовательность использования терминологии — залог правильного понимания.

К примеру, в Скала всё является объектом, даже int. И как-то гневной критики в их адрес не слышу...


V>>Я лично вижу, что идет неприятие исключительно из-за того, что базовый исполнительный элемент VM для языка Лада был обозван "инструкцией".
S>Неприятие идёт исключительно из-за того, что базовый исполнительный элемент был обозван "объектом".

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

S>Из-за чего возникает множество некорректных утверждений, вроде "у любого объекта есть свойство Result".

Наверно имелось ввиду "у любого объекта в такой-то иерархии". Да там вообще товарищ выдает много ненужных подробностей, которые сугубо относятся к реализации языка. Очевидно, ему плохо удается отделять спецификацию языка от реализации, и он перескакивает с одного на другое. Чего стоит только куча постов вокруг "FOR I", и о том, что I -имя цикла FOR. Это уже несущественные подробности метаинформации, и налицо наивная попытка сэкономить на спичках, ибо если I — имя цикла, то где же информация о типе итерируемой переменной. В общем, слабина в реализации видна невооруженным взглядом и вряд ли стоило эти моменты вообще обсуждать.


S>А также из-за того, что базовые исполнительные элементы имеют изменяемое состояние; при этом в качестве примеров приводятся не интуитивно ожидаемые "аггрегатор" или "триггер", а старые добрые императивные for, if, и так далее.

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


S>Не "замыкание" как в Лиспе, ни "слово" как в Форте, а вот "инструкция". ИМХО, оно столько обсуждения не стоило. По мне термин "слово" для Форта — куда как более спорно.
S>Дело не в спорности слова. Термин "слово" для Форта единожды определён, и используется непротиворечиво. В нём нет тенденции называть "словом" всё подряд.

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


V>>Я хочу сказать, что концепция языка Лада безусловно интересная. Это такой сплав реактивного и логического программирования. Автору пока не хватает информации, но думает он в правильном направлении.
S>Возможно. Я пока фундаментальных проблем в самом языке не вижу. Я просто пока не могу понять, как именно это работает.

Ну так эти вопросы и надо было задавать:
— каков общий сценарий вызова событий?
— кто именно и в какие моменты производит группировку событий и вычисление предусловий?
— какой самый общий верхний цикл этой VM (на простейшем псевдокоде)?
— что с асинхронностью и многозадачностью?
— как определяется точка входа и где останов?

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

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


S>Она говорит либо о том, что вы не различаете понятия "тип" и "значение", либо о том, что вы непоследовательно пользуетесь собственной терминологией.

О, наконец-то по делу! Дело в том, что в системе, когда у некоего типа может быть лишь единственный экземпляр, разница м/у типом и значением перетекают в область сугубо философскую. Ибо один экземпляр — это реально круто. Не больше (это фигня), но самое важное — не меньше, а ровно один, что означает, что одно без другого не существует и не имеет смысла, в отличии от системы, где на каждый тип может быть от 0-ля до оо экземпляров.

S>Логический — это, надо полагать, объект-значение. А у него тоже есть свойство Result? Или утверждение "свойство Result есть у всех объектов" оказалось опрометчивым?

Хотя ты и прав, скорее всего является опрометчивым с т.з. его реализации, но не удержусь...
Пусть есть у нас некий объект Int32, имеющий св-во Value, типа.. Int32... Ну ты понял. Это ничему не противоречит, коль у нас есть операция сравнения объектов, ибо не нужно до бесконечности "вынимать" св-во Value. Например, в некоторых системах без ATD простые булевы данные представляются через идентити двух объектов с глобальной видимостью: #t и #f. И речь идет о чистом функциональном языке, построенном сугубо на объектах. Не зря создатель этого языка в соседней ветке выступал как защитник ООП.


S>>>Я не понимаю, что изменяется в инструкции I = I + 1 при её выполнении. В классике меняется состояние машины: значение, хранящееся в переменной с именем "I". Инструкция остаётся точно такой же. Ей не нужен никакой Result — доступа к нему всё равно никто не получит.
B>>В вашем примере две инструкции. Сложения и присвоения.
S>Или три. Доступа к значению, сложения, и присваивания. Или пять — доступа к значению, приведения типа, сложения, приведения типа, присваивания.
S>Ни у одной из них нет никакого изменяемого состояния.

Есть, если (возвращаясь к нашим баранам) инструкции "сами себя исполняют". У самой верхней инструкции будет состояние-курсор текущей дочерней операции. Аналогичное поведение унутрях ф-ий Лиспа я уже упоминал. Фишка тут в том,что если вызов инструкции считать атомарным событием, то состояния как бы и нет, и оно нам непосредственно не доступно на некоем уровне абстракции. И это важно. Именно здесь лежит граница м/у функциональным и императивным вглядом на вещи. Но реально-то состояние есть, иначе такая фишка функционального программирования, как продолжения, без этого внутреннего состояния не работала бы.


S>Нет. Ничего очевидного тут нету. Ну вот к примеру — как же он превратится в исполняемый код, если без виртуальной машины он всё равно не может выполниться?

А чем реальная машина хуже виртуальной? И как это "объект не может выполнится"? Передай объекту управление, вызвав какой-нить метод, и все.


S>Ваш компилятор ничего подобного сделать не сможет — потому, что у for есть какой-то Result, который нужно менять при исполнении, даже если внутри цикла ничего не происходит.

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

Здравствуйте, PC_2, Вы писали:
потому что таких уже напридумывали и нариализовывали тысячи.

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

Именно, и то слишком уж народ интересуется подробностями реализации, не поняв толком как оно работает на самом общем уровне.