Forth
http://www.fforum.winglion.ru/

Форт и ООП
http://www.fforum.winglion.ru/viewtopic.php?f=25&t=2050
Страница 5 из 6

Автор:  VshMt [ Пт апр 17, 2009 00:04 ]
Заголовок сообщения: 

Mihail писал(а):
Что за побочные эффекты? Можно не примере?

Ну ты млин... Требуешь от меня непосильного шевеления моска :) Вот смотри, данные в программе меняются согласно описанию слова: берем со стэка то-то выкладываем то-то, а больше ни-ни упаси господь поменять данные в какой-либо другой области памяти. Ну например как в функциональном программировании. Сл-но взял да переписал слово, и еси преобразование стэка сохранилось то и все остальное будет работать. И вот в ФП там точно никаких побочных фефектов фикции. Есть функции и аргументы. А все остальное к $%^ням. Вот где-то так. Только в Форте это очень гибко и зависит полностью от тебя самого, хошь в смысле ФП пиши, ахошь в любом другом стиле можно писать. Ну и еще объем исходного кода слова должен умещаться в твоей (как это...) краткосрочной памяти. Тогда и понимание бсмысла слов будет достигнуто быстрее.

Токо вы это товой, сильно не пинайти. Пешу по слабой памяти, апосля корпоратива... :( Увы мне горемычному. Т.к.имею тягу к пиву, абхазскому вину и Форту. Но вот акромя первых пунктов Форт в моем лице ничего и не приобрел :(

in4 Ну напеши ченить про colorForth. Может в какой другой ветке, а напиши. Душа просит :((

Автор:  K`[f [ Вс апр 19, 2009 09:55 ]
Заголовок сообщения: 

mOleg писал(а):
мня, зачем сразу кастрировать!? нет, я еще могу понять обрезание, но кастрацию?
Через стек возвратов столько всего делается, тот же бэктрекинг без этого как?
А от ассемблера в Форте надо дистанцироваться, ассемблер это вобще вредный довесок (идеалогически вредный)


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

Автор:  mOleg [ Пн апр 20, 2009 22:14 ]
Заголовок сообщения: 

K`[f писал(а):
А при чём тут кастрация? Тот же бэктрекинг - если уж нужен - создайте для этого отдельный набор слов, который взаимодействует с системой.

дело в том, что его удобно реализовывать через доступ к стеку возвратов (манипуляции адресами)

K`[f писал(а):
Если считаете, что он нужен везде - опишите интерфейс оного в рамках стандарта, но никаких завязок на конркетную реализацию - т.е. тот же стек возвратов.

вот это и есть кастрация. Стек возвратов в Форте шикарнейшая вещь, отказываться от нее = лишаться половины возможностей.

Автор:  K`[f [ Ср апр 22, 2009 07:08 ]
Заголовок сообщения: 

mOleg писал(а):
вот это и есть кастрация. Стек возвратов в Форте шикарнейшая вещь, отказываться от нее = лишаться половины возможностей.


Ассемблер Z80, помнится, мне тоже нравился куда больше, чем интеловский. :)

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

1.Целые числа
2.Адреса
3.Стек потока управления при компиляции
4.Числа с плавающей точкой
5.Текущий контекст (сейчас - SET-ORDER / GET-ORDER)
6.Контекст компиляции (аналогично п.5, а вот этого сейчас нет)
7.Ещё вроде что-то было, не помню...

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

Автор:  Mihail [ Ср апр 22, 2009 11:04 ]
Заголовок сообщения: 

K`[f писал(а):
выведя стек возвратов из под ручного контроля программиста, мы сможем делать локальные переменные (не столь суть важно)


Локальные переменные можно реализовать и без выведения стек возвратов из под ручного контроля программиста.
http://spf.cvs.sourceforge.net/viewvc/s ... /locals4.f

K`[f писал(а):
оптимизировать работу программы (а это важнее), в точности, как и на плюсах каких-нибудь.


Разве какие-нибудь плюсы превосходят СПФ по оптимизации кода?

Автор:  K`[f [ Ср апр 22, 2009 13:31 ]
Заголовок сообщения: 

Mihail писал(а):
Локальные переменные можно реализовать и без выведения стек возвратов из под ручного контроля программиста.
http://spf.cvs.sourceforge.net/viewvc/s ... /locals4.f


Ессно. Но речь-то была не про это.

Mihail писал(а):
Разве какие-нибудь плюсы превосходят СПФ по оптимизации кода?


Конкретно не сравнивал. Хотя, подозреваю, это так и есть (по крайней мере, на Intel-платформе). Но, опять же, я говорил про несколько другое. Кстати - не уверен, что это и в обычном Форте можно реализовать в какой-то форме - почему бы и нет? Тут ещё подумать надо. А имел я в виду использование подходов из того-же мэйнстрим-программирования - когда при написании кода уделяется первостепенное значение читабельности, а не тому, как оно будет скомпилировано - т.е. часть "интеллектуальной" нагрузки ложится на компилятор. Простейший пример - предвычисление результатов работы цикла. Т.е., например, пишем мы нечто типа SOM_VALUE 0 DO SOME_ACTION LOOP, а компилятор уже сам решает, что он может эту последовательность слов вычислить сразу и заменить константой.

Автор:  Hishnik [ Ср апр 22, 2009 18:03 ]
Заголовок сообщения: 

Mihail писал(а):
Разве какие-нибудь плюсы превосходят СПФ по оптимизации кода?

Я в шоке...

Автор:  mOleg [ Ср апр 22, 2009 20:39 ]
Заголовок сообщения: 

K`[f писал(а):
mOleg писал(а):
вот это и есть кастрация. Стек возвратов в Форте шикарнейшая вещь, отказываться от нее = лишаться половины возможностей.
Ассемблер Z80, помнится, мне тоже нравился куда больше, чем интеловский.

это вещи разного уровня. Тут не просто синтаксис, а реальная возможность влиять на поток управления.

K`[f писал(а):
Впрочем, если без шуток - лично мне видится, что должно быть минимум несколько словарей, для основных общеупотребимых сущностей и разных назначений:

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

K`[f писал(а):
3.Стек потока управления при компиляции

а именно CONTROL STACK которого в СПФе нету, и это очень неудобно. Я вот сейчас как раз думаю в форк этот стек внедрять, бо уже во многих местах сталкивался с проблемами из-за его отсутствия 8(

K`[f писал(а):
4.Числа с плавающей точкой

кстати, есть где-нибудь реализация fp на сопроцессоре для 32 битных чисел? А то "не хочется делать велосипед".

K`[f писал(а):
5.Текущий контекст (сейчас - SET-ORDER / GET-ORDER)

интересно, что слова для работы с контекстом удобно выделять в отдельный словарь. Так было сделано в СМАЛ32 и я по-достоинству это решение оценил. В итоге в форке есть словарь ROOT, лежащий на дне контекста. Очень удобно, если вдруг забыл сделать ALSO и попал в "закрытый" контекст.

K`[f писал(а):
6.Контекст компиляции (аналогично п.5, а вот этого сейчас нет)

читайте КОП Гасаненко. Там он введен ;)
я тоже делал его, но потом отказался - он обычно не нужен. В любом случае наростить под CURRENT стек не сложно!

K`[f писал(а):
Опять же, задумайтесь над таким интересным фактом - выведя стек возвратов из под ручного контроля программиста, мы сможем делать локальные переменные (не столь суть важно) и оптимизировать работу программы (а это важнее), в точности, как и на плюсах каких-нибудь.

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

K`[f писал(а):
Т.е., например, пишем мы нечто типа SOM_VALUE 0 DO SOME_ACTION LOOP, а компилятор уже сам решает, что он может эту последовательность слов вычислить сразу и заменить константой.

упс. Зачем? (что от этого выиграется? - я вижу сплошь проблемы тут и никаких плюсов)

Автор:  mOleg [ Пн апр 27, 2009 22:44 ]
Заголовок сообщения: 

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

собственно, почти эксклюзивно для вас написана следующая статья языковая среда программирования так же советую почитать статьи, посвященные ЯОП (его пророчат на смену ООП, почему-то не замечая, что Форт уже есть, и давно) там озвучены претензии к ООП технологии, и перечисленны преимущества ЯОП. Почитайте хотя бы ту ссылку, которая дана в конце статьи ;)

Автор:  KPG [ Ср июл 24, 2019 11:20 ]
Заголовок сообщения:  Re: Форт и ООП

Сложность уровня абстракций (ради абстракций?)
Статья на хабр
Пять лет использования C++ под проекты для микроконтроллеров в продакшене

P.S. В рамках Форт решалось бы минимальными трудозатратами.
Чем хорош данный форум, что по разным вопросам уже было форумное обсуждение. :)

Автор:  Ethereal [ Ср июл 24, 2019 13:03 ]
Заголовок сообщения:  Re: Форт и ООП

Да уж.

- по объекту класса на каждый пин;
- объект, инкапсулирующий все пины для их инициализации одним методом;
- объект контроля RCC, который инкапсулирует все объекты, которые находятся на аппаратных шинах;
- проект конвертера CAN<->RS485 по протоколу заказчика содержит под 60 объектов;


Это пипец какой-то. Метод родил дикое усложнение только ради того чтобы уложить реальность в прокрустово ложе парадигмы.

Мне малознаком C++ , но увидел в статье упоминание про какие-то constexpr и почитал что это такое https://habr.com/ru/post/228181/ Да это-же попытка закосить под Форт и прикрутить к C++ какую-никакую интерпретацию на этапе компиляции. Правда

Но тут у C++ большие проблемы с синтаксисом: ... Также все это сопровождается непонятными сообщениями об ошибке, которые могут занимать сотни строк.
Но на этом проблемы не заканчиваются.


используемые шаблоны и constexpr невозможно просчитать до просмотра map, asm и bin файлов конечной прошивки (или запуска отладки в микроконтроллере);

Воистину превращение C в C++ - это нездоровая деятельнось по притаскиванию за уши всего удачного, что можно подсмотреть в других языках. Чтобы в итоге получилось C++ the best. Только меня почему-то воротит от всего этого.

Автор:  Victor__v [ Ср июл 24, 2019 13:25 ]
Заголовок сообщения:  Re: Форт и ООП

Ethereal писал(а):
Да уж.
Мне малознаком C++ , но увидел в статье упоминание про какие-то constexpr и почитал что это такое https://habr.com/ru/post/228181/ Да это-же попытка закосить под Форт и прикрутить к C++ какую-никакую интерпретацию на этапе компиляции. Правда

constexpr
Новый препроцессор! Теперь банановый :))

Автор:  Total Vacuum [ Ср июл 24, 2019 13:29 ]
Заголовок сообщения:  Re: Форт и ООП

Недавно наткнулся на статью. ООП на чистом С (не С++):
https://www.cs.rit.edu/~ats/books/ooc.pdf
Немножко не по теме, но может кому-то будет интересно. Ждем статью ООП на ассемблере :))

Автор:  Victor__v [ Ср июл 24, 2019 15:10 ]
Заголовок сообщения:  Re: Форт и ООП

Я кстати видел где-то в инете пример ООП на асме.

Автор:  Ethereal [ Ср июл 24, 2019 16:52 ]
Заголовок сообщения:  Re: Форт и ООП

Ethereal писал(а):
- по объекту класса на каждый пин;
- объект, инкапсулирующий все пины для их инициализации одним методом;
Подумал, а как бы я это "инкапсулировал" на Форте. Вышло так :
Код:
HEX

: PIN ( bit addr -- ) CREATE , 1 SWAP LSHIFT , DOES> 2@ ;
: PIN@ ( mask addr -- flag ) C@ AND 0<> ;
: PIN! ( flag mask addr -- ) 2DUP C@ SWAP INVERT AND 2SWAP AND OR SWAP C! ;

18 CONSTANT PORTB
0 PORTB PIN PORTB.0
1 PORTB PIN PORTB.1
2 PORTB PIN PORTB.2
3 PORTB PIN PORTB.3
4 PORTB PIN PORTB.4
5 PORTB PIN PORTB.5
6 PORTB PIN PORTB.6
7 PORTB PIN PORTB.7

\ \\\\\\\\\\\\\\\\\\\\\\\\\\

8F PORTB C! \ Initialization by one method
...
TRUE  PORTB.5 PIN! \ _-
FALSE PORTB.5 PIN! \ -_
PORTB.3 PIN@ IF ... ELSE ... THEN
Там после той статьи такой диалог в обсуждениях :
- Но нужно предохраняться, чтобы не подхватить ООП головного мозга. ... Возможно, вы слишком сильно разбиваете задачу на объекты. Зачем на каждый пин по объекту?
- Тогда нарушается принцип «один объект — одна область ответственности».

Ну вот выше я сделал одно слово - одна область ответственности - "пин" и слово инкапсулирующее все пины в "порт". Чо що то нужно ? Зачем огород городить ?
Не понимаю я в итоге этого ООП. Как в студенческие годы не понял так и до сих пор. В чем там фишка ?

Страница 5 из 6 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/