Forth
http://fforum.winglion.ru/

Что же касается средств управления потоком интерпретации
http://fforum.winglion.ru/viewtopic.php?f=36&t=1786		 Страница 3 из 5
Автор:  mOleg [ Вт дек 23, 2008 17:07 ]
Заголовок сообщения: 
как и обещал набросок кода(для SPF4.19):

<pre>
\ 22.12.2008 ~mOleg
\ Сopyright [C] 2008 mOleg mininoleg@yahoo.com
\ набросок новой структуры управления трансляцией входного потока

\ слово берет очередную лексему из входного потока до тех пор, пока он
\ не исчерпается.
: NEXT-WORD ( --> asc # | asc 0 )
BEGIN NextWord DUP 0 = WHILE
DROP REFILL DUP WHILE
2DROP
REPEAT
THEN ;

WORDLIST CONSTANT cmwl \ словарь для хранения имен обработчиков

\ пропускать все лексемы до того момента, пока не найдется лексема из cmwl
: findcmd ( --> )
BEGIN NEXT-WORD DUP WHILE
cmwl SEARCH-WORDLIST 0 = WHILE
REPEAT EXECUTE EXIT \ слово найдено
THEN -1 THROW ; \ не встретилось управляющее слово

USER-VALUE _state \ сохраняет STATE на момент запуск [IF

\ открыть условную конструкцию управления входным потоком
: [IF ( --> )
STATE @ TO _state
[COMPILE] [
ALSO cmwl CONTEXT !
; IMMEDIATE

ALSO cmwl CONTEXT ! DEFINITIONS

\ выбрать в заивисимости от значения флага либо пропуск текста до [ELSE]\[THEN]
\ либо трансляцию текста до [ELSE]\[THEN]
: [ELSE] ( flag --> ) IF FALSE ELSE TRUE findcmd THEN ; IMMEDIATE

\ выполняет то же, что ELSE, предварительно востановив STATE
: ] ( flag --> ) _state STATE ! [COMPILE] [ELSE] ;

\ завершает конструкцию управления трансляцией входного потока
: [THEN] ( flag --> ) PREVIOUS DROP ; IMMEDIATE

\ коментарий до конца строки
: \ ( flag --> )
[COMPILE] \
DUP IF findcmd THEN ; IMMEDIATE

PREVIOUS DEFINITIONS

\ а это тесты

: test [IF FALSE ] ." aaa " [ELSE] ." bbb " [THEN] ." ccc " ;
: tst [IF TRUE ] ." aaa " [ELSE] ." bbb " [THEN] ." ccc " ;
: tes [IF FALSE ]
." aaa "
\ [ELSE]
." bbb "
[THEN] ." ccc " ;

: ts [IF TRUE ]
." aaa "
\ [ELSE]
." bbb "
[THEN] ." ccc " ;



\EOF
другой вариант - использовать EVALUATE то есть:

: [IF ( --> flag )
[CHAR] ] PARSE EVALUATE
IF продолжить трансляцию
ELSE пропустить текст вплодь до [ELSE] или [THEN]
THEN
;

Недостаток такой реализации в том, что закрывающая скобка должна находиться в той же строке,
где и [IF .

</pre>
Автор:  mOleg [ Вт дек 23, 2008 17:16 ]
Заголовок сообщения: 
figwam писал(а):
Во первых, более логично и фортово: "[ ... ] [IF]" --> "[ ... IF]"
А во вторых, для открывающей скобки достаточно запомнить только текущий STATE
Код:: [  STATE @ STATE-PREV ! POSTPONE [ ; IMMEDIATE
: IF] STATE-PREV @ STATE ! POSTPONE [IF] ; IMMEDIATE


сначала хотел вам резко возразить, потом понял, что вы в некотором смысле правы ;) только не надо менять поведение открывающей скобки, достаточно использовать существующую. Но! сразу возникает проблема: как узнать в каком режиме была система перед выполнением открывающей скобки?
VoidVolker писал(а):
сиво, а в реальности предется следить за тем, чтобы не забыть поставить закрывающую скобку!

VoidVolker писал(а):
А зачем менять поведение открывающей скобки? Переход в режим интерпретации все-равно происходит. А дальше просто использовать стандартные для режима интерпретации [IF] [ELSE] [THEN]. А то получается, что есть аш три вида управляющих конструкций для двух режимов. Зачем? Вот оно это самое усложнение, про которое я говорил.

это так кажется, пока не сталкиваешься с проблемой.
На самом деле несколько более простых и однозначных слов, лучше, чем более сложное но одно.
[IF] стандартный не удобен.
про открывающую скобку уже писал.

VoidVolker писал(а):
2. Я утверждаю, что нет никакой необходимости вводить в стандарт третий вид уравляющих конструкций, и считаю их переусложненными.

я тоже не утверждаю этого. На сколько помню тема была начата там, где речь шла об обычных коментариях.
Я же предложил не рассматривать коментарии отдельно от слов, позволяющих управлять трансляцией входного потока!
То есть это одна група слов. И в моей классификации это группа третьего уровня ;)
Автор:  mOleg [ Вт дек 23, 2008 17:29 ]
Заголовок сообщения: 
WingLion писал(а):
Вспомнил, кстати, одну конструкцию, которую использовал в исходниках для "условной компиляции" (в "СвоемФорте")
Код: : SP> SYS-ID NOT IF [COMPILE] \ THEN ; IMMEDIATE \ for Sprinter only commands
 : PC> SYS-ID IF [COMPILE] \ THEN ; IMMEDIATE     \ for PC only commands
слово SP> попросту запрещает интерпретацию/компиляцию всего, что стоит за ним в строке, если SYS-ID не соответствует условию
слово PC> - аналогично - попросту запрещает интерпретацию/компиляцию всего, что стоит за ним в строке, если SYS-ID соответствует условию.

у меня немного другая конструкция используется в форке:
<pre>
: (conclude) ( --> )
trg{ LAST @ }
img{ LATEST }
DUP IF HERE OVER to_link off_code A@ - SWAP to_flag off_eow W!
LAST OFF
ELSE DROP
THEN ;
</pre>
слова trg{ ... } до закрывающей скобки и img{ ... } в зависимости от того, при каких условиях происходит компиляция выбирают текст внутри себя.
Но подход достаточно грубый и неуниверсальный. Поэтому мысли продолжают крутиться вокруг этих вопросов.

WingLion писал(а):
Вводить нечто подобное в стандарт - не вижу смысла, так как это просто "часть программы пользователя", при чем такая часть, которая в целевой программе даже не обязана присутствовать

тут есть над чем подумать. В стандарт оно может и нет надобности вводить, но, например, если у нас есть несколько уровней поддержки того же стандарта, то даже для компиляции кода в соответствие с заданным уровнем надо иметь какие-то вспомогательные средства.
А стандартный [IF] убог и неудобен. И самое главное, что он работает по-разному при разных STATE, что на мой взгляд неудачно
в то же время [IF expression ] ... будет одинаково работать в разных режимах.
и еще остается вопрос того, как совместить все слова, управляющие потоком, потому что сейчас, к примеру, следующий код:
<pre>
FALSE [IF] .( aaaa)
\ [ELSE] .( bbbb)
[THEN]
</pre>
распечатает bbbb
но по логике вещей слово \ - должно закоментировать [ELSE] и на экран bbbb попасть не должен.
Это промах, и его надо лечить. В ANSI этому моменту внимания не уделено.
Автор:  WingLion [ Вт дек 23, 2008 17:52 ]
Заголовок сообщения: 
mOleg писал(а):
тут есть над чем подумать. В стандарт оно может и нет надобности вводить, но, например, если у нас есть несколько уровней поддержки того же стандарта, то даже для компиляции кода в соответствие с заданным уровнем надо иметь какие-то вспомогательные средства.


спору нет


mOleg писал(а):
А стандартный [IF] убог и неудобен. И самое главное, что он работает по-разному при разных STATE, что на мой взгляд неудачно


Видимо, это из стандарта ANSI94, в 83-м, вроде бы нет такого слова.

"из песни слов не выкинешь", в 94-м стандарте это слово останется, а в новом надо продумывать, что нужно, а что нет.
Хотя, опять же, я стою на той позиции, что продумать все-все-все на все случаи жизни - нереально и невозможно.
Потому и предлагаю особо не заморачиваться, чтобы не увязнуть на мелочах.


mOleg писал(а):
в то же время [IF expression ] ... будет одинаково работать в разных режимах.


думаю, это не единственный вариант реализации, наверняка есть что-то еще.


mOleg писал(а):
и еще остается вопрос того, как совместить все слова, управляющие потоком, потому что сейчас, к примеру, следующий код:

<pre>

FALSE [IF] .( aaaa)
\ [ELSE] .( bbbb)
[THEN]
</pre>

распечатает bbbb
но по логике вещей слово \ - должно закоментировать [ELSE] и на экран bbbb попасть не должен.
Это промах, и его надо лечить. В ANSI этому моменту внимания не уделено.


Проблема имхо, скорее, в неправильной реализации.
\ - должно просто отбросить все, что стоит за ним, и у Форта не должно быть даже возможности увидеть ".( bbbb)"
Автор:  mOleg [ Вт дек 23, 2008 18:01 ]
Заголовок сообщения: 
WingLion писал(а):
mOleg писал(а):в то же время [IF expression ] ... будет одинаково работать в разных режимах.
думаю, это не единственный вариант реализации, наверняка есть что-то еще.

варианты-то есть, но они на мой взгляд хуже.
Предложенный вариант имеет следующие преимущества:
1) интуитивно понятен
2) одинаково работает в любом состоянии системы (компиляция\интерпретация)
3) не перетяжелен синтаксическими особенностями.
Автор:  Hishnik [ Вт дек 23, 2008 19:19 ]
Заголовок сообщения: 
А ничего, что expression требует отдельного, особого механизма разбора? И чего тут интуитивно понятного? Интуиция у всех разная, фортеры привыкают к постфиксу, и к тому, что есть просто слова, и есть immediate, генерирующие какой-то код управления. Заводить исключения из правил себе дороже - промучавшись, можно с усилиями впихнуть в систему конструкцию для использования только ее автором, и то пока оно свежо в памяти. А конструкции условной трансляции вообще нечего тиражировать, если в программе они наворочены сверх всякой меры - значит, писал не программист, а кулхацкер, которому сам процесс красивого кодинга и возможность сбегать к приятелю похвастаться вычурным кодом важнее результата.
Автор:  вопрос [ Вт дек 23, 2008 20:54 ]
Заголовок сообщения: 
Хищник писал(а):
А ничего, что expression требует отдельного, особого механизма разбора? И чего тут интуитивно понятного? Интуиция у всех разная, фортеры привыкают к постфиксу, и к тому, что есть просто слова, и есть immediate, генерирующие какой-то код управления. Заводить исключения из правил себе дороже - промучавшись, можно с усилиями впихнуть в систему конструкцию для использования только ее автором, и то пока оно свежо в памяти. А конструкции условной трансляции вообще нечего тиражировать, если в программе они наворочены сверх всякой меры - значит, писал не программист, а кулхацкер, которому сам процесс красивого кодинга и возможность сбегать к приятелю похвастаться вычурным кодом важнее результата.

