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

Я всегда считал и считаю его подходы замечательными, великолепными работами вообще для всей области Computer Science, но до последнего времени не расценивал эту вещь как нечто могущее иметь реальное применение.

Но вот поработал пару дней и начал сомневаться (если бы не обозначенные ниже проблемы, был бы полностью переубеждён). Сразу даю примеры (файл bac4th-str.f в архиве):



В процессе немного расширил реализацию бэкФорта на SPF (но DIVE все ещё не написан (теперь написан)). Вот архив (ох, надо мне поднапрячься и научится-таки работать с CVS...).

А теперь домашнее задание (в том числе и моё):
1. Насколько годится этот подход для обработки строк?
2. Может ли он послужить хоть какой-то заменой авто-сборке мусора при работе со строками?
3. Можно ли расширить подход для использования с другими структурами (списками, например)?

Вопросы по текущей реализации (аналогично, сам тоже думаю):
4. Глобальная переменная previousVariable. Как и следовало ожидать, locals.f конфликтует с бэкФортом так как оба тяжело завязаны на стек возвратов, поэтому сделать её локальной не получится. Интересно, что в слове find конфликтов нет (но не уверен полностью...), тогда как локальная в split previousVariable конфликты вызывает (сделал по-другому).
5. Есть ли смысл делать запись в эту переменную обратимым (через B! )? Насколько я понял, сейчас слово split работает правильно и в каскадах (пример r3) можно сказать чисто случайно.
6. Необходимость использовать дополнительный L-стек (слова PRO и CONT). Опять же совместимость их со всем остальным в SPF. Циклы, локальные переменные. А есть ли она, эта необходимость, может и более простого R@ ENTER будет достаточно?
7. Слова BACK .. TRACKING сделал достаточно небрежно, так как не хотел разбираться с генерацией маш. кодов. Главное -- работает.
8. Обратимые процедуры (B! , SWAPB и прочие) просто скопировал из SMAL'а. Не проверены.

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

В ходе обдумывания вопроса пятого своего предыдущего сообщения, дошёл до такого (это весь код, запускается сразу):

Это -- второе...

Ещё один вопрос: хорошо, мы умеем разбивать одну строку на несколько, а можно ли сцепить их?

Пока так (ой, как криво!):



А хотелось бы:


В чём проблемы на этот раз?
1. Опять, как и в split, между разными итерациями необходимо передавать данные. В этом случае -- строку-сумму.
2. Слово concat должно уметь предсказывать будущее (работать на тиотимолине)... Объясняю: на входе у слова concat будет n-итераций (n-строк), тогда как выдаст оно только одну (результат конкатенации).

Что-то такое есть:



Но структурный CUT пропускает самый первый успех и не обрабатывает остальные. Тогда как concat должно сначала обработать все итерации, не пропуская их, и только на последней дать один-единственный успех. Определить какая итерация точно будет последней, при этом не нарушив закон причинно-следственных связей, не очень получается. Не говоря уже о том что нам надо во внешнем слове строить структурный CUT: ... -CUT (это ещё туда-сюда).

Может, как-то через NOT: ... -NOT ? Правда, реализация его на SMAL'е написана мной (судя по кривизне), а не от mlg (кажется, тогда я не смог найти в его работах исходного кода этих слов) и она не очень на вид надёжна.

Архив опять обновил.

