Автор |
Сообщение |
|
|
Заголовок сообщения: |
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.
[quote="Wlad"]Вот мне очень бы хотелось глянуть, как это сделано! [/quote] Все выглядит очень просто: [code] : m1 a) a @ IF 1 ELSE 2 THEN . ; \ определяем первый модуль с локальной для этого модуля переменной a +: m2 b) 1 a ! m1 0 a ! m1 ; \ определяем второй модуль \ во втором модуле пишем в переменную a первого модуля m2 ( 1 2 ) \ результат работы второго модуля с включением первого [/code] ps. Идея состоит в том, что локальный словарь первого модуля "растягиваем" на второй модуль, определяемый сразу после первого модуля. Растяжка делается с помощью слова +: Если бы вместо +: было : , то для второго модуля был бы создан свой локальный словарь, а старый лок. словарь для определения первого модуля в части имен слов был бы удален. В итоге к переменной а не будет доступа ниоткуда кроме как из модулей 1 и 2.
|
|
|
|
Добавлено: Чт мар 29, 2012 13:57 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
spf писал(а): ... Нет, рабское подражание нам не нужно. См., например, у Броуди про зеленые и красные яблоки...
[quote="spf"]...[/quote]Нет, рабское подражание нам не нужно. См., например, у Броуди про зеленые и красные яблоки...
|
|
|
|
Добавлено: Ср мар 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
[quote="Wlad"][quote="gudleifr"]Простой и надежный механизм структур, унаследованный от C. Так, нет же, поощряется создание специальных методов (т.е. слов) для доступа к отдельным полям. И даже в С некоторые пытаются так делать. А в Forth можно сразу перейти к нужным словам, минуя структуры...[/quote][/quote][quote="Wlad"]Если брать семантический уровень реализации модели, то как вы "переход к словам, минуя структуры" обоснуете с точки зрения к атрибутам объектов? ОСОБЕННО, при их изменениисо стороны внешних воздействий?[/quote]
\ "структура" 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 писал(а): В рамках же стандарта "по Броуди": класс == словарь. Если продолжить эту аналогию, то: методы и свойства класса == элементы словаря (слова). Но, что будет поставлено в соответствие "объекту" (экземпляру класса)? И, как он создается? Другая возможная аналогия: словарь ? объект.
[quote="gudleifr"]В рамках же стандарта "по Броуди": класс == словарь.[/quote] Если продолжить эту аналогию, то: методы и свойства класса == элементы словаря (слова). Но, что будет поставлено в соответствие "объекту" (экземпляру класса)? И, как он создается?
Другая возможная аналогия: словарь ? объект.
|
|
|
|
Добавлено: Ср мар 28, 2012 22:05 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
gudleifr писал(а): С теми же локалсами. Да, используя их, можно писать почти как на C. Но, зачем писать "как на C"? Покажите мне реально полезную программу, которая после добавления локалсов стала красивее и лучше, чем без них. Докажите, что подобных результатов нельзя добиться используя другие, традиционные для Forth средства. Да можно, можно, только бывает удобнее и так и этак. Не всегда пишется качественная продуманная программа, иногда "набросок на коленке" гораздо полезнее и удобнее. Wlad писал(а): Например в Обероне-07 вообще запрещён синтаксически доступ к переменной из другого модуля напрямую. Читать - читай! А писать - только через вызов процедуры или метода. И сразу вспоминается VALUE и USER-VALUE переменные. т.е. значение получаем просто по имени, а присвоение значения с помощью специального метода, в случае с USER-VALUE еще интереснее, т.к. у каждого потока такие переменные уникальны. Ничто не мешает сделать подобный же механизм для ээ модулей. Собственно, синтаксический доступ к переменной из другого словаря, особенно, если он не находится в контексте невозможен.
[quote="gudleifr"]С теми же локалсами. Да, используя их, можно писать почти как на C. Но, зачем писать "как на C"? Покажите мне реально полезную программу, которая после добавления локалсов стала красивее и лучше, чем без них. Докажите, что подобных результатов нельзя добиться используя другие, традиционные для Forth средства.[/quote] Да можно, можно, только бывает удобнее и так и этак. Не всегда пишется качественная продуманная программа, иногда "набросок на коленке" гораздо полезнее и удобнее.
[quote="Wlad"]Например в Обероне-07 вообще запрещён синтаксически доступ к переменной из другого модуля напрямую. Читать - читай! А писать - только через вызов процедуры или метода.[/quote] И сразу вспоминается VALUE и USER-VALUE переменные. т.е. значение получаем просто по имени, а присвоение значения с помощью специального метода, в случае с USER-VALUE еще интереснее, т.к. у каждого потока такие переменные уникальны. Ничто не мешает сделать подобный же механизм для ээ модулей. Собственно, синтаксический доступ к переменной из другого словаря, особенно, если он не находится в контексте невозможен.
|
|
|
|
Добавлено: Ср мар 28, 2012 20:53 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
gudleifr писал(а): Что касаемо атрибутов... Хотелось бы написать, что подобные идеи Forth противопоказаны, с его-то концепцией слово-действие. Я уже говорил, что у вас странный взгляд на Форт ? В форке все кроме lfa cчитается атрибутом и потенциально может быть изменено. Какого-либо противоречия с Фортом я не вижу, более того, считаю более логичным выбранный подход
[quote="gudleifr"]Что касаемо атрибутов... Хотелось бы написать, что подобные идеи Forth противопоказаны, с его-то концепцией слово-действие.[/quote] Я уже говорил, что у вас странный взгляд на Форт ? В форке все кроме lfa cчитается атрибутом и потенциально может быть изменено. Какого-либо противоречия с Фортом я не вижу, более того, считаю более логичным выбранный подход 8)
|
|
|
|
Добавлено: Ср мар 28, 2012 20:43 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
Wlad писал(а): Если брать семантический уровень реализации модели, то как вы "переход к словам, минуя структуры" обоснуете с точки зрения к атрибутам объектов? ОСОБЕННО, при их изменениисо стороны внешних воздействий? Прошу прощения, перестал регулярно посещать этот Форум (уж очень, как-то, со всеми не согласен). Поэтому, с опозданием... Что касаемо атрибутов... Хотелось бы написать, что подобные идеи Forth противопоказаны, с его-то концепцией слово-действие. Но... Сам Мур в своей давнишей книге предложил что-то вроде объектов - поля. С методами... Интересно, это действительно писалось в 70-м году? Мне, все же, кажется, что если Вам нужны атрибуты, их нужно запихнуть внутрь Вашей версии ядра: что-то вроде SmallTalk или словарные статьи ориентированные не на действия, а на параметры. В рамках же стандарта "по Броуди": класс == словарь.
[quote="Wlad"]Если брать семантический уровень реализации модели, то как вы "переход к словам, минуя структуры" обоснуете с точки зрения к атрибутам объектов? ОСОБЕННО, при их изменениисо стороны внешних воздействий?[/quote]Прошу прощения, перестал регулярно посещать этот Форум (уж очень, как-то, со всеми не согласен). Поэтому, с опозданием... Что касаемо атрибутов... Хотелось бы написать, что подобные идеи Forth противопоказаны, с его-то концепцией слово-действие. Но... Сам Мур в своей давнишей книге предложил что-то вроде объектов - поля. С методами... Интересно, это действительно писалось в 70-м году? Мне, все же, кажется, что если Вам нужны атрибуты, их нужно запихнуть внутрь Вашей версии ядра: что-то вроде SmallTalk или словарные статьи ориентированные не на действия, а на параметры. В рамках же стандарта "по Броуди": класс == словарь.
|
|
|
|
Добавлено: Ср мар 28, 2012 20:39 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
chess писал(а): Я, например, реализовал модули так, чтобы доступа к их переменным вообще ниоткуда(кроме как из самого модуля) не было. Исключение составляет только случай когда один модуль является составной частью другого модуля. Если Вас не затруднит (или это не нарушает какого-то копирайта), не могли бы вы выложить здесь или кинуть в личку код реализации этого механизма?!!!!!!! У Броуди, в "Думай Фортно" , я встретил упоминание такой вещи, но Форт - у меня практически не используется, хотя мне интересен. Вот мне очень бы хотелось глянуть, как это сделано! Хотя Броуди и ратует в книге про открытость всего и вся, но мне модульный вариант ограничения видимости, предложенный Виртом (Модула-2, Обероны), очень много раз жизнь облегчал и спасал, и, скажем так, "более понятен" с точки зрения создания моделей систем...
[quote="chess"]Я, например, реализовал модули так, чтобы доступа к их переменным вообще ниоткуда(кроме как из самого модуля) не было. Исключение составляет только случай когда один модуль является составной частью другого модуля.[/quote] Если Вас не затруднит (или это не нарушает какого-то копирайта), не могли бы вы выложить здесь или кинуть в личку код реализации этого механизма?!!!!!!! У Броуди, в "Думай Фортно" :) , я встретил упоминание такой вещи, но Форт - у меня практически не используется, хотя мне интересен. Вот мне очень бы хотелось глянуть, как это сделано! Хотя Броуди и ратует в книге про открытость всего и вся, но мне модульный вариант ограничения видимости, предложенный Виртом (Модула-2, Обероны), очень много раз жизнь облегчал и спасал, и, скажем так, "более понятен" с точки зрения создания моделей систем...
|
|
|
|
Добавлено: Ср мар 28, 2012 20:33 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
Wlad писал(а): Например в Обероне-07 вообще запрещён синтаксически доступ к переменной из другого модуля напрямую. Читать - читай! А писать - только через вызов процедуры или метода. В форте можно определить модули с взаимным доступом к переменным в том числе и по записи. Причем это может касаться не всех модулей, а только, например, конкретных двух. Вопрос только в целесообразности этого. Наверное когда делали Оберон-07 решили, что это нецелесообразно. В spf для каждого модуля любое количество переменных можно сделать общедоступным для всех модулей. Я, например, реализовал модули так, чтобы доступа к их переменным вообще ниоткуда(кроме как из самого модуля) не было. Исключение составляет только случай когда один модуль является составной частью другого модуля. В этом случае доступ возможен только между этими модулями. Пока этого вполне достаточно.
[quote="Wlad"]Например в Обероне-07 вообще запрещён синтаксически доступ к переменной из другого модуля напрямую. Читать - читай! А писать - только через вызов процедуры или метода.[/quote] В форте можно определить модули с взаимным доступом к переменным в том числе и по записи. Причем это может касаться не всех модулей, а только, например, конкретных двух. Вопрос только в целесообразности этого. Наверное когда делали Оберон-07 решили, что это нецелесообразно. В spf для каждого модуля любое количество переменных можно сделать общедоступным для всех модулей. Я, например, реализовал модули так, чтобы доступа к их переменным вообще ниоткуда(кроме как из самого модуля) не было. Исключение составляет только случай когда один модуль является составной частью другого модуля. В этом случае доступ возможен только между этими модулями. Пока этого вполне достаточно.
|
|
|
|
Добавлено: Ср мар 28, 2012 12:28 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
gudleifr писал(а): Простой и надежный механизм структур, унаследованный от C. Так, нет же, поощряется создание специальных методов (т.е. слов) для доступа к отдельным полям. И даже в С некоторые пытаются так делать. А в Forth можно сразу перейти к нужным словам, минуя структуры... Я пытаюсь. Особенно в методах установки/записи в поле "структуры". И очень себе благодарен потом, что не поленился! Например в Обероне-07 вообще запрещён синтаксически доступ к переменной из другого модуля напрямую. Читать - читай! А писать - только через вызов процедуры или метода. Если брать семантический уровень реализации модели, то как вы "переход к словам, минуя структуры" обоснуете с точки зрения к атрибутам объектов? ОСОБЕННО, при их изменениисо стороны внешних воздействий?
[quote="gudleifr"]Простой и надежный механизм структур, унаследованный от C. Так, нет же, поощряется создание специальных методов (т.е. слов) для доступа к отдельным полям. И даже в С некоторые пытаются так делать. А в Forth можно сразу перейти к нужным словам, минуя структуры...[/quote]Я пытаюсь. Особенно в методах установки/записи в поле "структуры". И очень себе благодарен потом, что не поленился! ;) Например в Обероне-07 вообще запрещён синтаксически доступ к переменной из другого модуля напрямую. Читать - читай! А писать - только через вызов процедуры или метода.
Если брать семантический уровень реализации модели, то как вы "переход к словам, минуя структуры" обоснуете с точки зрения к атрибутам объектов? ОСОБЕННО, при их изменениисо стороны внешних воздействий?
|
|
|
|
Добавлено: Вт мар 27, 2012 14:23 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
in4 писал(а): делать интерфейс с Windows - то с локалсами исходник чище Никоим образом, если не считать локалсами 4 вечных параметра сообщения. См. FOBOS.
[quote="in4"]делать интерфейс с Windows - то с локалсами исходник чище[/quote]Никоим образом, если не считать локалсами 4 вечных параметра сообщения. См. FOBOS.
|
|
|
|
Добавлено: Пн мар 19, 2012 20:50 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
Я, собственно, к тому, что если писАть в стиле Мура - локалсы как бы и не нужны. А если переписывать на FORTHе исходники с С или делать интерфейс с Windows - то с локалсами исходник чище - меньше стековой эквилибристики. Ну и исходники выходят похожими, можно легко найти аналогичные места.
Я, собственно, к тому, что если писАть в стиле Мура - локалсы как бы и не нужны. А если переписывать на FORTHе исходники с С или делать интерфейс с Windows - то с локалсами исходник чище - меньше стековой эквилибристики. Ну и исходники выходят похожими, можно легко найти аналогичные места.
|
|
|
|
Добавлено: Пн мар 19, 2012 18:53 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
in4 писал(а): Но иногда (много обращений к нескольким параметрам слова, доступ к полям структуры) локалсы могут заменить стековые манипуляции. Программа будет выглядеть проще... Но с локалсами проще. Сам стараюсь не использовать - Мура начитался... Когда это Мур призывал отказываться от того, что проще? Просто, он (и я) считает, что локалсы это ненужное усложнение. И пока я не видел контрпримеров. Возьмем, например, C++. Простой и надежный механизм структур, унаследованный от C. Так, нет же, поощряется создание специальных методов (т.е. слов) для доступа к отдельным полям. И даже в С некоторые пытаются так делать. А в Forth можно сразу перейти к нужным словам, минуя структуры...
[quote="in4"]Но [u]иногда[/u] (много обращений к нескольким параметрам слова, доступ к полям структуры) локалсы могут заменить стековые манипуляции. Программа будет выглядеть проще... Но с локалсами проще. Сам стараюсь не использовать - Мура начитался...[/quote]Когда это Мур призывал отказываться от того, что проще? Просто, он (и я) считает, что локалсы это ненужное усложнение. И пока я не видел контрпримеров. Возьмем, например, C++. Простой и надежный механизм структур, унаследованный от C. Так, нет же, поощряется создание специальных методов (т.е. слов) для доступа к отдельным полям. И даже в С некоторые пытаются так делать. А в Forth можно сразу перейти к нужным словам, минуя структуры...
|
|
|
|
Добавлено: Пн мар 19, 2012 12:41 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
gudleifr писал(а): Берется кто-нибудь доказать, что программа с локалсами удобнее и красивее программы без них? Конечно, все относительно... Но иногда (много обращений к нескольким параметрам слова, доступ к полям структуры) локалсы могут заменить стековые манипуляции. Программа будет выглядеть проще. IMHO, это единственное их достоинство. Без локалсов, конечно, можно. Но с локалсами проще. Сам стараюсь не использовать - Мура начитался...
[quote="gudleifr"]Берется кто-нибудь доказать, что программа с локалсами удобнее и красивее программы без них?[/quote]Конечно, все относительно... ;) Но [u]иногда[/u] (много обращений к нескольким параметрам слова, доступ к полям структуры) локалсы могут заменить стековые манипуляции. Программа будет выглядеть проще. IMHO, это единственное их достоинство. Без локалсов, конечно, можно. Но с локалсами проще. ;) Сам стараюсь не использовать - Мура начитался... :)
|
|
|
|
Добавлено: Пн мар 19, 2012 04:13 |
|
|
|
|
|
Заголовок сообщения: |
Re: локальные фреймы данных |
|
|
Думаю, что зафлуживать еще одну тему проблемами нужности оптимизации нет смысла. Проблема не в этом. Проблема в том, что о чем бы ни шел разговор: о локалсах (здесь), оптимизации, иероглифах или еще о чем-либо, сторонники этих нововведений жульничают. Они начинают свою песнь словами "Всем понятно, что претворяя в жизнь решения партсъезда..." - и считают, что дальнейшая аргументация избыточна. Т.к., на словах, все выразили готовность подкреплять свои слова практикой, то предлагаю не рассуждать о том, что было бы "хорошо", а честно анализировать применимость представляемого метода: в чем проблема, почему нельзя решить иначе, насколько помогло и т.д.
С теми же локалсами. Да, используя их, можно писать почти как на C. Но, зачем писать "как на C"? Покажите мне реально полезную программу, которая после добавления локалсов стала красивее и лучше, чем без них. Докажите, что подобных результатов нельзя добиться используя другие, традиционные для Forth средства.
Например, приведенные мною выше стековые блоки так и остались курьезом. Копнув задачу глубже, понял, что без них проще. (Что это была за задача, правда, не помню. Помню только, что не пригодились.)
P.S. Да и грузить подробностями реализации для конкретной системы, думаю, менее полезно, чем подробно алгоритмизировать важные моменты. (Это я посмотрел на код, который выложил.)
Думаю, что зафлуживать еще одну тему проблемами нужности оптимизации нет смысла. Проблема не в этом. Проблема в том, что о чем бы ни шел разговор: о локалсах (здесь), оптимизации, иероглифах или еще о чем-либо, сторонники этих нововведений жульничают. Они начинают свою песнь словами "Всем понятно, что [s]претворяя в жизнь решения партсъезда[/s]..." - и считают, что дальнейшая аргументация избыточна. Т.к., на словах, все выразили готовность подкреплять свои слова практикой, то предлагаю не рассуждать о том, что было бы "хорошо", а честно анализировать применимость представляемого метода: в чем проблема, почему нельзя решить иначе, насколько помогло и т.д.
С теми же локалсами. Да, используя их, можно писать почти как на C. Но, зачем писать "как на C"? Покажите мне реально полезную программу, которая после добавления локалсов стала красивее и лучше, чем без них. Докажите, что подобных результатов нельзя добиться используя другие, традиционные для Forth средства.
Например, приведенные мною выше стековые блоки так и остались курьезом. Копнув задачу глубже, понял, что без них проще. (Что это была за задача, правда, не помню. Помню только, что не пригодились.)
P.S. Да и грузить подробностями реализации для конкретной системы, думаю, менее полезно, чем подробно алгоритмизировать важные моменты. (Это я посмотрел на код, который выложил.)
|
|
|
|
Добавлено: Вс мар 18, 2012 20:25 |
|
|
|
|