Я думаю, нет, сначала немного психологии: интуитивное восприятие чего-либо имеет обьективную и субьективную стороны, и кое-что нельзя преодолеть никакой привычкой или можно но вредно (можно переучить левшу, но ему всегда неудобно).
Расширение набора конструкций управления потоком интерпретации видимо, логично для языка, который претендует на расширяемость. По логике, таковые в расширяемом языке должны быть представлены лучше, чем в обычном, однако на деле всё наоборот - сколько однако таких конструкций в С++ и сколько в форте?
Автор:  mOleg [ Ср дек 24, 2008 00:13 ]
Заголовок сообщения: 
Хищник писал(а):
А ничего, что expression требует отдельного, особого механизма разбора?

ничего подобного. Expression - это обычное форт-выражение, возвращающее флаговое значение, например:
[IF lang @ rus = ] тут у нас русский язык [ELSE] ну, тогда английский [THEN]

Хищник писал(а):
И чего тут интуитивно понятного?

в Форте в квадратных скобках идут слова немедленного исполнения: [COMPILE] ['] [IF] и подобные, либо переключается режим интерпретации.
Автор:  mOleg [ Вс янв 04, 2009 18:44 ]
Заголовок сообщения: 
пришли в голову некие требования к словам управляющим трансляцией входного потока:
<pre>
1) слова управляющие потоком трансляции не должны зависеть от состояния переменной STATE!

поэтому, например слова ( \ можно считать удачными, а
[IF] \EOF неудачными

2) слова управляющие трансляцией входного потока должны знать о существовании друг друга

0 [IF] .( aaaaA)
\ [ELSE] .( bbbbb)
[THEN]
не должен выдавать ничего!, хотя в реальности исполнит ветку [ELSE]

3) обсуждаемые слова должны исполняться однозначно!
пример выше тоже к этому относится
</pre>
Автор:  WingLion [ Вс янв 04, 2009 18:56 ]
Заголовок сообщения: 
с 1 и 3 согласен.

с 2 - нет.
Слова из разных конструкций должны быть независимы и делать именно то, что они делают.

Состояние включенной/выключенной трансляции не должно задаваться какой-либо переменной типа STATE для компиляции/ интерпретации.
Выключение трансляции должно быть физическим.

Если \ выключает трансляцию потока до конца строки, то последующие слова должны быть напрочь отброшены, а не передаваться куда-то, где "какой-то [ELSE] может передумать" и включить трансляцию обратно.
Автор:  mOleg [ Вс янв 04, 2009 18:58 ]
Заголовок сообщения: 
WingLion писал(а):
с 2 - нет.

Слова из разных конструкций должны быть независимы и делать именно то, что они делают.

Если \ выключает трансляцию потока до конца строки, то последующие слова должны быть напрочь отброшены, а не передаваться куда-то, где "какой-то [ELSE] может передумать" и включить трансляцию обратно.

именно о том и речь!
текст должен читаться однозначно: если перед [ELSE] стоит коментарий, то он должен работать так же, как если бы он стоял перед [IF] а для этого эти слова и должны знать о существовании друг друга. Тут "знать" стоило бы взять в кавычки, потому что в действительности речь идет лишь о необходимости однозначного поведения всех слов управляющих трансляцией, каким образом она будет достигнута - совсем другой вопрос.
Автор:  Hishnik [ Вс янв 04, 2009 19:04 ]
Заголовок сообщения: 
Зачем словам знать о существовании друг друга, чтобы "отключать все"? Если \ означает "игнорировать текст до конца строки", то это исчерпывающее описание.
Автор:  mOleg [ Вс янв 04, 2009 19:06 ]
Заголовок сообщения: 
Хищник писал(а):
Зачем словам знать о существовании друг друга, чтобы "отключать все"? Если \ означает "игнорировать текст до конца строки", то это исчерпывающее описание.

еще раз, речь лишь о том, что оно должно ВСЕГДА работать, а не только в конкретных случаях, как это сейчас есть (по стандарту).
Автор:  WingLion [ Вс янв 04, 2009 19:15 ]
Заголовок сообщения: 
mOleg писал(а):
текст должен читаться однозначно: если перед [ELSE] стоит коментарий, то он должен работать так же, как если бы он стоял перед [IF] а для этого эти слова и должны знать о существовании друг друга. Тут "знать" стоило бы взять в кавычки, потому что в действительности речь идет лишь о необходимости однозначного поведения всех слов управляющих трансляцией, каким образом она будет достигнута - совсем другой вопрос.


Думаю, неоднозначность поведения в данной ситуации надо искать в том, что 0 [IF] запрещает трансляцию всего-всего до [ELSE], т.е. \ отбрасывается и не срабатывает, а работает то, что после [ELSE]

это просто непродуманность в действиях вводимых слов. Так можно навертеть черте-что, что все запутается в конец.

Чтобы такого не было, надо чтобы слова управляющие трансляцией имели общий синтаксис, например, их действие должно заканчиваться переводом строки. и конструкция с [IF] [THEN] [ELSE] должна быть в одной строке, чтобы не конфликтовать с другими конструкциями.

p.s. думаю, что конструкция [IF] [THEN] [ELSE] сама по себе неудачна
Автор:  WingLion [ Вс янв 04, 2009 20:04 ]
Заголовок сообщения: 
Короче, отсюда мораль: неудачные [IF] [THEN] [ELSE] из стандарта надо исключить.

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