Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт дек 06, 2019 00:24

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - локальные фреймы данных
Автор Сообщение
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
Wlad писал(а):
Вот мне очень бы хотелось глянуть, как это сделано!

Все выглядит очень просто:
Код:
: m1 a) a @ IF 1 ELSE 2 THEN . ;  \ определяем первый модуль с локальной для этого модуля переменной a
+: m2 b) 1 a ! m1 0 a ! m1 ;                       \ определяем второй модуль
                                                                  \ во втором модуле пишем в переменную a первого модуля
m2  ( 1 2 ) \ результат работы второго модуля с включением первого

ps. Идея состоит в том, что локальный словарь первого модуля "растягиваем" на второй модуль, определяемый сразу после первого модуля. Растяжка делается с помощью слова +:
Если бы вместо +: было : , то для второго модуля был бы создан свой локальный словарь, а старый лок. словарь для определения
первого модуля в части имен слов был бы удален. В итоге к переменной а не будет доступа ниоткуда кроме как из модулей 1 и 2.
Сообщение Добавлено: Чт мар 29, 2012 13:57
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
spf писал(а):
...
Нет, рабское подражание нам не нужно. См., например, у Броуди про зеленые и красные яблоки...
Сообщение Добавлено: Ср мар 28, 2012 23:16
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
Wlad писал(а):
gudleifr писал(а):
Простой и надежный механизм структур, унаследованный от C. Так, нет же, поощряется создание специальных методов (т.е. слов) для доступа к отдельным полям. И даже в С некоторые пытаются так делать. А в Forth можно сразу перейти к нужным словам, минуя структуры...
Wlad писал(а):
Если брать семантический уровень реализации модели, то как вы "переход к словам, минуя структуры" обоснуете с точки зрения к атрибутам объектов? ОСОБЕННО, при их изменениисо стороны внешних воздействий?


\ "структура"
0
CELL -- A
CELL -- B
CELL -- C
CONSTANT /struct

\ "доступ к отдельным полям"
: getA ( object -- x ) A @ ;
: setA ( x object -- ) A ! ;

\ "перейти к нужным словам, минуя структуры"
WORDLIST CONSTANT object ALSO object CONTEXT ! DEFINITIONS
VARIABLE A VARIABLE B VARIABLE C
: getA ( -- x ) A @ ;
: setA ( x -- ) A ! ;
PREVIOUS DEFINITIONS

