Локальные слова

вопрос

Хищник писал(а):

Плавающая точка, графика - везде ли?

вот и при чём тут обсуждаемое? наоборот, кроме локальных переменных (которые тоже не все делают - сложно) предложены локальные именованные отрезки кода

Hishnik

chess писал(а):

В том-то и дело, что не применимо. Правила находятся в долговременной памяти, а не в оперативной( объем внимания).

Очень интересно. То есть язык с большим количеством правил однозначно эффективнее, потому что его правила находятся в долговременной памяти, и программист гарантированно вспомнит, что и как можно применять в каждом конкретном случае?

Alexander

Не могу понять, куда движутся участники непонятного соревнования?!
Если я правильно понял Chess'а , то он просто не хочет засорять основной словарь определений. На это есть слово VOCABULARY.
Дальше идет речь, видимо, об ускорении процесса компиляции - использование списка поиска определений. Это я про слово WORDLIST.
Идея в чём? Наверное, если какая-то последовательность используются только раз и при этом сложно следить за правильностью использования стека (вот тут и вылезло слово LOCALS), то как раз можно использовать идею Chess'а.
А по мне так лучше лишний вызов подпрограммы в коде, потому что если я передам свой код другому человеку, то он сможет его понять. После этой фразы идея Chess'а кажется вполне приемлимой на стадии конечной сборки программы, когда её не надо никому показывать. Вот и дорассуждался я

я извиняюсь про :NONAME забыл вписать сразу -они ведь не создают слова в словаре, место занимают. единственное что их вызывать надо по хитрому, но ничего.

Hishnik

вопрос писал(а):

мне всё ещё непонятно, неужели польза от обсуждаемого неочевидна

А разве в технике бывает что-то очевидное? Любое предложение, любая технология требуют не столько доказательства, сколько пояснения работы и очерчивания сферы применения. Я ведь и не спорил с самой сутью предложения - да, оно работает, как заявлено. Но вот выводы никакие не сделаны, и самое главное, не указаны ограничения, откуда можно сделать вывод, что это надо срочно и повсеместно применять.

Hishnik

вопрос писал(а):

Хищник писал(а):
Плавающая точка, графика - везде ли?

вот и при чём тут обсуждаемое? наоборот, кроме локальных переменных (которые тоже не все делают - сложно) предложены локальные именованные отрезки кода

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

А что - ново, свежо, и развивает Форт! :))

И вот пока все нюансы не будут обсуждены, сидим и обсуждаем, а код уже можно не писать.

вопрос

Хищник писал(а):

вопрос писал(а):

мне всё ещё непонятно, неужели польза от обсуждаемого неочевидна

А разве в технике бывает что-то очевидное? Любое предложение, любая технология требуют не столько доказательства, сколько пояснения работы и очерчивания сферы применения. Я ведь и не спорил с самой сутью предложения - да, оно работает, как заявлено. Но вот выводы никакие не сделаны, и самое главное, не указаны ограничения, откуда можно сделать вывод, что это надо срочно и повсеместно применять.

Поискал и не нашёл тему Хищника, где как-раз речь , что программист не обязан наиболее эффективно использовать стек, а может вновь обращаться к переменной по имени - ...

Цитата:

идею динамически выделяемых древовидных двунаправленных неименованных контейнеров метаданных

как ни странно, фраза имеет смысл :))

Hishnik

вопрос писал(а):

Поискал и не нашёл тему Хищника, где как-раз речь , что программист не обязан наиболее эффективно использовать стек, а может вновь обращаться к переменной по имени - ...

Со стековыми кадрами? Я бы рассматривал это как пример решения чего, а не решения как. А программист обязан решать поставленную техническую задачу, а не развлекаться с красивыми кусочками кода.

вопрос писал(а):

Цитата:
идею динамически выделяемых древовидных двунаправленных неименованных контейнеров метаданных
как ни странно, фраза имеет смысл

Чайник Рассела тоже имеет смысл

