за критические замечания. Благодаря Вам мне удалось сформулировать чего я все-таки хотел сказать. И вот общая идея созрела: Я ее назвал концептной парадигмой. Но может быть это где-то и субъектное программирование. В том смысле что в основе парадигмы создание субъекта и программирование его отношения к объектам.
Концепт это двойка (L, S), где L это его размер (определяемый свойствами концепта), а S — семантическое содержание (программа), определяющее его отношения с другими концептами. Создание концепта заключается в определении его свойств и последовательности концептов, определяющих его семантику.
Т.е. классы, функции, операторы (все понятия системы, манипулирующие объектами) это не жестко заданное и реализованное в трансляторе или системе, а определяемое непосредственно концептами. Наличие единых правил определения размера концепта позволяет единообразно манипулировать ими в смысле выделения памяти, служить протоколом обмена и основой для хранения и редактирования. Расширения и форматы файлов тоже теряют смысл, так как файл (документ) имеет тоже формат концепта, и содержат описание своего формата в себе.
Правила создания новых концептов, например, классов, которые в свою очередь будут создавать объекты, едины. Так же единый и синтаксис для создания концептов. Таким образом, получаем макроязык, в рамках которого реализуются другие языки, являющиеся обычно подмножествами общих правил синтаксиса, но с новым семантическим содержанием. Отсюда же следует собственный язык описания грамматик, который так же является частью общего синтаксиса.
Можно сказать концептами (Concept) создаются субъекты (концепты-классы, концепты-типы), которые в свою очередь могут порождать объекты, субъекты (концепты-функции) и субъекты которые определяют отношения с объектами (концепты-операторы). Все вышеперечисленное, конечно, является концептами, являясь классами, типами, функциями и т.д. Так концепты Class порождают концепты-объекты, концепты Type порождают концепты-значения, концепты-операторы (операторы For, If и т.п.) порождаются непосредственно концептами. Семантическое содержание концепта обеспечивается функционалом, запрограммированным в свойстве Child концепта. Отсюда выполнение каждого концепта виртуальной машиной (VML) заключается в выполнении свойств концепта в порядке заданном при его определении, и затем вложенных концептов (для базовых концептов это двоичный код) содержащихся в свойстве Child. Таким образом, VML не выполняет ничего, кроме того что определено концептом.
Свойства и размер концепта определяются базовыми концептами Concept, Property, Byte и Tape. Концепт Byte определяет размер свойства, концепт Property собственно и создает свойство, определяет его имя и содержание. Концепт Tape объединяет концепты в группы.
Естественно весь материал переработан, потому решил создать новую ветку где буду отвечать на вопросы и скидывать доп. материалы. Если, конечно, будет интерес.
Всем спасибо!
Скажу только что на лето планируется все это реализовать.
?
Прошел год с обещанного момента?
B>Благодаря Вам мне удалось сформулировать чего я все-таки хотел сказать. И вот общая идея созрела: ...
Извини, видимо мы старались недостаточно сильно, но понять то что ты понаписал далее невозможно. По крайней мере я не пнял.
И вообще, кому нужны концептуальные объяснения роли концептов в концепции парадигмы концептуального программирования?
Любой программист тебе скажет — покажи мне код, черт побери!
B>Я ее назвал концептной парадигмой.
Лучше парадигмальной концепцией. По смысле тоже самое, но звучит как-о веселее .
B> Но может быть это где-то и субъектное программирование. В том смысле что в основе парадигмы создание субъекта и программирование его отношения к объектам.
О, как? И кто же такой этот субъект? Может стоит начать с определения терминов?
B>Концепт это двойка (L, S), где L это его размер (определяемый свойствами концепта), а S — семантическое содержание (программа),
О, как? Ну, "семантическое содержание" — это понятно. Это квази-уно-фантазия, а вот что такое размер? И как размер может определяться свойствами? А свойства — это что за фигня?
B> определяющее его отношения с другими концептами.
А что значит "отношение"? И как оно определяется?
Это набор слов. Бессмысленный и беспощадный.
B>Создание концепта заключается в определении его свойств и последовательности концептов, определяющих его семантику.
А где длинна? И как определять эту последовательность концептов определяющих его семантику?
B> Наличие единых правил определения размера концепта позволяет единообразно манипулировать ими в смысле выделения памяти, служить протоколом обмена и основой для хранения и редактирования.
Хранения и редактирования чего? Где у тебя в твоей концепции хотя бы данные то хранятся?
B> Расширения и форматы файлов тоже теряют смысл,
Ну, да — "Москва переименовывается в Нь`Васиюки, а Васиюки в Москва.".
А то что у людей есть "легаси-файлы" (doc, html, и т.п.) нас не волнуют. Мы же вселенский всемогутер изобретаем. Нам не пристало мелочиться.
B>так как файл (документ) имеет тоже формат концепта, и содержат описание своего формата в себе.
Ближе к делу. Можно поглядеть как будет выглядит описание хоря бы простенького формата HTML? О doc-е я и не заикаюсь.
B>Правила создания новых концептов, например, классов, которые в свою очередь будут создавать объекты, едины. B> Так же единый и синтаксис для создания концептов.
Так покажи приерчик.
B>...Естественно весь материал переработан, потому решил создать новую ветку где буду отвечать на вопросы и скидывать доп. материалы. Если, конечно, будет интерес.
Мы правильно поняли, что очередным летом надо ждать очередной реализации?
ЗЫ
Сколько можно этим бредом людям мозг выносить? Если ты что-то хочешь придумать, то сделай хотя бы прототип и покажи то что получилось людям. Ну, или хотя бы псевдокод покажи.
Название вообще фееричное. Сразу вспомнил радио "Московская Москва".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, batu, Вы писали:
B>>Для начала хочу выразить благодарность всем участникам обсуждения http://www.rsdn.ru/forum/philosophy/3734245.aspx за критические замечания.
VD>А что с вот этим заявлением: VD>
VD>Скажу только что на лето планируется все это реализовать.
VD>?
Слово "Все" было опрометчивым. Но очередную версию сделал. По ходу появились новые мысли. Вот их и хочу изложить.
VD>Прошел год с обещанного момента?
B>>Благодаря Вам мне удалось сформулировать чего я все-таки хотел сказать. И вот общая идея созрела: ...
VD>Извини, видимо мы старались недостаточно сильно, но понять то что ты понаписал далее невозможно. По крайней мере я не пнял.
Есть такая проблема. Объясняю плохо. Извини. Стараюсь.
VD>И вообще, кому нужны концептуальные объяснения роли концептов в концепции парадигмы концептуального программирования?
VD>Любой программист тебе скажет — покажи мне код, черт побери!
B>>Я ее назвал концептной парадигмой.
VD>Лучше парадигмальной концепцией. По смысле тоже самое, но звучит как-о веселее .
B>> Но может быть это где-то и субъектное программирование. В том смысле что в основе парадигмы создание субъекта и программирование его отношения к объектам.
VD>О, как? И кто же такой этот субъект? Может стоит начать с определения терминов?
Субъект (философия) — носитель действия, тот, кто (или то, что) познаёт, мыслит или действует, в отличие от объекта (как того, на что направлены мысль или действие субъекта).
Отсюда здесь
B>>Концепт это двойка (L, S), где L это его размер (определяемый свойствами концепта), а S — семантическое содержание (программа),
VD>О, как? Ну, "семантическое содержание" — это понятно. Это квази-уно-фантазия, а вот что такое размер? И как размер может определяться свойствами? А свойства — это что за фигня?
Размер концепта определяется наличием свойств. В том смысле что каждое свойство имеет свои размеры.
B>> определяющее его отношения с другими концептами.
VD>А что значит "отношение"? И как оно определяется?
Субъект и объект познания. Это из философии. Концептом определяется одно из представлений субъектом объектов. Это представление и названо здесь отношением. Оно же "семантическое содержание" и фактически программа ее реализующая.
Так, например, концепт For выполняет свое содержимое несколько раз. Думаю реализация концепта For вопросов не вызывает.
VD>Это набор слов. Бессмысленный и беспощадный.
Не дам голову на отсечение что терминология удачная. Но, такая как есть на сегодняшний день.
B>>Создание концепта заключается в определении его свойств и последовательности концептов, определяющих его семантику.
VD>А где длинна? И как определять эту последовательность концептов определяющих его семантику?
Про длину уже ответил.
B>> Наличие единых правил определения размера концепта позволяет единообразно манипулировать ими в смысле выделения памяти, служить протоколом обмена и основой для хранения и редактирования.
VD>Хранения и редактирования чего? Где у тебя в твоей концепции хотя бы данные то хранятся?
B>> Расширения и форматы файлов тоже теряют смысл,
VD>Ну, да — "Москва переименовывается в Нь`Васиюки, а Васиюки в Москва.".
VD>А то что у людей есть "легаси-файлы" (doc, html, и т.п.) нас не волнуют. Мы же вселенский всемогутер изобретаем. Нам не пристало мелочиться.
B>>так как файл (документ) имеет тоже формат концепта, и содержат описание своего формата в себе.
VD>Ближе к делу. Можно поглядеть как будет выглядит описание хоря бы простенького формата HTML? О doc-е я и не заикаюсь.
Заикнись. В каком смысле выглядит? На экране в тексте или как хранится?
B>>Правила создания новых концептов, например, классов, которые в свою очередь будут создавать объекты, едины. B>> Так же единый и синтаксис для создания концептов.
VD>Так покажи примерчик.
та не вопрос. Сначала представлю группы что б новые правила описания грамматик были понятны, потом саму грамматику.
B>>...Естественно весь материал переработан, потому решил создать новую ветку где буду отвечать на вопросы и скидывать доп. материалы. Если, конечно, будет интерес.
VD>Мы правильно поняли, что очередным летом надо ждать очередной реализации?
Правильно понимаешь.
VD>Сколько можно этим бредом людям мозг выносить? Если ты что-то хочешь придумать, то сделай хотя бы прототип и покажи то что получилось людям. Ну, или хотя бы псевдокод покажи.
VD>Название вообще фееричное. Сразу вспомнил радио "Московская Москва".
Покажу. И показывал. Не все сразу.
Пока очень мутно, нужны примеры!
Вот есть задача: отсортировать строки в файле. Как она будет решаться в этой парадигме?
Как описать тот же цикл for? А foreach по коллекции? А выброс исключения? А ограничение доступа к методу? Можно ли описать концепцию аппликативного функтора?
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, batu.
DM>Пока очень мутно, нужны примеры! DM>Вот есть задача: отсортировать строки в файле. Как она будет решаться в этой парадигме?
Сортировки как обычно. Отличия не большие только в синтаксисе. За него позже поговорим. За строковые объекты могу сказать что это частный случай перечислимых объектов. Специального такого класса нет. DM>Как описать тот же цикл for? А foreach по коллекции? А выброс исключения? А ограничение доступа к методу? Можно ли описать концепцию аппликативного функтора?
Цикл можно организовать группой. Группа имеет свойства Min и Max значения которых определяются соответственно подстрочным и надстрочным значением после закрывающей скобки. Виртуальная машина выполняет группу в зависимости от этих значений.
Полное описание группирования и применения скобок здесь
Концепт For будет выглядеть где-то так.
Concept For
{Property Integer Per=0 ' Переменная цикла со значением по умолчанию=0
Property Integer End ' Значение конца цикла
Per+:=1
IfElse Per<=End { Execute Else Exit Concept For }
}
При трансляции выражения
For I=1 To N {... }
Создается концепт класса For и именем I соответствующими значениями свойств концепта. В таком формате и хранится. Результат трансляции — тоже концепты.
На выполнение в виртуальную машину попадает содержимое концепта. Так и выполняется цикл.
Это, конечно приблизительно. Потому как, конечно, такие концепты реализуются на ассемблере или C+.
Здравствуйте, batu, Вы писали:
B>Для начала хочу выразить благодарность всем участникам обсуждения http://www.rsdn.ru/forum/philosophy/3734245.aspx за критические замечания. Благодаря Вам мне удалось сформулировать чего я все-таки хотел сказать. И вот общая идея созрела: Я ее назвал концептной парадигмой. Но может быть это где-то и субъектное программирование. В том смысле что в основе парадигмы создание субъекта и программирование его отношения к объектам.
Первая формальная ошибка: субъект и объект — это сугубо ролевые характеристики. Единственный "настоящий" субъект — человек, сидящий за клавиатурой. Остальное — игры разума.
Потом, как водится, ты начинаешь не с того конца: с парадигмы и прочих паттернов (читай, концептов). Под твоё определение "програмирования отношений к объектам" можно притянуть любую программу на любом языке.
B>Концепт это двойка (L, S), где L это его размер (определяемый свойствами концепта), а S — семантическое содержание (программа), определяющее его отношения с другими концептами. Создание концепта заключается в определении его свойств и последовательности концептов, определяющих его семантику.
То есть концепт — это некая программа некоторого размера? Оригинально!
B>Т.е. классы, функции, операторы (все понятия системы, манипулирующие объектами) это не жестко заданное и реализованное в трансляторе или системе, а определяемое непосредственно концептами. Наличие единых правил определения размера концепта позволяет единообразно манипулировать ими в смысле выделения памяти, служить протоколом обмена и основой для хранения и редактирования. Расширения и форматы файлов тоже теряют смысл, так как файл (документ) имеет тоже формат концепта, и содержат описание своего формата в себе.
Потерялся субъект действия (да, я про человека). Именно этот субъект назначает группам действий характеристики, как то: оператор, функция, класс и т.п. Расширения и форматы файлов точно так же порождены человеком для решения определённых задач.
B>Правила создания новых концептов, например, классов, которые в свою очередь будут создавать объекты, едины. Так же единый и синтаксис для создания концептов. Таким образом, получаем макроязык, в рамках которого реализуются другие языки, являющиеся обычно подмножествами общих правил синтаксиса, но с новым семантическим содержанием. Отсюда же следует собственный язык описания грамматик, который так же является частью общего синтаксиса.
Это как раз всё не важно. У нас есть уже единый язык — он называется Ассемблером. Посмотри, сколько поверх него нагромождено.
B>Можно сказать концептами (Concept) создаются субъекты (концепты-классы, концепты-типы), которые в свою очередь могут порождать объекты, субъекты (концепты-функции) и субъекты которые определяют отношения с объектами (концепты-операторы). Все вышеперечисленное, конечно, является концептами, являясь классами, типами, функциями и т.д. Так концепты Class порождают концепты-объекты, концепты Type порождают концепты-значения, концепты-операторы (операторы For, If и т.п.) порождаются непосредственно концептами. Семантическое содержание концепта обеспечивается функционалом, запрограммированным в свойстве Child концепта. Отсюда выполнение каждого концепта виртуальной машиной (VML) заключается в выполнении свойств концепта в порядке заданном при его определении, и затем вложенных концептов (для базовых концептов это двоичный код) содержащихся в свойстве Child. Таким образом, VML не выполняет ничего, кроме того что определено концептом.
Семантическое содержание — это сильная сила, что там.
Короче говоря, примеры и описания — это всё чепуха. Ты покажи базовый словарь символов твоей системы. Без него ничего не получится.
B>Свойства и размер концепта определяются базовыми концептами Concept, Property, Byte и Tape. Концепт Byte определяет размер свойства, концепт Property собственно и создает свойство, определяет его имя и содержание. Концепт Tape объединяет концепты в группы.
Так... А что насчёт примеров (присоединюсь к предыдущим ораторам)?
B>Естественно весь материал переработан, потому решил создать новую ветку где буду отвечать на вопросы и скидывать доп. материалы. Если, конечно, будет интерес.
Интерес, конечно, есть: надо же подрастающему поколению учиться, как не надо подходить к разработке ПО, не у всех хватает смелости выносить свои ошибки на всеобщее обозрение. Так что, ждём продолжения.
B>Всем спасибо!
Пожалуйста.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Первая формальная ошибка: субъект и объект — это сугубо ролевые характеристики. Единственный "настоящий" субъект — человек, сидящий за клавиатурой. Остальное — игры разума.
Игры, конечно. Вопрос ради чего. Геометрии Лобачевского и Римана тоже игры.
ГВ>Потом, как водится, ты начинаешь не с того конца: с парадигмы и прочих паттернов (читай, концептов). Под твоё определение "программирования отношений к объектам" можно притянуть любую программу на любом языке.
А с какого конца не начинай начало надо усвоить.
ГВ>То есть концепт — это некая программа некоторого размера? Оригинально!
Это не ради оригинальности. Именно единый метод построения позволяет решать задачи распределения памяти, загрузку, хранение, передачу в сети простым единым алгоритмом.
ГВ>Потерялся субъект действия (да, я про человека). Именно этот субъект назначает группам действий характеристики, как то: оператор, функция, класс и т.п. Расширения и форматы файлов точно так же порождены человеком для решения определённых задач.
Ну, да..
ГВ>Это как раз всё не важно. У нас есть уже единый язык — он называется Ассемблером. Посмотри, сколько поверх него нагромождено.
Я бы не сказал что он единый. Архитектур машин и ассемблеров тоже не мало. И как на мое мнение интеловская не самая лучшая с которой я знаком.
ГВ>Короче говоря, примеры и описания — это всё чепуха. Ты покажи базовый словарь символов твоей системы. Без него ничего не получится.
А базовый словарь я уже привел. Это Concept, Property, Byte и Tape. Ну, еще правила группирования и концепт Selector — адресация. Это все. На этом строится вся система.
ГВ>Так... А что насчёт примеров (присоединюсь к предыдущим ораторам)?
Здравствуйте, batu, Вы писали:
ГВ>>Первая формальная ошибка: субъект и объект — это сугубо ролевые характеристики. Единственный "настоящий" субъект — человек, сидящий за клавиатурой. Остальное — игры разума. B>Игры, конечно. Вопрос ради чего. Геометрии Лобачевского и Римана тоже игры.
Вот именно — вопрос, ради чего.
ГВ>>То есть концепт — это некая программа некоторого размера? Оригинально! B>Это не ради оригинальности. Именно единый метод построения позволяет решать задачи распределения памяти, загрузку, хранение, передачу в сети простым единым алгоритмом.
Хм... Допустим.
ГВ>>Потерялся субъект действия (да, я про человека). Именно этот субъект назначает группам действий характеристики, как то: оператор, функция, класс и т.п. Расширения и форматы файлов точно так же порождены человеком для решения определённых задач. B>Ну, да..
Следовательно, сначала нужно сформулировать актуальную для человека задачу. Какую задачу ты собираешься решать?
ГВ>>Это как раз всё не важно. У нас есть уже единый язык — он называется Ассемблером. Посмотри, сколько поверх него нагромождено. B>Я бы не сказал что он единый. Архитектур машин и ассемблеров тоже не мало. И как на мое мнение интеловская не самая лучшая с которой я знаком.
Есть его аппроксимация — C. Те же тестикулы, но в другом ракурсе.
ГВ>>Короче говоря, примеры и описания — это всё чепуха. Ты покажи базовый словарь символов твоей системы. Без него ничего не получится. B>А базовый словарь я уже привел. Это Concept, Property, Byte и Tape. Ну, еще правила группирования и концепт Selector — адресация. Это все. На этом строится вся система.
Тогда второй вопрос: как их можно связывать между собой?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, batu, Вы писали:
B>Полное описание группирования и применения скобок здесь
Эту ссылку нельзя открыть никому, кроме тебя (это приватный список твоих файлов).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, batu, Вы писали:
ГВ>>>Первая формальная ошибка: субъект и объект — это сугубо ролевые характеристики. Единственный "настоящий" субъект — человек, сидящий за клавиатурой. Остальное — игры разума. B>>Игры, конечно. Вопрос ради чего. Геометрии Лобачевского и Римана тоже игры.
ГВ>Вот именно — вопрос, ради чего.
А не все удобно формулировать в геометрии Евклида. Больше незачем.
ГВ>Следовательно, сначала нужно сформулировать актуальную для человека задачу. Какую задачу ты собираешься решать?
Хороший вопрос. Так в том и фишка что виртуальная машина фактически пустая. А соответственно задаче конструируем набор концептов. Хоть функциональную парадигму, хоть императивную. Система будет работать по любому.
ГВ>>>Это как раз всё не важно. У нас есть уже единый язык — он называется Ассемблером. Посмотри, сколько поверх него нагромождено. B>>Я бы не сказал что он единый. Архитектур машин и ассемблеров тоже не мало. И как на мое мнение интеловская не самая лучшая с которой я знаком.
ГВ>Есть его аппроксимация — C. Те же тестикулы, но в другом ракурсе.
Та если у машины другая разрядность адресации и другое количество регистров. Да и не обязательно набор команд привязан к регистрам тут текстура не поможет. А тут реализовал несколько десятков концептов, а все остальное покатит.
ГВ>>>Короче говоря, примеры и описания — это всё чепуха. Ты покажи базовый словарь символов твоей системы. Без него ничего не получится. B>>А базовый словарь я уже привел. Это Concept, Property, Byte и Tape. Ну, еще правила группирования и концепт Selector — адресация. Это все. На этом строится вся система.
ГВ>Тогда второй вопрос: как их можно связывать между собой?
Так все очень просто. Есть только эти 5 концептов из них все остальное и конструируется. И операции и классы и все..
Вот в этом и основная фишка.. Не привычно по началу. Но реально
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, batu, Вы писали:
B>>Полное описание группирования и применения скобок здесь
ГВ>Эту ссылку нельзя открыть никому, кроме тебя (это приватный список твоих файлов).
А как открыть? Я прошлый раз делал получалось.. Сюда скопировать не получится. Там редактировать надо подстрочные, надстрочные и т.п..
Здравствуйте, batu, Вы писали:
B>>>Полное описание группирования и применения скобок здесь ГВ>>Эту ссылку нельзя открыть никому, кроме тебя (это приватный список твоих файлов). B>А как открыть? Я прошлый раз делал получалось.. Сюда скопировать не получится. Там редактировать надо подстрочные, надстрочные и т.п..
Выложи просто индивидуальные ссылки. Такие ссылки имеют вид: http://files.rsdn.ru/{user-id}/{file-name}
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, batu, Вы писали:
ГВ>>>>Первая формальная ошибка: субъект и объект — это сугубо ролевые характеристики. Единственный "настоящий" субъект — человек, сидящий за клавиатурой. Остальное — игры разума. B>>>Игры, конечно. Вопрос ради чего. Геометрии Лобачевского и Римана тоже игры. ГВ>>Вот именно — вопрос, ради чего. B>А не все удобно формулировать в геометрии Евклида. Больше незачем.
Правильно. Тогда вопрос: ради каких задач нужно вводить термин "субъект"? То есть в чём проблема имеющейся терминологии?
ГВ>>Следовательно, сначала нужно сформулировать актуальную для человека задачу. Какую задачу ты собираешься решать? B>Хороший вопрос. Так в том и фишка что виртуальная машина фактически пустая. А соответственно задаче конструируем набор концептов. Хоть функциональную парадигму, хоть императивную. Система будет работать по любому.
Не-не-не. "Хоть функциональная, хоть императивная" — это не задача. Ты про что-нибудь такое расскажи, что имеет значение для пользователя, а не о программистских упражнениях.
ГВ>>>>Это как раз всё не важно. У нас есть уже единый язык — он называется Ассемблером. Посмотри, сколько поверх него нагромождено. B>>>Я бы не сказал что он единый. Архитектур машин и ассемблеров тоже не мало. И как на мое мнение интеловская не самая лучшая с которой я знаком. ГВ>>Есть его аппроксимация — C. Те же тестикулы, но в другом ракурсе. B>Та если у машины другая разрядность адресации и другое количество регистров. Да и не обязательно набор команд привязан к регистрам тут текстура не поможет. А тут реализовал несколько десятков концептов, а все остальное покатит.
Хорошо, а чем плох Lisp/Scheme?
ГВ>>>>Короче говоря, примеры и описания — это всё чепуха. Ты покажи базовый словарь символов твоей системы. Без него ничего не получится. B>>>А базовый словарь я уже привел. Это Concept, Property, Byte и Tape. Ну, еще правила группирования и концепт Selector — адресация. Это все. На этом строится вся система. ГВ>>Тогда второй вопрос: как их можно связывать между собой? B>Так все очень просто. Есть только эти 5 концептов из них все остальное и конструируется. И операции и классы и все.. B>Вот в этом и основная фишка.. Не привычно по началу. Но реально
Снова напоминает Lisp. Впрочем, подожду, пока ты выложишь ссылки на описание.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, batu, Вы писали:
ГВ>>>>>Первая формальная ошибка: субъект и объект — это сугубо ролевые характеристики. Единственный "настоящий" субъект — человек, сидящий за клавиатурой. Остальное — игры разума. B>>>>Игры, конечно. Вопрос ради чего. Геометрии Лобачевского и Римана тоже игры. ГВ>>>Вот именно — вопрос, ради чего. B>>А не все удобно формулировать в геометрии Евклида. Больше незачем.
ГВ>Правильно. Тогда вопрос: ради каких задач нужно вводить термин "субъект"? То есть в чём проблема имеющейся терминологии?
Я бы не хотел вводить термин "Субъект" и тем более "Субъектно-ориентирование программирование". Слишком громко. Хотя похоже. Давай остановимся на концептах. Это скромнее.
ГВ>Снова напоминает Lisp. Впрочем, подожду, пока ты выложишь ссылки на описание.
Я не понял как сделать эти ссылки. Пошагово скажи.
Здравствуйте, batu, Вы писали:
ГВ>>Правильно. Тогда вопрос: ради каких задач нужно вводить термин "субъект"? То есть в чём проблема имеющейся терминологии? B>Я бы не хотел вводить термин "Субъект" и тем более "Субъектно-ориентирование программирование". Слишком громко. Хотя похоже. Давай остановимся на концептах. Это скромнее.
O'K.
ГВ>>Снова напоминает Lisp. Впрочем, подожду, пока ты выложишь ссылки на описание. B>Я не понял как сделать эти ссылки. Пошагово скажи.
1. Заходишь к себе в профиль. Нажимаешь на "Файлы". Видишь список своих файлов.
2. Выбираешь нужный файл, нажимаешь на нём правой кнопкой мыши. В контекстном меню выбираешь "скопировать ссылку".
3. Ссылку вставляешь в сообщение.
Всё, в общем-то. Два последних пункта повторить для всех файлов, которые ты хочешь показать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DM>Как описать тот же цикл for? А foreach по коллекции? А выброс исключения? А ограничение доступа к методу? Можно ли описать концепцию аппликативного функтора?
Да, извини. Ограничение доступа как обычно. Private аму, тНи т.д. Если это имелось в виду. А т ка прецеденты.И новая фишм много чего еще и по наследованию и интерфейсы. И новая фишка Прецеденты. Это по событиям тоже типа интерфейса. Кстати, события и исключения формируют. Это уже глубоко в конкретику..
ГВ>1. Заходишь к себе в профиль. Нажимаешь на "Файлы". Видишь список своих файлов. ГВ>2. Выбираешь нужный файл, нажимаешь на нём правой кнопкой мыши. В контекстном меню выбираешь "скопировать ссылку". ГВ>3. Ссылку вставляешь в сообщение.
ГВ>Всё, в общем-то. Два последних пункта повторить для всех файлов, которые ты хочешь показать.
Спасибою Делаю по инструкции здесь
Здравствуйте, batu, Вы писали:
B>Спасибою Делаю по инструкции здесь
Да, сейчас всё в порядке.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, batu, Вы писали:
ГВ>>Всё, в общем-то. Два последних пункта повторить для всех файлов, которые ты хочешь показать. B>Спасибою Делаю по инструкции здесь
Позволю себе вопрос: что это такое? Досужие рассуждения студента-фантаста, испытавшего приступ маниловщины или некое техническое описание?
Если второе (я так понимаю, ты предполагаешь, что это оно и есть), то я не понимаю, откуда ты выдёргиваешь термины.
Обычно (и привычно) объединение концептов осуществляется скобками. Собственно для этого скобки и придумали.
Was ist концепт? Что это такое?
Потом, ты сходу вводишь кучу разновидностей скобок (сиречь — группировок), постоянно ссылаясь на некое "выполнение" концептов, но при этом пропущено объяснение того, что же такое это самое выполнение. В смысле, сама модель вычислительной среды у тебя отсутствует. Что, за чем, кем и когда выполняется? Ну не с неба же оно всё берётся!
Вот это вообще десять:
Любой концепт может представлять собой как императивную сущность, так и логическую
Что это такое: императивная сущность? А логическая?
То есть уже получается так, что прежде, чем понять написанное даже в первом разделе нужно прочесть всё с начала до конца, плюс по диагонали и не забыть сделать конспект. Ты издеваешься, что ли?
Добавим сюда путаницу. Раздел 1 вводит термины: круглые, фигурные, квадратные, именные, перечислимые, лексические, метареализации (это всё были скобки). Хорошо, пусть так. Раздел 2:
1. В скобках объединено один, и более концептов. Это непосредственно группирование концептов. Исключение составляют круглые, текстовые или квадратные скобки с единственным концептом
Что такое текстовые скобки?
Дальше:
1.1. Единственный концепт в текстовых скобках представляет собой именно сам концепт, игнорируя его синтаксический, семантический и функциональный смысл
.
Значит так, если ты говоришь о каких-то "смыслах" изволь дать точное определение этих самых смыслов. Что такое семантический смысл? А синтаксический? "Подлежащее" — это синтаксический или семантический смысл? А "сказуемое" — функциональный? И потом, уточнение "именно сам" означает, что автор сам не определился, о чём он тут говорит. Здесь могут быть варианты: имя концепта, ссылка на концепт по его имени и т.п. Или он у тебя разворачивается в исходный текст, или ещё что-то. Я могу додумать, но за тебя делать этого не собираюсь.
Ещё бриллиант из следующего абзаца:
1.2. Единственный концепт в квадратных скобках обозначает индекс, имя или ключ, для обращения к вложенным элементам концепта. В частности к элементам группы, массива или коллекции
А чем отличается индекс от имени и от ключа? И снова водопад новых слов: массив, коллекция. А почему нет, скажем, "набора" и "множества"?
И в том же духе по остальному тексту. В третьем разделе есть какое-то упоминание про теговую машину, но что это за зверь такой — не понятно. Тебе трудно скопировать все свои описания в один документ?
Короче, для начала изложи всё по-человечески, т.е. — хотя бы по правилам оформления технической документации (термины, основные определения, и т.п.). На данный момент текст напоминает описание универсального всемогутера, который умеет всё. Продраться-то через твои экзерсисы возможно, но имей уважение к читателю, ага? И потом, шут бы с ним, с уважением, но далеко не факт, что читатель, пробившись сквозь всё это, в итоге поймёт тебя правильно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, batu, Вы писали:
ГВ>>>Всё, в общем-то. Два последних пункта повторить для всех файлов, которые ты хочешь показать. B>>Спасибою Делаю по инструкции здесь
ГВ>Позволю себе вопрос: что это такое? Досужие рассуждения студента-фантаста, испытавшего приступ маниловщины или некое техническое описание?
ГВ>Если второе (я так понимаю, ты предполагаешь, что это оно и есть), то я не понимаю, откуда ты выдёргиваешь термины.
ГВ>
Обычно (и привычно) объединение концептов осуществляется скобками. Собственно для этого скобки и придумали.
ГВ>Was ist концепт? Что это такое?
Что такое концепт изложено в старттопике.
ГВ>Потом, ты сходу вводишь кучу разновидностей скобок (сиречь — группировок), постоянно ссылаясь на некое "выполнение" концептов, но при этом пропущено объяснение того, что же такое это самое выполнение. В смысле, сама модель вычислительной среды у тебя отсутствует. Что, за чем, кем и когда выполняется? Ну не с неба же оно всё берётся!
Не с неба. Алгоритм виртуальной машины я еще не выложил потому что не все основы изложил. Но в старт топике указал что концепт-субъект имеет программу которая и запускается при выполнении концепта-объекта. Т.е. концептов порожденных непосредственно классом Concept.
Ну, и раздел 3. Там более подробно.
ГВ>Вот это вообще десять:
Любой концепт может представлять собой как императивную сущность, так и логическую
ГВ>Что это такое: императивная сущность? А логическая?
До этого еще рано. Но счел нужным указать на будущее. Концепты имеют не только императивное представление но и логическое. Как в Прологе. И при запуска целевого выражения (это термин из пролога) запускается так же как и в Прологе интерпретация (термин тоже из логического программирования. В императивной парадигме этот термин имеет другое значение)
ГВ>То есть уже получается так, что прежде, чем понять написанное даже в первом разделе нужно прочесть всё с начала до конца, плюс по диагонали и не забыть сделать конспект. Ты издеваешься, что ли?
К сожалению, нет. Я много раз компоновал текст. Ничего не могу поделать. Не получается так что б по порядку было все определено. ГВ>Добавим сюда путаницу. Раздел 1 вводит термины: круглые, фигурные, квадратные, именные, перечислимые, лексические, метареализации (это всё были скобки). Хорошо, пусть так. Раздел 2:
1. В скобках объединено один, и более концептов. Это непосредственно группирование концептов. Исключение составляют круглые, текстовые или квадратные скобки с единственным концептом
ГВ>Что такое текстовые скобки?
Во введении при определении перечислимых скобок предпоследняя фраза следующая:
"По умолчанию содержит класс перечислимых концептов, содержащихся в текущем алфавите (по этой причине иногда будем называть эту группу текстовой)."
Надо бы добавить что и скобки иногда будем называть текстовыми?
ГВ>Дальше:
1.1. Единственный концепт в текстовых скобках представляет собой именно сам концепт, игнорируя его синтаксический, семантический и функциональный смысл
.
ГВ>Значит так, если ты говоришь о каких-то "смыслах" изволь дать точное определение этих самых смыслов. Что такое семантический смысл? А синтаксический? "Подлежащее" — это синтаксический или семантический смысл? А "сказуемое" — функциональный? И потом, уточнение "именно сам" означает, что автор сам не определился, о чём он тут говорит. Здесь могут быть варианты: имя концепта, ссылка на концепт по его имени и т.п. Или он у тебя разворачивается в исходный текст, или ещё что-то. Я могу додумать, но за тебя делать этого не собираюсь.
Точное не приведу. Но суть попробую. Хотя это тоже впереди паровоза. Но что делать. Что б не объяснять сейчас все приведу несколько примеров.
Текст и буквы это тоже концепты. И "Перевод строки" это не буква, а можно сказать событие. Но это сейчас не важно. Важно то, что "Перевод строки" тоже знак (ну и концепт само собой). Так этот знак в текстовых скобках не приводит к переводу строки. Здесь опять мы пропустим две важные вещи как выполняется функциональная часть концепта "Перевод строки" и как определяется. Это важно, но пока достаточно того что уже сказано. Отключается функциональный смысл.
Вот у нас знак (не важно какой) обозначает комментарий. Как отключить его синтаксический смысл (обозначать комментарий)? Да очень просто. Взять его (единственного) в текстовые скобки.
Дело в том что к ЛЮБОМУ концепту при создании мы можем добавить новые свойства (плюс к тем что в классе), новые методы и новые события (это реализация называется). Эти события могут обрабатываться процедурами. В общем, если концепт взят в текстовые скобки, то все что мы ему доопределили не выполняется.
ГВ>Ещё бриллиант из следующего абзаца:
1.2. Единственный концепт в квадратных скобках обозначает индекс, имя или ключ, для обращения к вложенным элементам концепта. В частности к элементам группы, массива или коллекции
ГВ>А чем отличается индекс от имени и от ключа?
Можно сказать ничем не отличается. То дураки дали разные названия. ГВ> И снова водопад новых слов: массив, коллекция. А почему нет, скажем, "набора" и "множества"?
Добавь. И любое пользовательское объединение...
ГВ>И в том же духе по остальному тексту. В третьем разделе есть какое-то упоминание про теговую машину, но что это за зверь такой — не понятно. Тебе трудно скопировать все свои описания в один документ?
ГВ>Короче, для начала изложи всё по-человечески, т.е. — хотя бы по правилам оформления технической документации (термины, основные определения, и т.п.). На данный момент текст напоминает описание универсального всемогутера, который умеет всё. Продраться-то через твои экзерсисы возможно, но имей уважение к читателю, ага? И потом, шут бы с ним, с уважением, но далеко не факт, что читатель, пробившись сквозь всё это, в итоге поймёт тебя правильно.
Просто поверь, я старался. А как получится насчет это ж и от читателя зависит. И вообще делайте больше замечаний. Буду исправлять. Заранее извиняюсь если так что... Но я ж здесь
Обычно (и привычно) объединение концептов осуществляется скобками. Собственно для этого скобки и придумали.
ГВ>>Was ist концепт? Что это такое? B>Что такое концепт изложено в старттопике.
Эммм... А я-то думал, что старттопик — это только аннотация к тексту, а не составляющая.
ГВ>>Потом, ты сходу вводишь кучу разновидностей скобок (сиречь — группировок), постоянно ссылаясь на некое "выполнение" концептов, но при этом пропущено объяснение того, что же такое это самое выполнение. В смысле, сама модель вычислительной среды у тебя отсутствует. Что, за чем, кем и когда выполняется? Ну не с неба же оно всё берётся! B>Не с неба. Алгоритм виртуальной машины я еще не выложил потому что не все основы изложил. Но в старт топике указал что концепт-субъект имеет программу которая и запускается при выполнении концепта-объекта. Т.е. концептов порожденных непосредственно классом Concept. B>Ну, и раздел 3. Там более подробно.
Не пойдёт, давай цельное изложение. Ты вообще для чего всё это пишешь? Для того, чтобы читали? Или просто ради mind dump? Если второе, то извини, продолжать дискуссию не вижу смысла.
ГВ>>Вот это вообще десять:
Любой концепт может представлять собой как императивную сущность, так и логическую
ГВ>>Что это такое: императивная сущность? А логическая? B>До этого еще рано. Но счел нужным указать на будущее. Концепты имеют не только императивное представление но и логическое. Как в Прологе. И при запуска целевого выражения (это термин из пролога) запускается так же как и в Прологе интерпретация (термин тоже из логического программирования. В императивной парадигме этот термин имеет другое значение)
В Прологе не интерпретация, а машина перебора. Кстати, как раз поэтому Пролог может быть и компилируемым. Короче, посмотри первоисточники.
ГВ>>То есть уже получается так, что прежде, чем понять написанное даже в первом разделе нужно прочесть всё с начала до конца, плюс по диагонали и не забыть сделать конспект. Ты издеваешься, что ли? B>К сожалению, нет. Я много раз компоновал текст. Ничего не могу поделать. Не получается так что б по порядку было все определено.
Значит, изъян где-то в самом излагаемом предмете. Это очень надёжный диагностический признак.
ГВ>>Добавим сюда путаницу. Раздел 1 вводит термины: круглые, фигурные, квадратные, именные, перечислимые, лексические, метареализации (это всё были скобки). Хорошо, пусть так. Раздел 2:
1. В скобках объединено один, и более концептов. Это непосредственно группирование концептов. Исключение составляют круглые, текстовые или квадратные скобки с единственным концептом
ГВ>>Что такое текстовые скобки? B>Во введении при определении перечислимых скобок предпоследняя фраза следующая: B>"По умолчанию содержит класс перечислимых концептов, содержащихся в текущем алфавите (по этой причине иногда будем называть эту группу текстовой)." B>Надо бы добавить что и скобки иногда будем называть текстовыми?
Обязательно. Иначе ты сбиваешь читателя с толку.
ГВ>>Дальше:
1.1. Единственный концепт в текстовых скобках представляет собой именно сам концепт, игнорируя его синтаксический, семантический и функциональный смысл
.
ГВ>>Значит так, если ты говоришь о каких-то "смыслах" изволь дать точное определение этих самых смыслов. Что такое семантический смысл? А синтаксический? "Подлежащее" — это синтаксический или семантический смысл? А "сказуемое" — функциональный? И потом, уточнение "именно сам" означает, что автор сам не определился, о чём он тут говорит. Здесь могут быть варианты: имя концепта, ссылка на концепт по его имени и т.п. Или он у тебя разворачивается в исходный текст, или ещё что-то. Я могу додумать, но за тебя делать этого не собираюсь. B>Точное не приведу. Но суть попробую. Хотя это тоже впереди паровоза. Но что делать. Что б не объяснять сейчас все приведу несколько примеров.
Отказать. Если не можешь объяснить точно — не объясняй вообще. Скажи: "пока не знаю".
B>Текст и буквы это тоже концепты. И "Перевод строки" это не буква, а можно сказать событие.
А можно сказать — глокая куздра. Тоже ведь так можно сказать?
B>Но это сейчас не важно.
Если не важно, зачем об этом говорить? Многословие — зло. Тем более в тексте, подобном твоему.
B>Важно то, что "Перевод строки" тоже знак (ну и концепт само собой).
Это концепт типа "знак" или "знак" типа "имя концепта"? Кто на ком стоял?
B>Так этот знак в текстовых скобках не приводит к переводу строки. Здесь опять мы пропустим две важные вещи как выполняется функциональная часть концепта "Перевод строки" и как определяется. Это важно, но пока достаточно того что уже сказано. Отключается функциональный смысл.
Есть корректный термин вместо твоего "функционального смысла": выполнение программы, ассоциированной с концептом. Для примера описания схожей функциональности см. функции QUOTE, EVAL, APPLY в Lisp.
B>Вот у нас знак (не важно какой) обозначает комментарий. Как отключить его синтаксический смысл (обозначать комментарий)? Да очень просто. Взять его (единственного) в текстовые скобки.
Забудь про слово "смысл". Вообще. Это всё для вольного пересказа. Смысл в твоём случае должен иметь конкретное наполнение — выполнение, распознавание, ещё что-то. Вот только об этом наполнении и говори.
B>Дело в том что к ЛЮБОМУ концепту при создании мы можем добавить новые свойства (плюс к тем что в классе), новые методы и новые события (это реализация называется).
О, как. "Дело в том"! Ты ещё не поставил неявного но единственного вопроса, чтобы огорошивать читателя нежданным открытием. Пока что у читателя возникает туева хуча вопросов совершенно отвлечённых вопросов.
B>Эти события могут обрабатываться процедурами. В общем, если концепт взят в текстовые скобки, то все что мы ему доопределили не выполняется.
А то, что было определено заранее (кстати, где?) — выполняется? А что мы тогда отключаем?
Бр-р-р... Так, давай по-порядку. В качестве опорной точки выберем нечто привычное и неизменное. Как концепт представляется в памяти машины? Структура, что куда указывает, где какие ссылки, где словари и как реализованы, и всё такое.
ГВ>>Ещё бриллиант из следующего абзаца:
1.2. Единственный концепт в квадратных скобках обозначает индекс, имя или ключ, для обращения к вложенным элементам концепта. В частности к элементам группы, массива или коллекции
ГВ>>А чем отличается индекс от имени и от ключа? B>Можно сказать ничем не отличается. То дураки дали разные названия.
Нашему бы теляти...
ГВ>> И снова водопад новых слов: массив, коллекция. А почему нет, скажем, "набора" и "множества"? B>Добавь. И любое пользовательское объединение...
Ещё лучше...
ГВ>>И в том же духе по остальному тексту. В третьем разделе есть какое-то упоминание про теговую машину, но что это за зверь такой — не понятно. Тебе трудно скопировать все свои описания в один документ?
ГВ>>Короче, для начала изложи всё по-человечески, т.е. — хотя бы по правилам оформления технической документации (термины, основные определения, и т.п.). На данный момент текст напоминает описание универсального всемогутера, который умеет всё. Продраться-то через твои экзерсисы возможно, но имей уважение к читателю, ага? И потом, шут бы с ним, с уважением, но далеко не факт, что читатель, пробившись сквозь всё это, в итоге поймёт тебя правильно.
B>Просто поверь, я старался. А как получится насчет это ж и от читателя зависит. И вообще делайте больше замечаний. Буду исправлять. Заранее извиняюсь если так что... Но я ж здесь
Да я верю, что старался. Только тут не ПКМ, старание в зачёт не идёт, тем более, что ты уже не первый год народ тут долбишь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
B>>Ну, и раздел 3. Там более подробно.
ГВ>Не пойдёт, давай цельное изложение. Ты вообще для чего всё это пишешь? Для того, чтобы читали? Или просто ради mind dump? Если второе, то извини, продолжать дискуссию не вижу смысла.
Давай скушаем то, что подано. Я понимаю что не просто.
B>>До этого еще рано. Но счел нужным указать на будущее. Концепты имеют не только императивное представление но и логическое. Как в Прологе. И при запуска целевого выражения (это термин из пролога) запускается так же как и в Прологе интерпретация (термин тоже из логического программирования. В императивной парадигме этот термин имеет другое значение)
ГВ>В Прологе не интерпретация, а машина перебора. Кстати, как раз поэтому Пролог может быть и компилируемым. Короче, посмотри первоисточники.
Вот часть моих первоисточников.
Альфред Тарский «Введение в логику и методологию дедуктивных наук.»
Стр. 167. Раздел 37. Модель и интерпретация дедуктивной теории.
К. Хоггер «Введение в логическое программирование.»
Стр. 57. Раздел 2. Процедурная интерпретация.
С. Клини 1957. «Введение в математику.»
Стр 125. Раздел 30. Разрешающая процедура. Интерпретация.
Я же написал что этот термин "Интерпретация" не в привычном для программистов смысле, а в том что в логическом программировании.
B>>К сожалению, нет. Я много раз компоновал текст. Ничего не могу поделать. Не получается так что б по порядку было все определено. ГВ>Значит, изъян где-то в самом излагаемом предмете. Это очень надёжный диагностический признак.
Не факт. Просто читая литературу по привычному программированию не обращаешь внимание на вроде знакомые термины. А здесь все по другому и буквы и строки.. Так я еще больше запутаю. Просто поверь.
B>>Во введении при определении перечислимых скобок предпоследняя фраза следующая: B>>"По умолчанию содержит класс перечислимых концептов, содержащихся в текущем алфавите (по этой причине иногда будем называть эту группу текстовой)." B>>Надо бы добавить что и скобки иногда будем называть текстовыми?
ГВ>Обязательно. Иначе ты сбиваешь читателя с толку.
Логично. Исправляю "по этой причине иногда будем называть эту группу текстовой" на "по этой причине иногда будем называть эту группу текстовой, а скобки текстовыми"
ГВ>>>Дальше:
1.1. Единственный концепт в текстовых скобках представляет собой именно сам концепт, игнорируя его синтаксический, семантический и функциональный смысл
.
ГВ>>>Значит так, если ты говоришь о каких-то "смыслах" изволь дать точное определение этих самых смыслов. Что такое семантический смысл? А синтаксический? "Подлежащее" — это синтаксический или семантический смысл? А "сказуемое" — функциональный? И потом, уточнение "именно сам" означает, что автор сам не определился, о чём он тут говорит. Здесь могут быть варианты: имя концепта, ссылка на концепт по его имени и т.п. Или он у тебя разворачивается в исходный текст, или ещё что-то. Я могу додумать, но за тебя делать этого не собираюсь. B>>Точное не приведу. Но суть попробую. Хотя это тоже впереди паровоза. Но что делать. Что б не объяснять сейчас все приведу несколько примеров.
ГВ>Отказать. Если не можешь объяснить точно — не объясняй вообще. Скажи: "пока не знаю".
B>>Текст и буквы это тоже концепты. И "Перевод строки" это не буква, а можно сказать событие.
ГВ>А можно сказать — глокая куздра. Тоже ведь так можно сказать?
B>>Но это сейчас не важно.
ГВ>Если не важно, зачем об этом говорить? Многословие — зло. Тем более в тексте, подобном твоему.
Ты ж спросил. Вот и пришлось говорить. Я просил пропустить пока.
ГВ>Есть корректный термин вместо твоего "функционального смысла": выполнение программы, ассоциированной с концептом. Для примера описания схожей функциональности см. функции QUOTE, EVAL, APPLY в Lisp.
B>>Вот у нас знак (не важно какой) обозначает комментарий. Как отключить его синтаксический смысл (обозначать комментарий)? Да очень просто. Взять его (единственного) в текстовые скобки.
ГВ>Забудь про слово "смысл". Вообще. Это всё для вольного пересказа. Смысл в твоём случае должен иметь конкретное наполнение — выполнение, распознавание, ещё что-то. Вот только об этом наполнении и говори.
К сожалению, и "выполнение" тоже не катит потому как будет видно дальше выполнение происходит в несколько этапов.
За выполнение программы, ассоциированной с концептом понравилось. Только надо что-то покороче придумать.
ГВ>А то, что было определено заранее (кстати, где?) — выполняется? А что мы тогда отключаем?
Отключаем обработку событий для единственного концепта в текстовых скобках. А может и для всех концептов в текстовых скобках. Или только для алфавита так сделать. Есть мысли. Это надо обдумать. Но для единственного точно.
ГВ>Бр-р-р... Так, давай по-порядку. В качестве опорной точки выберем нечто привычное и неизменное. Как концепт представляется в памяти машины? Структура, что куда указывает, где какие ссылки, где словари и как реализованы, и всё такое.
Хороший вопрос. Концепт располагается непосредственно непрерывно в памяти (для того он и размер имеет). А выполнять может и создание динамических данных.
Так концепт Form А { Size:=20;120) Представляет собой форму и может применяться для создания формы типа в браузере (у нас нет браузеров, программ и т.п. все загрузочные единицы имеют один формат документа ( Концепт Document). А применение концепта New к этой форме (New Form А { Size:=20;120) )создает эту же форму динамически.
ГВ>>>А чем отличается индекс от имени и от ключа? B>>Можно сказать ничем не отличается. То дураки дали разные названия.
ГВ>Нашему бы теляти...
А чего б и нет?
ГВ>Да я верю, что старался. Только тут не ПКМ, старание в зачёт не идёт, тем более, что ты уже не первый год народ тут долбишь.
Лукавишь. С месяц поболтали и я ушел на год трудится. Доставать это не мое. Не интересно не читай.
Здравствуйте, batu, Вы писали:
B>>>Ну, и раздел 3. Там более подробно. ГВ>>Не пойдёт, давай цельное изложение. Ты вообще для чего всё это пишешь? Для того, чтобы читали? Или просто ради mind dump? Если второе, то извини, продолжать дискуссию не вижу смысла. B>Давай скушаем то, что подано. Я понимаю что не просто.
Давай выплюнем недоброкачественное.
B>>>До этого еще рано. Но счел нужным указать на будущее. Концепты имеют не только императивное представление но и логическое. Как в Прологе. И при запуска целевого выражения (это термин из пролога) запускается так же как и в Прологе интерпретация (термин тоже из логического программирования. В императивной парадигме этот термин имеет другое значение)
ГВ>>В Прологе не интерпретация, а машина перебора. Кстати, как раз поэтому Пролог может быть и компилируемым. Короче, посмотри первоисточники. B>Вот часть моих первоисточников. B>Альфред Тарский «Введение в логику и методологию дедуктивных наук.» B>Стр. 167. Раздел 37. Модель и интерпретация дедуктивной теории. B>К. Хоггер «Введение в логическое программирование.» B>Стр. 57. Раздел 2. Процедурная интерпретация. B>С. Клини 1957. «Введение в математику.» B>Стр 125. Раздел 30. Разрешающая процедура. Интерпретация.
B>Я же написал что этот термин "Интерпретация" не в привычном для программистов смысле, а в том что в логическом программировании.
Давай так. Я из тебя не буду вытягивать слово за словом, а ты всё это внесёшь в одну бумагу. Пусть она окажется на 100 страниц — не страшно. Главное, чтобы изложение было последовательным, полным и непротиворечивым.
B>>>К сожалению, нет. Я много раз компоновал текст. Ничего не могу поделать. Не получается так что б по порядку было все определено. ГВ>>Значит, изъян где-то в самом излагаемом предмете. Это очень надёжный диагностический признак. B>Не факт. Просто читая литературу по привычному программированию не обращаешь внимание на вроде знакомые термины. А здесь все по другому и буквы и строки.. Так я еще больше запутаю. Просто поверь.
Да я уж не то, что поверил, а прямо убедился в этой самой путанице.
B>>>Во введении при определении перечислимых скобок предпоследняя фраза следующая: B>>>"По умолчанию содержит класс перечислимых концептов, содержащихся в текущем алфавите (по этой причине иногда будем называть эту группу текстовой)." B>>>Надо бы добавить что и скобки иногда будем называть текстовыми?
ГВ>>Обязательно. Иначе ты сбиваешь читателя с толку. B>Логично. Исправляю "по этой причине иногда будем называть эту группу текстовой" на "по этой причине иногда будем называть эту группу текстовой, а скобки текстовыми"
Угу, хорошо. Только теперь, давай, остальные нестыковки ты найдёшь в своём тексте сам. Ручаюсь, это очень полезная практика.
ГВ>>>>Дальше:
1.1. Единственный концепт в текстовых скобках представляет собой именно сам концепт, игнорируя его синтаксический, семантический и функциональный смысл
. ГВ>>>>Значит так, если ты говоришь о каких-то "смыслах" изволь дать точное определение этих самых смыслов. Что такое семантический смысл? А синтаксический? "Подлежащее" — это синтаксический или семантический смысл? А "сказуемое" — функциональный? И потом, уточнение "именно сам" означает, что автор сам не определился, о чём он тут говорит. Здесь могут быть варианты: имя концепта, ссылка на концепт по его имени и т.п. Или он у тебя разворачивается в исходный текст, или ещё что-то. Я могу додумать, но за тебя делать этого не собираюсь. B>>>Точное не приведу. Но суть попробую. Хотя это тоже впереди паровоза. Но что делать. Что б не объяснять сейчас все приведу несколько примеров.
ГВ>>Отказать. Если не можешь объяснить точно — не объясняй вообще. Скажи: "пока не знаю".
B>>>Текст и буквы это тоже концепты. И "Перевод строки" это не буква, а можно сказать событие.
ГВ>>А можно сказать — глокая куздра. Тоже ведь так можно сказать? B>>>Но это сейчас не важно. ГВ>>Если не важно, зачем об этом говорить? Многословие — зло. Тем более в тексте, подобном твоему. B>Ты ж спросил. Вот и пришлось говорить. Я просил пропустить пока.
А, ясно. То есть замечание в скобках с ремаркой "это не важно" — это ответ на мою просьбу. Мда...
ГВ>>Есть корректный термин вместо твоего "функционального смысла": выполнение программы, ассоциированной с концептом. Для примера описания схожей функциональности см. функции QUOTE, EVAL, APPLY в Lisp.
B>>>Вот у нас знак (не важно какой) обозначает комментарий. Как отключить его синтаксический смысл (обозначать комментарий)? Да очень просто. Взять его (единственного) в текстовые скобки.
ГВ>>Забудь про слово "смысл". Вообще. Это всё для вольного пересказа. Смысл в твоём случае должен иметь конкретное наполнение — выполнение, распознавание, ещё что-то. Вот только об этом наполнении и говори. B>К сожалению, и "выполнение" тоже не катит потому как будет видно дальше выполнение происходит в несколько этапов.
Я не знаю, что катит, а что — нет. Это твоя обязанность — изложить всё внятно и без двусмысленностей. Мне остаётся только гадать.
B>За выполнение программы, ассоциированной с концептом понравилось. Только надо что-то покороче придумать.
Дарю.
ГВ>>А то, что было определено заранее (кстати, где?) — выполняется? А что мы тогда отключаем? B>Отключаем обработку событий для единственного концепта в текстовых скобках. А может и для всех концептов в текстовых скобках. Или только для алфавита так сделать. Есть мысли. Это надо обдумать. Но для единственного точно.
Какие ещё, к дьяволу, "может быть"? Либо да, либо — нет, либо одно — либо другое. Может быть, не может быть... Ты предлагаешь читателю заниматься гаданием на кофейной гуще?
ГВ>>Бр-р-р... Так, давай по-порядку. В качестве опорной точки выберем нечто привычное и неизменное. Как концепт представляется в памяти машины? Структура, что куда указывает, где какие ссылки, где словари и как реализованы, и всё такое. B>Хороший вопрос. Концепт располагается непосредственно непрерывно в памяти (для того он и размер имеет). А выполнять может и создание динамических данных. B>Так концепт Form А { Size:=20;120) Представляет собой форму и может применяться для создания формы типа в браузере (у нас нет браузеров, программ и т.п. все загрузочные единицы имеют один формат документа ( Концепт Document). А применение концепта New к этой форме (New Form А { Size:=20;120) )создает эту же форму динамически.
Разные открывающая и закрывающая скобка — это так задумано или опечатка?
ГВ>>>>А чем отличается индекс от имени и от ключа? B>>>Можно сказать ничем не отличается. То дураки дали разные названия. ГВ>>Нашему бы теляти... B>А чего б и нет?
Да не, ничего. Только не надорвись.
ГВ>>Да я верю, что старался. Только тут не ПКМ, старание в зачёт не идёт, тем более, что ты уже не первый год народ тут долбишь. B>Лукавишь. С месяц поболтали и я ушел на год трудится. Доставать это не мое. Не интересно не читай.
Да, всего лишь второй. Не, всё, больше не читаю. Разве что ты переоформишь свои измышления во что-то более удобоваримое. Свистни, когда управишься — постараюсь выступить пруфридером.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
B>>Хороший вопрос. Концепт располагается непосредственно непрерывно в памяти (для того он и размер имеет). А выполнять может и создание динамических данных. B>>Так концепт Form А { Size:=20;120} Представляет собой форму и может применяться для создания формы типа в браузере (у нас нет браузеров, программ и т.п. все загрузочные единицы имеют один формат документа ( Концепт Document). А применение концепта New к этой форме (New Form А { Size:=20;120} )создает эту же форму динамически.
ГВ>Разные открывающая и закрывающая скобка — это так задумано или опечатка?
Опечатка.
ГВ>>>Да я верю, что старался. Только тут не ПКМ, старание в зачёт не идёт, тем более, что ты уже не первый год народ тут долбишь. B>>Лукавишь. С месяц поболтали и я ушел на год трудится. Доставать это не мое. Не интересно не читай.
ГВ>Да, всего лишь второй. Не, всё, больше не читаю. Разве что ты переоформишь свои измышления во что-то более удобоваримое. Свистни, когда управишься — постараюсь выступить пруфридером.
Ок.
ГВ>Не пойдёт, давай цельное изложение. Ты вообще для чего всё это пишешь? Для того, чтобы читали? Или просто ради mind dump? Если второе, то извини, продолжать дискуссию не вижу смысла.
Я переспал с этим вопросом.
А, действительно, зачем я все это пишу?
Что б поделится своими мыслями. Я не студент-фантаст. Начинал еще в начале 80-х работая на голом железе и дырочки в перфокартах и перфолентах ручками вырезал. Технологии программирования развивались очень быстро. Это, конечно, хорошо. Но в этой гонке многие старые решения не пересматривались, а наследовались как данное и почти святое. В первую очередь это касается кодировки алфавита и методов редактирования. Ведь он тупо скопирован с печатных машинок. С появлением графических мониторов и объектной парадигмы это ж полный бред. Пробел не символ, перевод строки и вообще коды редактирования (форматирования) не символы вообще, а события. Т.е. другой класс объектов. И вообще что такое символ? Значение или объект? И если объект то каким боком там операция сравнения и сортировок? И откуда код символа? Это глупые вопросы для того кто привык к тому как есть. А логично это или нет уже никого не волнует. Получи строковый тип данных и все тут. А почему он отдельный и такой специфический? Может это не правильно?
Потом как появились расширения файлов. Когда были одни программы и комп не применялся для редактирования (текстовых редакторов вообще не было) так и проблем таких не было. И вдруг проявились ассемблеры и текстовые файлы (само значение слова файлы не так давно появилось). Их надо было как то отличать и тут Эврика! Та в имени файла через точку три буквы поставим и все решение. Так и тянем до сих пор это "мудрое" решение. А что можно формат файла (и все свойства файла) содержать в самом файле тогда эта мысль не могла появится.
Прерывания — суть события. Правда и события можно и нужно усовершенствовать. Что и предлагаю.
Загрузку, хранение, распределение памяти, сборка мусора, протокол передачи можно значительно упростить если все имеет единую структуру.
Трансляция, глобализация ставит новые задачи и подходы.
В общем, я предлагаю решение древних проблем и новые подходы к программированию надо только поменять подход.
И, конечно, понимаю что сам я всего задуманного не сделаю. И не только потому что большой объем работы, а потому что все это необходимо прокрутить в мозгах, обсудить, попробовать реализовать. Исправить недостатки и снова обсудить и снова реализовать. Короче у меня уже версий 5 было. А обсуждать не с кем. Да и бабки нужны.
Вот потому и пишу здесь. Матюкайте
Здравствуйте, batu, Вы писали:
B>Естественно весь материал переработан, потому решил создать новую ветку где буду отвечать на вопросы и скидывать доп. материалы. Если, конечно, будет интерес. B>Всем спасибо!
Если я правильно понял, то все это похоже на принципы DSL.
1. Есть у нас некий алфавит (множество концептов). Используя (объединяя) их мы можем написать что-то полезное. Например, все слова некоторого языка программирования (if, for, return) мы можем рассматривать как концепты. Тогда объединяя эти концепты мы получим программу на данном языке программирования.
2. Но можно также добавлять новые концепты, выражая их через другие концепты. Т.е. придумать некий DSL для описания некой предметной области. Например придумать язык описание юнит тестов. Но система должна знать как трактовать данный концепт, поэтому его семантика должна быть каким-то образом описана (правила для системы).
3. Концепты из п.1 (if, for, return) могли быть реализованы на основе каких-то других, более примитивных концептах, например, на концептах виртуальной машины. Те, на еще более примитивных концептах. Значит должны быть какие-то базовые концепты из которых строится все-все, а также правила их объединения.
4. Идея, как я понимаю, и состоит в том, чтобы придумать:
— минимальный набор базовых концептов
— правила объединения концептов синтаксис
— правила задания значения концептов (семантика)
— возможно, правила взаимодействия концептов (это от себя, про это речь еще не шла)
В этом плате система похожа на LISP. В лиспе есть всего-лишь одна основная операция — группирование в скобки. Объединяя значения в скобки мы можем моделировать сущность любой сложности. При этом последовательные значения в скобках мы можем трактовать как угодно (как значения, как программу на языке C, как ключевые слова DSL и т.д.).
В этом случае это действительно может стать базой для любых языков программирования, для любых форматов данных. Например, мы можем реализовать концепты, соответствующие XML. Потом использовать эти концепты для построения некоторого документа XML. Выглядеть это будет именно как XML, но по сути будет объединение концептов.
В то же время рассматриваемая система не является языком программирования в привычном смысле. Но в рамках данной системы можно реализовать любой язык программирования, реализовав некоторые концепты для программирования на таком языке и описав правила выполнения программы на таком языке. Тогда написав программу на таком языке система (Лада?) будет рассматривать текст программы как набор концептов, выполнять правила, описанные в этих концептах, и в конечном итоге выполнять программу (или делать что-то другое?).
Повторюсь, это то, как я понял. Прошу меня поправить.
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, batu, Вы писали:
B>>Естественно весь материал переработан, потому решил создать новую ветку где буду отвечать на вопросы и скидывать доп. материалы. Если, конечно, будет интерес. B>>Всем спасибо!
Б>Если я правильно понял, то все это похоже на принципы DSL.
Б>1. Есть у нас некий алфавит (множество концептов). Используя (объединяя) их мы можем написать что-то полезное. Например, все слова некоторого языка программирования (if, for, return) мы можем рассматривать как концепты. Тогда объединяя эти концепты мы получим программу на данном языке программирования.
Где-то так. Не только программу. Любой документ. Программа это частный случай документа.
Б>2. Но можно также добавлять новые концепты, выражая их через другие концепты. Т.е. придумать некий DSL для описания некой предметной области. Например придумать язык описание юнит тестов. Но система должна знать как трактовать данный концепт, поэтому его семантика должна быть каким-то образом описана (правила для системы).
Можем. есть и синтаксис и наследование концептов. И потом концепт класса Concept создает другие концепты, в частности концепт Class, который в свою очередь создает объекты. Есть и язык (даже два. один теговый, второй высокого уровня). И этот язык типа метаязык который может создавать и грамматики. Причем синтаксис остается общим.
Б>3. Концепты из п.1 (if, for, return) могли быть реализованы на основе каких-то других, более примитивных концептах, например, на концептах виртуальной машины. Те, на еще более примитивных концептах. Значит должны быть какие-то базовые концепты из которых строится все-все, а также правила их объединения.
Так куда уже примитивнее чем If Думаю их можно запрограммировать и в ассемблере или C++. Хотя у меня концепт If без секции Else. Секция Else самостоятельный концепт и включается в концепты If, Select и другие срабатывая при значении свойства Result=False
Базовых концептов 5, я их перечислил. Кроме того правила группирования здесь (т.е. объединения).
Б>4. Идея, как я понимаю, и состоит в том, чтобы придумать: Б>- минимальный набор базовых концептов Б>- правила объединения концептов синтаксис Б>- правила задания значения концептов (семантика) Б>- возможно, правила взаимодействия концептов (это от себя, про это речь еще не шла)
Совершенно верно.
Б>В этом плате система похожа на LISP. В лиспе есть всего-лишь одна основная операция — группирование в скобки. Объединяя значения в скобки мы можем моделировать сущность любой сложности. При этом последовательные значения в скобках мы можем трактовать как угодно (как значения, как программу на языке C, как ключевые слова DSL и т.д.).
Не как угодно, но в принципе правильно.
Б>В этом случае это действительно может стать базой для любых языков программирования, для любых форматов данных. Например, мы можем реализовать концепты, соответствующие XML. Потом использовать эти концепты для построения некоторого документа XML. Выглядеть это будет именно как XML, но по сути будет объединение концептов.
Не для любых форматов. Формат необходимо блюсти. Вместо XML я предложил свой теговый язык. У XML есть большой недостаток. Он меняет среду в которой работает. Так, например, первый тег должен обязательно указать шрифты и т.д.. И действие этого тега изменяет среду, до тех пор пока следующий ее не изменит еще раз. Правильнее область действия тега распространить только на самого себя. Т.е. то на что он действует должно находиться внутри тега. Но тут возникает проблема, что мы не можем оттранслировать и выполнить тег пока он полностью не закончился. В этом и хитрость и в загрузке и при выполнении, что в виртуальной машине сначала выполняются свойства, а потом вложенные теги (концепты)..
Б>В то же время рассматриваемая система не является языком программирования в привычном смысле. Но в рамках данной системы можно реализовать любой язык программирования, реализовав некоторые концепты для программирования на таком языке и описав правила выполнения программы на таком языке. Тогда написав программу на таком языке система (Лада?) будет рассматривать текст программы как набор концептов, выполнять правила, описанные в этих концептах, и в конечном итоге выполнять программу (или делать что-то другое?).
Б>Повторюсь, это то, как я понял. Прошу меня поправить.
Очень близко все понял. На нюансах я бы не стал сейчас акцентировать.
Что происходит с программой? Как она выполняется, т.е. каковы правила исполнения концептов? Это какая-то императивная программа (как С) или некоторое описание, по которому будет построена программа на основе других концептов (концептов стоящих внутри данного концепта, стоящих рядом, стоящих где-то в другом месте документа/программы)?
Зачем введено понятие размер?
Б>>2. Но можно также добавлять новые концепты, выражая их через другие концепты. Т.е. придумать некий DSL для описания некой предметной области. Например придумать язык описание юнит тестов. Но система должна знать как трактовать данный концепт, поэтому его семантика должна быть каким-то образом описана (правила для системы). B>Можем. есть и синтаксис и наследование концептов. И потом концепт класса Concept создает другие концепты, в частности концепт Class, который в свою очередь создает объекты. Есть и язык (даже два. один теговый, второй высокого уровня). И этот язык типа метаязык который может создавать и грамматики. Причем синтаксис остается общим.
Про наследование концептов хотелось бы подробнее узнать.
B>Базовых концептов 5, я их перечислил. Кроме того правила группирования здесь (т.е. объединения).
Этот документ я видел. Но хочется примеров, как из базовых концептов сформировать другой концепт (что-нибудь полезное). Среди базовых концептов нет (if,for,return) — как их реализовать? кто это будет делать? каких использовать (подключать) готовые концепты? Также среди базовых нет концептов для логического программирования, функционального программирования, описания таблиц Excel и т.д. и т.п. Вопросы те же.
Б>>4. Идея, как я понимаю, и состоит в том, чтобы придумать: Б>>- минимальный набор базовых концептов Б>>- правила объединения концептов синтаксис Б>>- правила задания значения концептов (семантика) Б>>- возможно, правила взаимодействия концептов (это от себя, про это речь еще не шла) B>Совершенно верно.
Ну вот и план описания концепции концептного программирование. Добавь введение, цели, систему вычисления и много примеров. Получится более-менее внятное описание.
Б>>В этом плате система похожа на LISP. В лиспе есть всего-лишь одна основная операция — группирование в скобки. Объединяя значения в скобки мы можем моделировать сущность любой сложности. При этом последовательные значения в скобках мы можем трактовать как угодно (как значения, как программу на языке C, как ключевые слова DSL и т.д.). B>Не как угодно, но в принципе правильно.
Почему не как угодно?
B>Не для любых форматов. Формат необходимо блюсти. Вместо XML я предложил свой теговый язык. У XML есть большой недостаток. Он меняет среду в которой работает. Так, например, первый тег должен обязательно указать шрифты и т.д.. И действие этого тега изменяет среду, до тех пор пока следующий ее не изменит еще раз. Правильнее область действия тега распространить только на самого себя. Т.е. то на что он действует должно находиться внутри тега. Но тут возникает проблема, что мы не можем оттранслировать и выполнить тег пока он полностью не закончился. В этом и хитрость и в загрузке и при выполнении, что в виртуальной машине сначала выполняются свойства, а потом вложенные теги (концепты)..
Не понял про теги и теговый язык. Как это все соотносится с концептами?
B>Очень близко все понял. На нюансах я бы не стал сейчас акцентировать.
Если все правильно понял, то можно (нужно) и про нюансы.
Два самых важных вопроса:
1. Описание (идеи) системы исполнения/вычисления/интерпретации концептов
2. Для чего все это нужно? Какие проблемы удастся решить, если ВСЕ что можно будет построено с использованием концептного программирования и концептов? Здесь можно помечтать...
Здравствуйте, Буравчик, Вы писали:
Б>Непонятно почему концепт = (размер, программа).
Концепт имеет следующие обязательные свойства
Таблица 1.1. Обязательные свойства концепта.
Название Доступ Тип Назначение
Name Полный Text Имя концепта.
Class Чтение Word Класс концепта.
Parent Чтение Selector Родительский объект (объект в который вложен текущий).
Child Чтение Concept() Вложенные концепты.
Help Полный Text Справочная информация.
Result Полный Boolean Результат работы. Имеет события Error и Good
Свойство Class, Name и Parameters формируется общим синтаксисом, и доступно только для чтения. Свойство Child и Parent недоступно для изменения и формируется расположением концептов (в тексте). Свойство Child содержит вложенные концепты. Т.е. все объекты, находящиеся в реализации данного объекта за исключением присвоений свойств. Свойство Result является признаком результата выполнения объекта. Этим свойством контролируется выполнение реализаций. Кроме того реализация имеет доступ к этому свойству, и может его изменить своим функционалом. Свойство Help содержит информацию об объекте.
В случае если класс концепта порожден Concept, то вложенные концепты являются программой его реализующей. Т.е создаем концепт For. Повторяю
Концепт For будет выглядеть где-то так.
Concept For
{Property Integer Per=0 ' Переменная цикла со значением по умолчанию=0
Property Integer End ' Значение конца цикла
Per+:=1
IfElse Per<=End { Execute Else Exit Concept For }
}
При трансляции выражения
For I=1 To N {... }
Создается концепт класса For и именем I соответствующими значениями свойств концепта. В таком формате и хранится. Результат трансляции — тоже концепты.
А сам тип Integer возникает из Byte (приблизительно) так
Type Integer
{Dim Byte First
Dim Byte Second
}
Размер, а точнее количество свойств плюс правило по которому вычисляется количество байт содержащихся в концепте и позволяет выполнять манипуляции с концептом. Свопинг, загрузка, передача и т.п..
Для концептов созданых непосредственно
Плюс работа с устройствами тоже унифицируется.
Б>Что происходит с программой? Как она выполняется, т.е. каковы правила исполнения концептов? Это какая-то императивная программа (как С) или некоторое описание, по которому будет построена программа на основе других концептов (концептов стоящих внутри данного концепта, стоящих рядом, стоящих где-то в другом месте документа/программы)?
Виртуальная машина сначала выполняет свойства (о выполнении свойств позже), затем выполняет вложенные концепты подавая их в порядке следования себе на вход. Если концепт непосредственно порожден концептом Concept (а именно такая ситуация возникнет при попадании концепта класса For) то выполняется программа вложенная в концепт класса Concept с именем For. Т.е. концепт-класса For.
Б>Этот документ я видел. Но хочется примеров, как из базовых концептов сформировать другой концепт (что-нибудь полезное). Среди базовых концептов нет (if,for,return) — как их реализовать? кто это будет делать? каких использовать (подключать) готовые концепты? Также среди базовых нет концептов для логического программирования, функционального программирования, описания таблиц Excel и т.д.
Б>Ну вот и план описания концепции концептного программирование. Добавь введение, цели, систему вычисления и много примеров. Получится более-менее внятное описание.
Если б было так просто. Так и делаю, но сначала основные понятия.
B>>Не для любых форматов. Формат необходимо блюсти. Вместо XML я предложил свой теговый язык. У XML есть большой недостаток. Он меняет среду в которой работает. Так, например, первый тег должен обязательно указать шрифты и т.д.. И действие этого тега изменяет среду, до тех пор пока следующий ее не изменит еще раз. Правильнее область действия тега распространить только на самого себя. Т.е. то на что он действует должно находиться внутри тега. Но тут возникает проблема, что мы не можем оттранслировать и выполнить тег пока он полностью не закончился. В этом и хитрость и в загрузке и при выполнении, что в виртуальной машине сначала выполняются свойства, а потом вложенные теги (концепты)..
Б>Не понял про теги и теговый язык. Как это все соотносится с концептами?
Б>Если все правильно понял, то можно (нужно) и про нюансы. Б>Два самых важных вопроса: Б>1. Описание (идеи) системы исполнения/вычисления/интерпретации концептов Б>2. Для чего все это нужно? Какие проблемы удастся решить, если ВСЕ что можно будет построено с использованием концептного программирования и концептов? Здесь можно помечтать...
Ну, например, реальная мультиплатформенность. Все без исключения определяется через концепты нижнего уровня.
Когда я опять вижу все эти Фор, Иф, Цикл, проверки и тп
то понимаю что этот язык полностью опять улетит в говнокод.
Опять для описания чегото нужно будет 100500 циклов, 1005000100 переменных и тд
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
PC_>Когда я опять вижу все эти Фор, Иф, Цикл, проверки и тп PC_>то понимаю что этот язык полностью опять улетит в говнокод. PC_>Опять для описания чегото нужно будет 100500 циклов, 1005000100 переменных и тд
Привет! Рад видеть.
Циклы это конечно. Но вот с ифами есть и свежее.
Во первых чисто синтаксический сахар. Оператор If отдельно, а секция Else отдельно и выполняется в любом концепте если Result=False.
Во вторых оператор If (как и любой концепт) можно объединить в группу.
If
{ Х=0 {...}
X<0 {...} X>= {...}
}
И в эту группу добавить секцию Else.
Во третьих совершенно свежий оператор Swith создающий перечислимое значение из группы операторов If.
Swith I
If
{ Х=0 {...}
X<0 {...} X>= {...}
}
И затем (не обязательно сразу, а в другом месте текста программы) организовать переход по этой переменной на выполнение в соответствующую группу операторов
ExecuteOnSwitch S
{
{A+:=I}
{A-:=I}
{A*:=I}
Else {A:=A^3}
}
Любопытной фишкой является возможность именовать операторы. Тоже согласно общему синтаксису после имени класса концепта может стоять имя концепта. И тогда if -ы в операторе Swith можно именовать и использовать эти имена для именования группы для выполнения. Что очень удобно. Получается типа флага который может принимать несколько значений, а не только False, True. И по которому можно переходить в зависимости от его значения.
Пример именования оператора If
If "проверка на принадлежность комплекту" X=0 {...}
"проверка на принадлежность комплекту" — это имя такое.
И, самое главное. If-ы создают определенные сложности особенно если их много. Так часть If-ов можно убрать из текста используя события.
Так, например, если необходимо проверять на конец текста, можно определить событие "End Text" и избавится от этих проверок в тексте программы переложив этот контроль на процедуру обработки события.
О событиях я писал год назад.
Ориентируйся на язык SQL.
Он конечно нишевый, но показывает как лаконично без багово можно описать "программку" в один запрос,
без всяких переменных циклов ифов и тд.
Вот о таком языке нужно думать.
Чтобы был на три головы выше чем все остальное.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
PC_>Циклы зло. PC_>Ифы зло. PC_>Переменные зло.
PC_>Ориентируйся на язык SQL. PC_>Он конечно нишевый, но показывает как лаконично без багово можно описать "программку" в один запрос, PC_>без всяких переменных циклов ифов и тд.
PC_>Вот о таком языке нужно думать. PC_>Чтобы был на три головы выше чем все остальное.
Будешь смеяться. База данных управление и запросы получаются как часть системы. Ведь хранение концептов одна из основных задач. Там тоже есть любопытные результаты. Одним из главных результатов это то, что "иерархические базы данных" это плод нашего воображения. В природе они не существуют. иерархия возникает как результат нашего отношения к данным. Физическое расположение данных все равно линейное и не зависит от нашего отношения к ним как сейчас, и, тем более, в будущем (это я намекаю что они не нуждаются в нормализации). А так как отношений может быть много именно их и необходимо реализовывать. На практике это означает возможность строить несколько каталогов на одни и те же данные. Ярким примером является проводник. Там папки находятся одна в другой и это не имеет никакой связи с их расположением. Вполне логично иметь несколько каталогов по нашему отношению к документам. Фактически имя такого каталога это имя свойства которым документ обладает, либо это свойство появляется как наше отношение к некоторому множеству документов. А имена папок обычно значения этих свойств. Так первый вариант демонстрирует построение каталога файлов по авторству. Автор присутствует как свойство документа. А второе если будем строить каталог "любимых", "Очень любимых", "Не любимых" фильмов. Ведь в самом файле фильма нет свойства "Любимый". Это свойство появляется как наше отношение к некоторому множеству фильмов.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
PC_>Циклы зло. PC_>Ифы зло. PC_>Переменные зло.
Насчет переменных согласен. Это опять же в глобальном смысле. Но императивное программирование уже из истории не вычеркнешь. Да и из будущего тоже..
Здравствуйте, batu, Вы писали:
B>Будешь смеяться. База данных управление и запросы получаются как часть системы. Ведь хранение концептов одна из основных задач. Там тоже есть любопытные результаты. Одним из главных результатов это то, что "иерархические базы данных" это плод нашего воображения. В природе они не существуют. иерархия возникает как результат нашего отношения к данным. Физическое расположение данных все равно линейное и не зависит от нашего отношения к ним как сейчас, и, тем более, в будущем (это я намекаю что они не нуждаются в нормализации). А так как отношений может быть много именно их и необходимо реализовывать. На практике это означает возможность строить несколько каталогов на одни и те же данные. Ярким примером является проводник. Там папки находятся одна в другой и это не имеет никакой связи с их расположением. Вполне логично иметь несколько каталогов по нашему отношению к документам. Фактически имя такого каталога это имя свойства которым документ обладает, либо это свойство появляется как наше отношение к некоторому множеству документов. А имена папок обычно значения этих свойств. Так первый вариант демонстрирует построение каталога файлов по авторству. Автор присутствует как свойство документа. А второе если будем строить каталог "любимых", "Очень любимых", "Не любимых" фильмов. Ведь в самом файле фильма нет свойства "Любимый". Это свойство появляется как наше отношение к некоторому множеству фильмов.
Все правильно мыслишь, я о этом тоже много думал и понял что ООП в новом языке места нет.
Также как и ты выделил для данных некоторый слой. Они лежат в твоем понимании "линейно" в моем понимании еще более абстрактно "хаотично".
И вот те кто "смотрят" на эти данные интерпретируют их по своему. Не знаю что в данном случаем ты подразумеваешь под концептом,
но в моей теории это теория послойного построения структур на основе распознавания. Тоесть слой за слоем структурируется информация, в зависимости от наложеных "понятий" на этом уровне.
Самый простой пример это пример с фигурами. Определяется понятие точки, которая любые два числа распознает как координаты. Отрезки распознают себя там где есть две точки. Углы там где есть три точки. Прямые углы там где есть три точки и определенное соотношение. Прямоугольники там где есть четыре угла.
В отличии от зашореной ООП вылитой в граните, здесь структура намного более гибкая. Она может расходится и сходится на уровнях, анализируя что на каждом этапе появляется.
На практике это означает что однажды определенное "понятие" сможет применится в любом месте системы. Вообщем везде где есть числа они смогут быть интерпретированы как координаты и появится в этой системе всевозможные фигуры в конечном итоге, которыми можно оперировать.
Так работает мышление человека, на уровне распознавания.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, batu, Вы писали:
PC_>>Циклы зло. PC_>>Ифы зло. PC_>>Переменные зло. B>Насчет переменных согласен. Это опять же в глобальном смысле. Но императивное программирование уже из истории не вычеркнешь. Да и из будущего тоже..
Семантика переменной это изменяемая ячейка памяти компьютера. И операции оперирования с этой ячейкой.
Тоесть это самый самый низкий уровень программирования который плотненько лежит на архитектуре.
Вместе с тем SQL или функциональное программирования уводит нас от такого понятия как "ячейка памяти"\переменная и являются намного более эффективными абстрактными моделями программирования достаточно хорошо оторванными от функционирования железа.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
PC_>но в моей теории это теория послойного построения структур на основе распознавания. Тоесть слой за слоем структурируется информация, в зависимости от наложеных "понятий" на этом уровне. PC_>Самый простой пример это пример с фигурами. Определяется понятие точки, которая любые два числа распознает как координаты. Отрезки распознают себя там где есть две точки. Углы там где есть три точки. Прямые углы там где есть три точки и определенное соотношение. Прямоугольники там где есть четыре угла. PC_>В отличии от зашореной ООП вылитой в граните, здесь структура намного более гибкая. Она может расходится и сходится на уровнях, анализируя что на каждом этапе появляется.
Автор теории за год так и не прикинул, сколько углов даст 1000 точек?
PC_>На практике это означает что однажды определенное "понятие" сможет применится в любом месте системы. Вообщем везде где есть числа они смогут быть интерпретированы как координаты и появится в этой системе всевозможные фигуры в конечном итоге, которыми можно оперировать.
PC_>Так работает мышление человека, на уровне распознавания.
Не обобщай. Не все мыслят брутфорсом.
Здравствуйте, batu, Вы писали:
B>Всем спасибо!
Несколько отвлеченный вопрос, но, я думаю, это будет полезно для понимания. Решение какой практической задачи привело к созданию это парадигмы? То есть от какой реальной проблемы мысль полетела
PC_>Все правильно мыслишь, я о этом тоже много думал и понял что ООП в новом языке места нет.
Ну, почему нет? Ноги по любому растут оттуда. А недостатков меньше. Хотя не без них. PC_>Также как и ты выделил для данных некоторый слой. Они лежат в твоем понимании "линейно" в моем понимании еще более абстрактно "хаотично". PC_>И вот те кто "смотрят" на эти данные интерпретируют их по своему. Не знаю что в данном случаем ты подразумеваешь под концептом,
Размер, свойства и программу его реализующую. Кроме того, логическое определение. Высказывание. Как в Прологе. PC_>но в моей теории это теория послойного построения структур на основе распознавания. То есть слой за слоем структурируется информация, в зависимости от наложеных "понятий" на этом уровне. PC_>Самый простой пример это пример с фигурами. Определяется понятие точки, которая любые два числа распознает как координаты. Отрезки распознают себя там где есть две точки. Углы там где есть три точки. Прямые углы там где есть три точки и определенное соотношение. Прямоугольники там где есть четыре угла.
1. Не любые две точки есть координаты. Нужно еще что-то однозначно определяющее с чем имеем дело. У меня это программа и высказывание.
2. "Уровни" это настолько мутное понятие если в реальности говорить об уровнях можно только в случае наследования или наличия в составе. А в реальности уровней нет. Все в перемешку. PC_>В отличии от зашореной ООП вылитой в граните, здесь структура намного более гибкая. Она может расходится и сходится на уровнях, анализируя что на каждом этапе появляется.
Ну, да..Я ж и говорю что "уровни" понятие весьма абстрактное. А вот "гранитность" ООП легко разбавить динамическим доопределением свойств и методов но только при непосредственном создании из класса. Более глубокое наследование (не от классов а от данных как в прототипных языках) делает систему не надежной и тормознутой.
PC_>На практике это означает что однажды определенное "понятие" сможет применится в любом месте системы. Вообще везде где есть числа они смогут быть интерпретированы как координаты и появится в этой системе всевозможные фигуры в конечном итоге, которыми можно оперировать.
Почему как координаты? А почему не другой тип? И что такое числа? Целое и вещественное это разные типы хотя и числа. PC_>Так работает мышление человека, на уровне распознавания.
Мышление у человеков по разному работает. Даже в одной индоевропейской группе англичанин, немец и русский думают по разному. Не говоря уже про китайцев. Есть еще языки объектной группы. Основные на планете. Но, представь, есть племена индейцы разговаривают не на объектном языке. Потому так нет привычных отношений типа вчера-завтра и т.п. они мыслят совсем по другому
PC_>Семантика переменной это изменяемая ячейка памяти компьютера. И операции оперирования с этой ячейкой. PC_>Тоесть это самый самый низкий уровень программирования который плотненько лежит на архитектуре.
PC_>Вместе с тем SQL или функциональное программирования уводит нас от такого понятия как "ячейка памяти"\переменная и являются намного более эффективными абстрактными моделями программирования достаточно хорошо оторванными от функционирования железа.
Я знаком с функциональным программированием еще по Lisp. В парадигме все красиво. И вопрос даже не в эффективности как с Прологом Хотя тоже прекрасная парадигма. А как раз в том что трудно мыслить такими категориями и переложить чисто в функциональную парадигму. Как раз в тему предыдущего поста. Людям так трудно думать.
Есть еще одна красивая парадигма-"машины управляемые потоками данных". Т.е. там для выполнения поступают не команды, а данные. Очень мощная парадигма для параллельной обработки, и весьма близко к тому как происходит в реальности. Однако запрограммировать такую машину человеку не человечески трудно. Кстати, мое предложение механизма событий решает эту проблему. Т.е. события происходят как угодно, а процедуры обработки пишутся линейно.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, batu, Вы писали:
B>>Всем спасибо! 0>Несколько отвлеченный вопрос, но, я думаю, это будет полезно для понимания. Решение какой практической задачи привело к созданию это парадигмы? То есть от какой реальной проблемы мысль полетела
Сначала не нравилось архитектура компьютера. Потом (еще в 80-х) япошки начали делать "машину управляемую потоками данных и назвали ее 5-м поколением. Я еще тогда сказал что ничего не получится.. Потом языки, изучение трансляторов, чтение литературы по языкам человеческим и по компутерным. Потом появилось объектное.. можно сказать я к тому же пришел.. но решил идти дальше.. И вот..пришел к тому что пришел. Ну, еще научные всякие. Базы данных, искусственный интеллект, экспертные системы, нейронные сети и т.п..Прототипные языки.. Кстати, жава..тоже любопытный язык.. В плане апплетов и работы с браузером.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, batu, Вы писали:
B>>Всем спасибо! 0>Несколько отвлеченный вопрос, но, я думаю, это будет полезно для понимания. Решение какой практической задачи привело к созданию это парадигмы? То есть от какой реальной проблемы мысль полетела
Искал общее. И что б упростить. И изучение и программирование и общение (понимание) между программистами разных языков и парадигм.
Здравствуйте, samius, Вы писали:
S>Автор теории за год так и не прикинул, сколько углов даст 1000 точек?
Это ленивые вычисления. Человек тоже может где угодно, когда угодно и к чему угодно применить такое понятие как
"очертить рамку", "отсортировать", "перевернуть вверх ногами" где это может иметь смысл. Он не занимается брутфорсам,
он просто на основе распознавания монтирует алгоритм и применяет его.
S>Не обобщай. Не все мыслят брутфорсом.
Программа которая плотно лежит на архитектуре процессора будет работать всегда быстрее.
И ровно настолько она отдалена от реальной модели построения окружающего мира.
Кэп.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, batu, Вы писали:
B>2. "Уровни" это настолько мутное понятие если в реальности говорить об уровнях можно только в случае наследования или наличия в составе. А в реальности уровней нет. Все в перемешку.
Понятие уровней и послойности здесь только в наглядных целях.
Поэтому выделено такое свойство как распознавание.
Если любая сущность себя может распознать на любом этапе, то фактически она там и применяется.
Число-Точка-Отрезок-Фигура просто могут распознаваться только один за одним, поэтому они образовуют слои абстракций над данными.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, batu, Вы писали:
B>2. "Уровни" это настолько мутное понятие если в реальности говорить об уровнях можно только в случае наследования или наличия в составе. А в реальности уровней нет. Все в перемешку.
Вот в том то и дело, что не такого понятия как наследования или жесткая структура как в ООП.
В структуре распознавания данные мигрируют от одных классов к другим на основе их свойств.
Если на примере:
Обьект класса Авто. Пока обьект имеет колеса и мотор он принадлежит классу Авто.
Если от него забрать колеса и мотор, то класс Авто для этого обьекта распознан не будет, но будет
наложен на обьект класс Металолом, например.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, samius, Вы писали:
S>>Автор теории за год так и не прикинул, сколько углов даст 1000 точек? PC_>Это ленивые вычисления. Человек тоже может где угодно, когда угодно и к чему угодно применить такое понятие как PC_>"очертить рамку", "отсортировать", "перевернуть вверх ногами" где это может иметь смысл. Он не занимается брутфорсам, PC_>он просто на основе распознавания монтирует алгоритм и применяет его.
Все таки интересно, за сколько тысяч лет твой подход лениво распознает выпуклую оболочку на множестве из 1000 точек. или триангуляцию Делоне...
S>>Не обобщай. Не все мыслят брутфорсом. PC_>Программа которая плотно лежит на архитектуре процессора будет работать всегда быстрее. PC_>И ровно настолько она отдалена от реальной модели построения окружающего мира. PC_>Кэп.
Реальная модель построения округающего мира — это само по себе зачетно
Но ты полагаешь что твоя программа с точками, ленивыми углами и квадратами намного ближе? Вполне вероятно, при условии что твоя реальная модель мира построена из ленивых углов.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>2. "Уровни" это настолько мутное понятие если в реальности говорить об уровнях можно только в случае наследования или наличия в составе. А в реальности уровней нет. Все в перемешку.
PC_>Понятие уровней и послойности здесь только в наглядных целях. PC_>Поэтому выделено такое свойство как распознавание. PC_>Если любая сущность себя может распознать на любом этапе, то фактически она там и применяется. PC_>Число-Точка-Отрезок-Фигура просто могут распознаваться только один за одним, поэтому они образуют слои абстракций над данными.
И что мешает назвать это типами или классами? Кстати, это разные вещи. Если число это тип, то отрезок это может быть класс.
Ну, это не главное. В языках программирования мы создаем типы-классы снизу. Вот как ты делаешь. Число-Точка-Отрезок-Фигура.
А человеческий язык (и вообще развитие) в смысле придумывания слов (классов) развивался сверху. Сначала общие сущности и по мере обнаружения частных свойств выделялись более мелкие. Придумывание существительных это фактически придумывание нового класса. Потом придуманное слово применяется одновременно как имя класса и имя объекта.
"Мужчина должен построить дом, посадить дерево..." здесь слово "дом" применяется как класс. А в фразе "Я построил дом" слово "дом" применяется как объект. В английском (и французском) определенные (неопределенные)артикли.
Здравствуйте, samius, Вы писали:
S>Все таки интересно, за сколько тысяч лет твой подход лениво распознает выпуклую оболочку на множестве из 1000 точек. или триангуляцию Делоне...
Ну мозг както так работает ведь.
Натягивает на пиксели примитивы, примитивы мигрируют к фигурам, фигуры мигирируют в обьемные фигуры ...
Вот грубо говоря возьмем то окно в котором я сейчас печатаю текст.
Если бы в языке который строит структуры на основе распознования применить такое понятие "буква", то я бы получил в новом слое
все буквы что здесь есть, а если бы применил понятие "картинка", картинка бы себя распознала везде где здесь есть и я бы получил коллекцию картинок.
Вот класс нужно описывать не с точки зрения своего устройства, это так скажем сиюминутная его роль,
а с точки зрения свойств данных на которые можно натянуть этот класс. Эдакая глобальная утиная типизация.
Все что плавает как утка и крякает как утка и есть утка.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
PC_>Вот в том то и дело, что не такого понятия как наследования или жесткая структура как в ООП. PC_>В структуре распознавания данные мигрируют от одных классов к другим на основе их свойств.
PC_>Если на примере: PC_>Обьект класса Авто. Пока обьект имеет колеса и мотор он принадлежит классу Авто. PC_>Если от него забрать колеса и мотор, то класс Авто для этого объекта распознан не будет, но будет PC_>наложен на обьект класс Металлолом, например.
А может быть одновременно и авто и металлоломом
А преподаватель может быть одновременно и студентом. Это ж классика. Один и тот же объект может выполнять разные роли?
Но, проблема ООП в том, что объект может иметь свойства отличные от свойств определенных классом. Опять же классический пример. Пингвин-птица, но не летает. Решение этих проблем было предложено в прототипных языках. Но там свои заморочки. Я уже писал. Эффективность кода и надежность Потому я допустил только один уровень отличия от класса. Ну, такое вот решение. Можно сказать компромисс.
И еще одна вещь. Как происходит "Распознание"? Это ж должна быть единая процедура для всего. Как? А если разные то как их выбирать?
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, samius, Вы писали:
S>>Все таки интересно, за сколько тысяч лет твой подход лениво распознает выпуклую оболочку на множестве из 1000 точек. или триангуляцию Делоне...
PC_>Ну мозг както так работает ведь. PC_>Натягивает на пиксели примитивы, примитивы мигрируют к фигурам, фигуры мигирируют в обьемные фигуры ...
ты бы почитал что-нибудь. Или у тебя в отношении мозга такая же позиция как и с программированием? Типа если много читать, то некогда будет изобретать?
PC_>Вот грубо говоря возьмем то окно в котором я сейчас печатаю текст. PC_>Если бы в языке который строит структуры на основе распознования применить такое понятие "буква", то я бы получил в новом слое PC_>все буквы что здесь есть, а если бы применил понятие "картинка", картинка бы себя распознала везде где здесь есть и я бы получил коллекцию картинок.
Ты не ответил, сколько тысяч лет потребуется что бы распознать ленивым брутфорсом выпуклую оболочку из 1000 точек. Но взял планку повыше:
В окне условно мегапиксель. Сколько потребуется времени прежде чем твой подход распознает в нем все буквы описанным тобой макаром?
PC_>Вот класс нужно описывать не с точки зрения своего устройства, это так скажем сиюминутная его роль, PC_>а с точки зрения свойств данных на которые можно натянуть этот класс. Эдакая глобальная утиная типизация.
PC_>Все что плавает как утка и крякает как утка и есть утка.
Все что думает как утка — тоже есть утка.
Здравствуйте, batu, Вы писали:
B>И что мешает назвать это типами или классами? Кстати, это разные вещи. Если число это тип, то отрезок это может быть класс. B>Ну, это не главное. В языках программирования мы создаем типы-классы снизу. Вот как ты делаешь. Число-Точка-Отрезок-Фигура.
В сиюминутном контексте ничего не мешает. ООП это эдакий автомат газировки, который установлен здесь и сейчас и расчитан на один и тотже диаметр монеток. Стоит поменять диаметр монеток и автомат пришел в негодность, потому что инженеры не предусмотрели. В мире жестких структур данных все предусмотреть невозможно, любая мелкая деталь все ломает. В динамическом мире на основе распознования, просто перестраивается структура автоматически, меняются чередности, вложености, наборы классов на определенных данных.
B>А человеческий язык (и вообще развитие) в смысле придумывания слов (классов) развивался сверху. Сначала общие сущности и по мере обнаружения частных свойств выделялись более мелкие. Придумывание существительных это фактически придумывание нового класса. Потом придуманное слово применяется одновременно как имя класса и имя объекта. B>"Мужчина должен построить дом, посадить дерево..." здесь слово "дом" применяется как класс. А в фразе "Я построил дом" слово "дом" применяется как объект. В английском (и французском) определенные (неопределенные)артикли.
Построй по своей схеме иерархию обьектов, по правилам ООП
"Мужчина должен построить дом, посадить дерево...".
А потом я тебе скажу, есть участок в программе, который звучит так
"Мужчина должен построить автомобиль, посадить дерево...".
И твоя первая структура уже пришла в негодность, в том плане что ее нельзя применить.
Нет ты можешь конечно подумать и держать в голове обе этих структуры, но суть распознавания в динамической и гибкой структуре.
Стоит только автомобилю обзавестись таким понятием как "построить" и он автоматически себя сможет применить во всех местах программы где так или иначе чтото может быть "построено"
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, samius, Вы писали:
S>Ты не ответил, сколько тысяч лет потребуется что бы распознать ленивым брутфорсом выпуклую оболочку из 1000 точек. Но взял планку повыше:
Да не сколько.
Просто пишется чтото вроде вместо класса
public property IsConwex
{
[здесь условие на выпуклость. Если обьекты не в одной плоскости то обьект выпуклы ]
}
И все. Все обьекты можно проверить на выпуклость в системе.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, samius, Вы писали:
S>>Ты не ответил, сколько тысяч лет потребуется что бы распознать ленивым брутфорсом выпуклую оболочку из 1000 точек. Но взял планку повыше:
PC_>Да не сколько. PC_>Просто пишется чтото вроде вместо класса
PC_>public property IsConwex PC_>{ PC_> [здесь условие на выпуклость. Если обьекты не в одной плоскости то обьект выпуклы ] PC_>}
PC_>И все. Все обьекты можно проверить на выпуклость в системе.
PC_>Car.IsConwex = true PC_>Picture.IsConwex = false PC_>Point.IsConwex = false PC_>Cat.IsConwex = true
PC_>и так далее. Однажды описаное свойство появляется у всех обьектов где оно себя распознало, аттачится.
Я так и понял, что бы найти выпуклую оболочку точек на плоскости, придется перебрать все полигоны из этих точек и спросить у каждого, не содержит ли он все указанные точки.
Тагил рулит (ц)
Здравствуйте, PC_2, Вы писали:
PC_>В сиюминутном контексте ничего не мешает. ООП это эдакий автомат газировки, который установлен здесь и сейчас и расчитан на один и тотже диаметр монеток. Стоит поменять диаметр монеток и автомат пришел в негодность, потому что инженеры не предусмотрели. В мире жестких структур данных все предусмотреть невозможно, любая мелкая деталь все ломает. В динамическом мире на основе распознования, просто перестраивается структура автоматически, меняются чередности, вложености, наборы классов на определенных данных.
Я не очень понимаю слово "автоматически" в данном контексте. Кто и как это делает?
PC_>Построй по своей схеме иерархию обьектов, по правилам ООП PC_>"Мужчина должен построить дом, посадить дерево...". PC_>А потом я тебе скажу, есть участок в программе, который звучит так PC_>"Мужчина должен построить автомобиль, посадить дерево...". PC_>И твоя первая структура уже пришла в негодность, в том плане что ее нельзя применить. PC_>Нет ты можешь конечно подумать и держать в голове обе этих структуры, но суть распознавания в динамической и гибкой структуре. PC_>Стоит только автомобилю обзавестись таким понятием как "построить" и он автоматически себя сможет применить во всех местах программы где так или иначе чтото может быть "построено"
Твой пример слишком простой для разбора насколько я понимаю слово "распознавание". Вообще, в человеческом языке есть, конечно, неоднозначности, но они скорее лежат в плоскости "распознавания" лексем. Т.е. что имеется в виду. А когда понятно то дальше уже дело техники.
Здравствуйте, batu, Вы писали:
B>И еще одна вещь. Как происходит "Распознание"? Это ж должна быть единая процедура для всего. Как? А если разные то как их выбирать?
Происходит на основе уже преобретенных свойств.
Например если забрать у четыреугольника одну вершину, то он автоматически избавится от класса прямоугольник и примкнет к классу треугольник.
Хотя сам по себе обьект и данные будут одни и теже. Например он не потеряет цвет и координаты оставшихся вершин.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, samius, Вы писали:
S>Я так и понял, что бы найти выпуклую оболочку точек на плоскости, придется перебрать все полигоны из этих точек и спросить у каждого, не содержит ли он все указанные точки.
Если определить свойство выпуклость как любой обьект где хотябы две точки не находятся в одной плоскости то все в порядке.
В чем затык у тебя произошел ? Не пойму.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, batu, Вы писали:
B>Я не очень понимаю слово "автоматически" в данном контексте. Кто и как это делает?
Это делает компилятор, он на основе определенных свойств резолвит структуры классов над данными.
Тоесть в этой системе описываются не классы а свойства обьектов. А обьект уже налепливает на себя свойства,
под которые он подходит.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, samius, Вы писали:
S>>Я так и понял, что бы найти выпуклую оболочку точек на плоскости, придется перебрать все полигоны из этих точек и спросить у каждого, не содержит ли он все указанные точки.
PC_>Если определить свойство выпуклость как любой обьект где хотябы две точки не находятся в одной плоскости то все в порядке. PC_>В чем затык у тебя произошел ? Не пойму.
Ты знаешь что такое выпуклая оболочка? Нет, ну и ладно, забей. Я смотрю у тебя проблемы со школьным курсом геометрии, куда уж еще выпуклая оболочка?
Две точки не находятся в одной плоскости — это 8 баллов из 5-и!
Здравствуйте, samius, Вы писали:
S>Ты знаешь что такое выпуклая оболочка? Нет, ну и ладно, забей. Я смотрю у тебя проблемы со школьным курсом геометрии, куда уж еще выпуклая оболочка? S>Две точки не находятся в одной плоскости — это 8 баллов из 5-и!
Определи слово "оболочка" что оно означает в твоем понимании а тем более в терминах языка программирования.
Впрочем ладно, так уж сложилось что мне нужно доносить элементарные или очень элементарные вещи.
MyObject.IsConwex
транспортируй в метод
IsConwex(MyObject)
и избавишся в своем понимании от комбинаторного взрыва.
Свойства это по сути теже методы, просто в данном случае эти методы можно применить к любому обьекту
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, samius, Вы писали:
S>>Ты знаешь что такое выпуклая оболочка? Нет, ну и ладно, забей. Я смотрю у тебя проблемы со школьным курсом геометрии, куда уж еще выпуклая оболочка? S>>Две точки не находятся в одной плоскости — это 8 баллов из 5-и!
PC_>Определи слово "оболочка" что оно означает в твоем понимании а тем более в терминах языка программирования. Не позорился бы, гигант мысли PC_>Впрочем ладно, так уж сложилось что мне нужно доносить элементарные или очень элементарные вещи.
себе донеси для начала. Начни со школьной геометрии, там где про точки и плоскости. Запамятовал, какой класс.
Очень хороший прием, протупить, предложить свой пример чтобы разобраться, добрые люди возьмутся обьяснять тебе же разбирая твой пример,
а ты только обвинишь что тебя не так поняли и отправляешь в третий класс
Поршивенький характер, ничо не скажешь.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, samius, Вы писали:
PC_>Очень хороший прием, протупить, предложить свой пример чтобы разобраться, добрые люди возьмутся обьяснять тебе же разбирая твой пример, PC_>а ты только обвинишь что тебя не так поняли и отправляешь в третий класс
Интересно, найдется ли еще кто-нибудь, кто меня не так понял в этом топике?
PC_>Поршивенький характер, ничо не скажешь.
Ой, ты прям одуванчик
Здравствуйте, samius, Вы писали:
S>Интересно, найдется ли еще кто-нибудь, кто меня не так понял в этом топике?
Здесь как видишь говорят о абстрактных или очень абстрактных вещах.
И здесь нужно стараться и приложить немало усилий чтобы тебя поняли. Когда человек рассуждает
о высоких материях а не о гаечном ключе на 12 очень легко выглядеть смешным. Но другого пути нет,
ктото о этом должен хорошенько подумать. Тем более вот вижу что у Бату по сути крутятся теже идеи
в голове на счет класификации обьектов. Жаль что не все это понимают.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, samius, Вы писали:
S>>Интересно, найдется ли еще кто-нибудь, кто меня не так понял в этом топике?
PC_>Здесь как видишь говорят о абстрактных или очень абстрактных вещах.
Усё, не смею отвлекать.
PC_>И здесь нужно стараться и приложить немало усилий чтобы тебя поняли. Когда человек рассуждает PC_>о высоких материях а не о гаечном ключе на 12 очень легко выглядеть смешным. Но другого пути нет, PC_>ктото о этом должен хорошенько подумать. Тем более вот вижу что у Бату по сути крутятся теже идеи PC_>в голове на счет класификации обьектов. Жаль что не все это понимают.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>И еще одна вещь. Как происходит "Распознание"? Это ж должна быть единая процедура для всего. Как? А если разные то как их выбирать?
PC_>Происходит на основе уже преобретенных свойств. PC_>Например если забрать у четыреугольника одну вершину, то он автоматически избавится от класса прямоугольник и примкнет к классу треугольник. PC_>Хотя сам по себе обьект и данные будут одни и теже. Например он не потеряет цвет и координаты оставшихся вершин.
Ты с логическим программированием знаком?
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>Я не очень понимаю слово "автоматически" в данном контексте. Кто и как это делает?
PC_>Это делает компилятор, он на основе определенных свойств резолвит структуры классов над данными. PC_>Тоесть в этой системе описываются не классы а свойства обьектов. А обьект уже налепливает на себя свойства, PC_>под которые он подходит.
Компилятор не годится. Изменения могут происходить во время выполнения или просто со временем. Слесарю могут повысить зарплату или он может жениться. После этого он не перестанет быть слесарем. Но если ему отрежут руку...
Сделать можно все. То, что ты предлагаешь смесь прототипного программирования с логическим. Ни то ни другое нельзя назвать эффективным. Трудно себе представить как это будет работать. И какие полезут ошибки и как их искать..
Здравствуйте, batu, Вы писали:
B>Компилятор не годится. Изменения могут происходить во время выполнения или просто со временем. Слесарю могут повысить зарплату или он может жениться. После этого он не перестанет быть слесарем. Но если ему отрежут руку...
Да, компилятор нет. Нужна другая виртуальная машина с экзотическими возможностями.
B>Сделать можно все. То, что ты предлагаешь смесь прототипного программирования с логическим. Ни то ни другое нельзя назвать эффективным. Трудно себе представить как это будет работать. И какие полезут ошибки и как их искать..
Это будет работать как база знаний.
Ошибки если полезут то высокоуровневые.
Чтото не так интерпретировано как нужно, нужно системе "подсказать", "уточнить", доопределить.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, batu, Вы писали:
B>>Компилятор не годится. Изменения могут происходить во время выполнения или просто со временем. Слесарю могут повысить зарплату или он может жениться. После этого он не перестанет быть слесарем. Но если ему отрежут руку...
PC_>Да, компилятор нет. Нужна другая виртуальная машина с экзотическими возможностями.
B>>Сделать можно все. То, что ты предлагаешь смесь прототипного программирования с логическим. Ни то ни другое нельзя назвать эффективным. Трудно себе представить как это будет работать. И какие полезут ошибки и как их искать..
PC_>Это будет работать как база знаний. PC_>Ошибки если полезут то высокоуровневые. PC_>Чтото не так интерпретировано как нужно, нужно системе "подсказать", "уточнить", доопределить.
Я ж говорю Пролог. Логическое программирование.
Здравствуйте, batu, Вы писали:
PC_>>Это будет работать как база знаний. PC_>>Ошибки если полезут то высокоуровневые. PC_>>Чтото не так интерпретировано как нужно, нужно системе "подсказать", "уточнить", доопределить. B>Я ж говорю Пролог. Логическое программирование.
Пролог это логическое программирование с предикатами.
А здесь программирование на модели распознования, тоесть здесь какбе нечеткая логика.
Вообщем этот форум не оч. удобен для продуктивного обмена накопленых размышлений,
если есть аська можно погалдеть там) Я теорию концепций до сих не понял, но эт нужно спрашивать
по ходу дела)
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Пролог это логическое программирование с предикатами.
Ну, а предикаты включают объекты.
Все варианты конструирования высказывания это комбинации функтора, объекта логических функций ( и, или, нет, следует) и формул (правил объединения в скобки)
PC_>А здесь программирование на модели распознования, тоесть здесь какбе нечеткая логика.
Почему не четкая? Не надо сочинять.. PC_>Вообщем этот форум не оч. удобен для продуктивного обмена накопленых размышлений, PC_>если есть аська можно погалдеть там) Я теорию концепций до сих не понял, но эт нужно спрашивать PC_>по ходу дела)
ICQ 139070664
Те же тестикулы, но в другом ракурсе.