Увы, это пока лишь просто интересно 8( Для того, чтобы понять, как с этим делом работать - нужно напрячься, в то же время целей у меня таких нет, чтоб был нужен перебор с откатом. Интересна сама методика управления потоком исполнения команд у Гасаненко - это да, идеи сами по себе тоже интересны. Но реального применения их я пока не видел. Очень жалко, что автор практически все свои поздние работы опубликовал только на английском языке 8( И еще очень бы хотелось с ним пообщаться в форуме

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

Как только -- так сразу.


Могу-то я могу... Но вот только проще чем сам автор уже не получится (по-моему). В моём случае для понимания помогла прокрутка в голове что же именно происходит при работе бэкФорта, и что там как называется. Но попробую. Опять же можно взять ещё одну мою статью со второго курса...

Тут вспоминается анекдот про учителя физики: " я им раз двадцать закон объяснял! Уже сам понял!) а они ни в какую 8( " Это шутка. Но иногда нужно понять, что поняли другие, чтобы понять, что не понял ничего
Вот! Можно и статью. Только не в pdf-е пожалуйста, а то сложно смотреть приходится 8( на другом компе.

Хм... Ну, [url=http://my.opera.com/profiT/homes/files/Реализации%20бэктрекинга%20на%20Форте.zip]ладно[/url]. А потом pdf запишу на ruFig-страницу.

В дополнение к статье пара слов:

бэкФорт -- это полностью работа в режиме исполнения. Поэтому этот подход работает везде, где есть эти три команды: pop, push и ret.

Вот ещё одна иллюстрация:

Итак, библиотека bac4th-str.f готова к использованию. Иду писать свой парсер ini-файлов (через эту библиотеку подобные парсеры вырождаются прямо на глазах). Свой парсер мне нужен, так как WinAPI-шный объективно не подходит, а значит и все аж три библиотеки (~yz\lib\profile.f, ~ac\lib\win\ini.f, ~af\lib\ini.f) , работающие через эти функции -- тоже не годятся.

Реализация бэкФорта bac4th.f пополнилась структурным NOT: -NOT, блоком альтернатив (*> альтернатива1 <*> альтернатива2 <*> альтернатива3 <* ) и блоком AMONG ... EACH ... ITERATE (хотя этот головоломный монстр так мне и не пригодился).

В bac4th-str.f конкатенацию строк сделал через дополнительную синтаксическую конструкцию:



Удалось также сделать её полностью каскадной (кстати, не использовав ни L-стек, ни стек возратов):



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

Архив обновлён.

не могу скачать статью 8( хотя остальные читаются.

Картинка тоже не видна...
видимо, проблема где-то более глобальная...

"Не верь глазам своим" (с)
Несмотря на то что невооружённым глазом видно что протечек в в bac4th-str.f нет и быть не могут я-таки решил проверить: а вдруг?

Прицепил в самом начале ~day\lib\memreport.f, запустил в конце кода MemReport. Вместо ожидаемого: "0 leaks" вылезло 18 протечек. Но как и следовало ожидать, я тут ни при чём...

В отчёте ясно написано что протекает слово SALLOT. И действительно оно хватает из памяти куски по 9 байт которые потом остаются висеть.

Подключил вместо ~ac/lib/str5.f ~ac/lib/str4.f -- "0 leaks". Эмпирика сошлась с теорией.

WingLion
Картинку случайно стёр. Записал опять.

oleg
Изменил имя файла: http://my.opera.com/profiT/homes/files/ ... rticle.zip

Может дело в том, что memreport.f заточен под str4.f ? Смотри в debugAlloc там есть сравнение на имя слова SALLOCATE и дальше какие-то подозрительные манипуляции с trace'ом. Т.е. я к тому что в str5.f может и нет утечек..
Кстати когда ты подключал memreport - ругался ли он на REQUIRE list: staticlist.f (нужен полный путь к staticlist.f) ?
Насчёт bac4th.f - START закрывает ядерное слово на запуск потока. Надо либо как-то переназвать, либо в отдельный модуль... И когда уже на CVS будет?

Может быть... Не копенгаген в этом...


Моя не дурак. Ошибка вылезла -- ошибка погибла. Хотел отправить вам, но в SPF-TODO уже описано.


В курсе. Надо названьице придумать другое...


По мере серьёзности
1. Когда ADSL появится.
2. Когда разберусь с CVS окончательно.
3. Когда мне дадут права на отсылку.

Ок. Я спрашивал чтобы confirm получить. Уже исправлено.


На диал-апе вполне нормально пользоваться. А насчёт cvs девелопер-доступа - создай на SF пользователя и я его добавлю.