K`[f

Хищник писал(а):

chess писал(а):

В том-то и дело, что не применимо. Правила находятся в долговременной памяти, а не в оперативной( объем внимания).

Очень интересно. То есть язык с большим количеством правил однозначно эффективнее, потому что его правила находятся в долговременной памяти, и программист гарантированно вспомнит, что и как можно применять в каждом конкретном случае?

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

mOleg

вопрос писал(а):

мне всё ещё непонятно, неужели польза от обсуждаемого неочевидна

мне еще не понятно, неужели вред от обсуждаемого не очевиден
ну чес.слово, как дети прямо

не бывает очевидных вещей, точнее, бывают, и обычно это ошибочные решения.

mOleg

а это мой вариант

\ куб
: ^3 ( n --> d ) DUP DUP UM* SD* ;
\ сумма кубов чисел N количеством # штук
: SUM^2 ( [ Ni ] # --> d ) 1 - NOW ^3 SINCE ROT ^3 D+ TILL ;

вопрос

Хищник писал(а):

Со стековыми кадрами? Я бы рассматривал это как пример решения чего, а не решения как. А программист обязан решать поставленную техническую задачу, а не развлекаться с красивыми кусочками кода.

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

то же и тут - нужно ли мучить себя либо достаточно сложной факторизацией
кода или назвать локально

Hishnik

вопрос писал(а):

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

Так я там приводил примеры с графикой, когда на стеке по 4-5 и более чисел, и все то и дело нужны.

вопрос писал(а):

то же и тут - нужно ли мучить себя либо достаточно сложной факторизацией
кода или назвать локально

Но это самое "назвать локально" уже раздуто на несколько страниц без какого-то внятного вывода. Быстрее уже разобраться со "сложной факторизацией".

вопрос

Хищник писал(а):

Так я там приводил примеры с графикой, когда на стеке по 4-5 и более чисел, и все то и дело нужны.

Угу, и локальные переменные не зря

Я не могу лезть вперёд автора, это нетактично

Предположим, нам нужны локальные переменные... (см. тему Хищника - фрейм...)
предположим, мы факторизовали код так, что он состоит из "внешних" (вызываемых) слов.
внешним словам можно передавать что-либо через стек или через переменные
внешние (вызываемые) слова не могут обращаться к локальным переменным по именам
для вызова вызываемого слова, нужно дополнительно упорядочить стек для передачи параметров
или нужно сложить значения во внешние (нелокальные) переменные
всё, выделенное жирным требует дополнительного, нетривиального усилия.
Также всё выделенное жирным не только к себе требует усилий, но и усложняет код остальной

Локальные куски кода можно организовать так, чтобы обращаться к локальным переменным по-прежнему по именам
Это значит, что трудности, обозначенные жирным и курсивом, просто отсутствуют
Но при этом остаётся польза от факторизации (структурирования фактически) кода

т.е. имеем и структуру кода и отсутствие необходимости обслуживать эту структуру дополнительными стековыми или с памятью манипуляцими

chess

вопрос писал(а):

т.е. имеем и структуру кода и отсутствие необходимости обслуживать эту структуру дополнительными стековыми или с памятью манипуляцими

Это так. Но стек никуда не изчез и все что можно было делать на стеке все осталось.
То есть никаких ограничений применение локального именования кусков кода( тут кто-то про ограничения говорил) не вносит.

chess

Упрощение синтаксиса при вводе статических локально-именованных переменных( при исполнении выдают на стек свои адреса)

Код:

\ сначала из NOTFOUND убираем беготню по поиску слов в словарях в виде  vocname1::wordname ..
\ чем сильно ускоряем его работу 

\ так как в интерпретаторе NOTFOUND стоит раньше опознавания чисел, то оставим в нем только определение того,
\ что ненайденная лексема не является числом - пожалуй это все что от него требуется

: NOTFOUND ( a u -- )
  2DUP 2>R ['] ?SLITERAL CATCH ?DUP IF NIP NIP THROW ELSE RDROP RDROP THEN ;

\ генерация кода статических переменных с локальными именами
: NOTFOUND ( a u --  )
  2DUP + 1- C@ [CHAR] } <> IF NOTFOUND EXIT THEN
  2>R lhere @ 0= IF lvoc ERASE lvoc DROP lhere ! THEN
  2R> 1- lname, HERE BRANCH, >MARK 2 HERE
  HERE LIT, \ тело переменной
  >R RET, POSTPONE THEN R> SWAP !
  lhere @ CELL+ lhere ! ;

\ EOF

: S1 ( -- a1 a2)
v1} v2}
v1 v2  
l' v1  l' v2 ;

SEE S1 S1 HEX

log

Код:

CODE S1
5AED3F E90C000000       JMP     5AED50  ( S1+11  )
5AED44 8945FC           MOV     FC [EBP] , EAX
5AED47 B844ED5A00       MOV     EAX , # 5AED44
5AED4C 8D6DFC           LEA     EBP , FC [EBP]
5AED4F C3               RET     NEAR
5AED50 E90C000000       JMP     5AED61  ( S1+22  )
5AED55 8945FC           MOV     FC [EBP] , EAX
5AED58 B855ED5A00       MOV     EAX , # 5AED55
5AED5D 8D6DFC           LEA     EBP , FC [EBP]
5AED60 C3               RET     NEAR
5AED61 8945FC           MOV     FC [EBP] , EAX
5AED64 B844ED5A00       MOV     EAX , # 5AED44
5AED69 8945F8           MOV     F8 [EBP] , EAX
5AED6C B855ED5A00       MOV     EAX , # 5AED55
5AED71 8945F4           MOV     F4 [EBP] , EAX
5AED74 B844ED5A00       MOV     EAX , # 5AED44
5AED79 8945F0           MOV     F0 [EBP] , EAX
5AED7C B855ED5A00       MOV     EAX , # 5AED55
5AED81 8D6DF0           LEA     EBP , F0 [EBP]
5AED84 C3               RET     NEAR
END-CODE
( 70 bytes, 20 instructions )

 Ok ( 5AED44 5AED55 5AED44 5AED55 )

пс. Если будут напрягать записи v1 @, v1 !, то можно переопеределить q1( v1 @ ) q1!( v1 ! )
и читать q1, и писать q1!

Локальные слова

Кто сейчас на конференции