\ "изменение со стороны внешних воздействий"
123 object::setA
123 `setA object send-message
Сообщение Добавлено: Ср мар 28, 2012 22:36
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
gudleifr писал(а):
В рамках же стандарта "по Броуди": класс == словарь.

Если продолжить эту аналогию, то: методы и свойства класса == элементы словаря (слова).
Но, что будет поставлено в соответствие "объекту" (экземпляру класса)? И, как он создается?

Другая возможная аналогия: словарь ? объект.
Сообщение Добавлено: Ср мар 28, 2012 22:05
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
gudleifr писал(а):
С теми же локалсами. Да, используя их, можно писать почти как на C. Но, зачем писать "как на C"? Покажите мне реально полезную программу, которая после добавления локалсов стала красивее и лучше, чем без них. Докажите, что подобных результатов нельзя добиться используя другие, традиционные для Forth средства.

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

Wlad писал(а):
Например в Обероне-07 вообще запрещён синтаксически доступ к переменной из другого модуля напрямую. Читать - читай! А писать - только через вызов процедуры или метода.

И сразу вспоминается VALUE и USER-VALUE переменные.
т.е. значение получаем просто по имени, а присвоение значения с помощью специального метода, в случае с USER-VALUE еще интереснее, т.к. у каждого потока такие переменные уникальны. Ничто не мешает сделать подобный же механизм для ээ модулей. Собственно, синтаксический доступ к переменной из другого словаря, особенно, если он не находится в контексте невозможен.
Сообщение Добавлено: Ср мар 28, 2012 20:53
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
gudleifr писал(а):
Что касаемо атрибутов... Хотелось бы написать, что подобные идеи Forth противопоказаны, с его-то концепцией слово-действие.

Я уже говорил, что у вас странный взгляд на Форт ?
В форке все кроме lfa cчитается атрибутом и потенциально может быть изменено.
Какого-либо противоречия с Фортом я не вижу, более того, считаю более логичным выбранный подход 8)
Сообщение Добавлено: Ср мар 28, 2012 20:43
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
Wlad писал(а):
Если брать семантический уровень реализации модели, то как вы "переход к словам, минуя структуры" обоснуете с точки зрения к атрибутам объектов? ОСОБЕННО, при их изменениисо стороны внешних воздействий?
Прошу прощения, перестал регулярно посещать этот Форум (уж очень, как-то, со всеми не согласен). Поэтому, с опозданием...
Что касаемо атрибутов... Хотелось бы написать, что подобные идеи Forth противопоказаны, с его-то концепцией слово-действие. Но... Сам Мур в своей давнишей книге предложил что-то вроде объектов - поля. С методами... Интересно, это действительно писалось в 70-м году? Мне, все же, кажется, что если Вам нужны атрибуты, их нужно запихнуть внутрь Вашей версии ядра: что-то вроде SmallTalk или словарные статьи ориентированные не на действия, а на параметры. В рамках же стандарта "по Броуди": класс == словарь.
Сообщение Добавлено: Ср мар 28, 2012 20:39
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
chess писал(а):
Я, например, реализовал модули так, чтобы доступа к их переменным вообще ниоткуда(кроме как из самого модуля) не было. Исключение составляет только случай когда один модуль является составной частью другого модуля.

Если Вас не затруднит (или это не нарушает какого-то копирайта), не могли бы вы выложить здесь или кинуть в личку код реализации этого механизма?!!!!!!!
У Броуди, в "Думай Фортно" :) , я встретил упоминание такой вещи, но Форт - у меня практически не используется, хотя мне интересен. Вот мне очень бы хотелось глянуть, как это сделано! Хотя Броуди и ратует в книге про открытость всего и вся, но мне модульный вариант ограничения видимости, предложенный Виртом (Модула-2, Обероны), очень много раз жизнь облегчал и спасал, и, скажем так, "более понятен" с точки зрения создания моделей систем...
Сообщение Добавлено: Ср мар 28, 2012 20:33
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
Wlad писал(а):
Например в Обероне-07 вообще запрещён синтаксически доступ к переменной из другого модуля напрямую. Читать - читай! А писать - только через вызов процедуры или метода.

В форте можно определить модули с взаимным доступом к переменным в том числе и по записи. Причем это может касаться не всех модулей, а только, например, конкретных двух. Вопрос только в целесообразности этого. Наверное когда делали Оберон-07 решили, что это нецелесообразно. В spf для каждого модуля любое количество переменных можно сделать общедоступным для всех модулей. Я, например, реализовал модули так, чтобы доступа к их переменным вообще ниоткуда(кроме как из самого модуля) не было. Исключение составляет только случай когда один модуль является составной частью другого модуля. В этом случае доступ возможен только между этими модулями. Пока этого вполне достаточно.
Сообщение Добавлено: Ср мар 28, 2012 12:28
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
gudleifr писал(а):
Простой и надежный механизм структур, унаследованный от C. Так, нет же, поощряется создание специальных методов (т.е. слов) для доступа к отдельным полям. И даже в С некоторые пытаются так делать. А в Forth можно сразу перейти к нужным словам, минуя структуры...
Я пытаюсь. Особенно в методах установки/записи в поле "структуры". И очень себе благодарен потом, что не поленился! ;)
Например в Обероне-07 вообще запрещён синтаксически доступ к переменной из другого модуля напрямую. Читать - читай! А писать - только через вызов процедуры или метода.

Если брать семантический уровень реализации модели, то как вы "переход к словам, минуя структуры" обоснуете с точки зрения к атрибутам объектов? ОСОБЕННО, при их изменениисо стороны внешних воздействий?
Сообщение Добавлено: Вт мар 27, 2012 14:23
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
in4 писал(а):
делать интерфейс с Windows - то с локалсами исходник чище
Никоим образом, если не считать локалсами 4 вечных параметра сообщения. См. FOBOS.
Сообщение Добавлено: Пн мар 19, 2012 20:50
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
Я, собственно, к тому, что если писАть в стиле Мура - локалсы как бы и не нужны. А если переписывать на FORTHе исходники с С или делать интерфейс с Windows - то с локалсами исходник чище - меньше стековой эквилибристики. Ну и исходники выходят похожими, можно легко найти аналогичные места.
Сообщение Добавлено: Пн мар 19, 2012 18:53
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
in4 писал(а):
Но иногда (много обращений к нескольким параметрам слова, доступ к полям структуры) локалсы могут заменить стековые манипуляции. Программа будет выглядеть проще...
Но с локалсами проще. Сам стараюсь не использовать - Мура начитался...
Когда это Мур призывал отказываться от того, что проще? Просто, он (и я) считает, что локалсы это ненужное усложнение. И пока я не видел контрпримеров.
Возьмем, например, C++. Простой и надежный механизм структур, унаследованный от C. Так, нет же, поощряется создание специальных методов (т.е. слов) для доступа к отдельным полям. И даже в С некоторые пытаются так делать. А в Forth можно сразу перейти к нужным словам, минуя структуры...
Сообщение Добавлено: Пн мар 19, 2012 12:41
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
gudleifr писал(а):
Берется кто-нибудь доказать, что программа с локалсами удобнее и красивее программы без них?
Конечно, все относительно... ;) Но иногда (много обращений к нескольким параметрам слова, доступ к полям структуры) локалсы могут заменить стековые манипуляции. Программа будет выглядеть проще. IMHO, это единственное их достоинство. Без локалсов, конечно, можно. Но с локалсами проще. ;) Сам стараюсь не использовать - Мура начитался... :)
Сообщение Добавлено: Пн мар 19, 2012 04:13
  Заголовок сообщения:  Re: локальные фреймы данных  Ответить с цитатой
Думаю, что зафлуживать еще одну тему проблемами нужности оптимизации нет смысла. Проблема не в этом. Проблема в том, что о чем бы ни шел разговор: о локалсах (здесь), оптимизации, иероглифах или еще о чем-либо, сторонники этих нововведений жульничают. Они начинают свою песнь словами "Всем понятно, что претворяя в жизнь решения партсъезда..." - и считают, что дальнейшая аргументация избыточна. Т.к., на словах, все выразили готовность подкреплять свои слова практикой, то предлагаю не рассуждать о том, что было бы "хорошо", а честно анализировать применимость представляемого метода: в чем проблема, почему нельзя решить иначе, насколько помогло и т.д.

С теми же локалсами. Да, используя их, можно писать почти как на C. Но, зачем писать "как на C"? Покажите мне реально полезную программу, которая после добавления локалсов стала красивее и лучше, чем без них. Докажите, что подобных результатов нельзя добиться используя другие, традиционные для Forth средства.

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

P.S. Да и грузить подробностями реализации для конкретной системы, думаю, менее полезно, чем подробно алгоритмизировать важные моменты. (Это я посмотрел на код, который выложил.)
Сообщение Добавлено: Вс мар 18, 2012 20:25

Часовой пояс: UTC + 3 часа [ Летнее время ]


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB