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/ |