Способ описания деревьев?

[Utkin]

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

[MihalNik]

Сообщение от Utkin

Предприятие
.Аппарат
..Директор
...Секретарь
.Цех_программистов
..Старшая_обезьяна
..Юнга
..Техничка
..Чайник (эмалоированный)

Ну вот уже эротичней.

А еще нагляднее - просто пробельные сдвиги. Да только они и могут поддерживаться некоторыми редакторами. Однако, возможны ошибки. Тут писали о проблемах с Питоном.

Сообщение от Utkin

Не представляю как. Нужно в обычном тексте.

Дерево - это, например, таблица, где одна размерность - предки, а вторая - потомки (неудобно - сильно разреженная, n^2) или уровень вложенности определяют те же самые отступы (пустые ячейки, тогда разреженность зависит от сбалансированности дерева).
Обычный текст:
а: x, y
x: y, z

Сообщение от Utkin

Да, но написать такую систему, которая будет мешать пиво с виски (то есть текст с графикой) немного утомительно. Особенно на старте. Это на создание ИДЕ уйдет куча времени. Тут хотя бы так начать. Да и потом работа с текстом программы только в одном редакторе не сильно будет способствовать распространению языка. То есть нужны какие-то общедоступные компоненты для быстрого создания редактора.

Средство существеннее идеи. Возможность править дерево в тексте любым блокнотом порождает ошибки. Сами по себе текстовые редакторы не учитывают строения Вашего "дерева", поэтому не дадут ни удобства, ни надежности, ни физической скорости исполнения (нагрузка на железо большая). Для сколько-нибудь удобства понадобится писать отдельное дополнение для каждого редактора, которое будет сильно отъедать выч. ресурсы из-за того, что работает поверх текста (живой пример - IDEA).

Сообщение от Utkin

Универсальные динамические структуры данных. Проблемы современных типов данных - они не универсальны. В виде дерева можно выразить очень много абстрактных типов данных. Например, без проблем можно создать вектор, одним из элементов которого будет массив множеств стеков. Напишите это на с++ пожалста. В дереве это можно хранить в одной переменной. Которую одним оператором можно сбросить в XML и прочитать оттуда. Дерево можно реализовать в любой современной базе данных. Скорость реализации Ваших мечтов увеличится в разы. Все эти struct или там record это статичность. В дереве Вы на лету можете насувать туда столько всего, и все это быстренько прочитать/записать в файл.
Короче выразительная сила дерева огромна (но есть конечно предел, те же графы). Фактически простые программы могут использовать всего одну переменную, просто беря нужные значения из отдельных ветвей дерева. Вопрос только удобства такого подхода. Даже сама вот тема - я вот хочу описать оргструктуру предприятия в программе. Ну напишите это быстро на паскале. Мне будет достаточно описания дерева. Пункт два деревья упрощают обратную совместимость программ. То есть например, если Вы только добавляете новые ветви в дерево, то можно составить такой алгоритм обработки дерева, что программа сможет читать и работать с данными нового формата (в той части, в которой реализован ее функционал естественно).

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

Сообщение от Utkin

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

Лисп придумали более полувека назад, а в каких редакторах появилась удобная работа с его строениями? А ведь по своему назначению разницы м/у его скобками и отступами в Питоне нет. Какой смысл в шурупах, если забивать молотками?

[Utkin]

А еще нагляднее - просто пробельные сдвиги. Да только они и могут поддерживаться некоторыми редакторами. Однако, возможны ошибки.

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

Обычный текст:
а: x, y
x: y, z

Как и графы будет плохо читаться наверно. Не знаю, выразите представленную оргструктуру организации таким образом. И еще как Вы опишите y? Их ведь там 2. А если один из них будет иметь еще ветви. Как определить про какой y идет речь в Вашем описании?

Средство существеннее идеи. Возможность править дерево в тексте любым блокнотом порождает ошибки. Сами по себе текстовые редакторы не учитывают строения Вашего "дерева", поэтому не дадут ни удобства, ни надежности, ни физической скорости исполнения (нагрузка на железо большая). Для сколько-нибудь удобства понадобится писать отдельное дополнение для каждого редактора, которое будет сильно отъедать выч. ресурсы из-за того, что работает поверх текста (живой пример - IDEA).

Уверен есть решение, только я о нем еще не знаю. Вот собственно и ищу.

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

Дайте пример проблемы.

Лисп придумали более полувека назад, а в каких редакторах появилась удобная работа с его строениями?

Лисп смотрит на программы как на вложенный вызов функций. Я хочу смотреть на программу как на дерево.

Какой смысл в шурупах, если забивать молотками?

Мне интересно. С другой стороны если бы Лисп умирал, проблем бы не возникало. А он живет и здравствует во всяких Автокадах и Фотошопах с Гимпами.

[MihalNik]

Сообщение от Utkin

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

Предприятие: Аппарат, Цех_программистов
Аппарат: Директор
Директор: Секретарь
Цех_программистов: Старшая_обезьяна, Юнга, Техничка, Чайник

Скорее всего секратаря не собирались помещать в директора, но х.з.

Сообщение от Utkin

Уверен есть решение, только я о нем еще не знаю. Вот собственно и ищу.

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

Сообщение от Utkin

Дайте пример проблемы.

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

[Utkin]

Скорее всего секратарь не собиралась размещаться в директоре, но х.з.

Когда Аватар читал, там в моем посте была ошибка, я потом поправил.
Но что если у Цеха_программистов будет свой собственный Аппарат? Как это будет выглядеть тогда?

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

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

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

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

[MihalNik]

Сообщение от Utkin

Когда Аватар читал, там в моем посте была ошибка, я потом поправил.
Но что если у Цеха_программистов будет свой собственный Аппарат? Как это будет выглядеть тогда?

Странный вопрос.
Предприятие: Аппарат, Цех_программистов
Аппарат: ...
Цех_программистов: Аппарат, ...

Сообщение от Utkin

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

Хранятся данные в тектовых форматах очень часто.

Сообщение от Utkin

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

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

[Utkin]

Странный вопрос.

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

Хранятся данные в тектовых форматах очень часто.

Ну и здорово. Значит нужно выработать свой. Собственно об этом тема и есть.

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

Пока хватит и одного для начала. А там дальше видно будет имеет ли это вообще какой-то смысл.

[MihalNik]

Сообщение от Utkin

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

Можно сократить раскрытие либо по уровню вложенности, т.е.:
Аппарат: ...
но
Цех_программистов.Аппарат: ...
Либо до первого уникального предка (скорее всего предпочтительнее - понятнее для человека).

[Utkin]

Можно сократить раскрытие либо по уровню вложенности, т.е.:
Аппарат: ...
но
Цех_программистов.Аппарат: ...
Либо до первого уникального предка (скорее всего предпочтительнее - понятнее для человека).

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

[Alex11223]

Да не вопрос. К персоне добавились паспортные данные. Вгрузите его обратно.

Добавились куда? В файл (==файл от новой версии)? Или в программу (==файл от старой версии)?

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