Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 03:49

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу Пред.  1, 2, 3, 4  След.

Форт развивается. Стоит ли использовать новые диалекты?
Плевать на диалекты, мне С-стиля программирования хватает! 0%  0%  [ 0 ]
Я сделал расширение Форта до ... и мне этого хватает! 13%  13%  [ 2 ]
Конечно! Люблю использовать последние достижения! 38%  38%  [ 6 ]
А что, это действительно эффективно? 25%  25%  [ 4 ]
Я вообще Форт не использую! 0%  0%  [ 0 ]
Другое. Опишите свой вариант в форуме. 25%  25%  [ 4 ]
Всего голосов : 16
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Ср янв 31, 2007 00:53 
Я реализовывал поверх SPF три вида colorForth'а. Все они являются "бесцветными", то есть не нуждаются в особом формате для обозначения цвета, и пишутся обычным текстом.

~profit/lib/colorForth/loveall.f:
Код:
\ Реализация со словами-цветами-префиксами
...
: square  ] DUP  ] *  ;
: 2x2  2 n  ] square  ] . ;
2x2


~profit/lib/colorForth/colorSP4th.f (привожу код в порядок, пока недоступно)

Код:
\ Что делать со "словом" (точнее говоря строкой), определяется последней буквой
\ См. также ~profit\lib\loveall.f

\ square: DUP, *.
\ 2x2: 2d; square, typeNumber.
\ 2x2

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

\ Через это возникает интересная возможность "перехвата" режимов.
\ Например, определив слово "SWAP," можно задать действия по компиляции
\ SWAP. При этом само слово "SWAP" остаётся незадетым.

\ Хвостовая оптимизация имеет место.


\ определение:  1d; typeNumber,    <--- CREATE определение 1 LIT, COMPILE .
\ определение2: 2d; typeNumber,    <--- CREATE определение 2 LIT, COMPILE .
\ определение3: 3d; typeNumber, .    <--- CREATE определение 3 LIT, COMPILE . RET,
\ определение3: 3d; typeNumber.    <--- CREATE определение 3 LIT, ' . BRANCH,


~profit/lib/colorForth/photon.f:
Код:
\ На этот раз для обозначения режима используются разметка и
\ отступы (при этом отступы работают также визуально видимым
\ control-flow стеком).

\ Интерпретация идёт построчно. Если строка начинается с пробела,
\ значит её нужно исполнить. Если строка начинается с табуляции,
\ то компилируем и выполняем действия из массива табуляций.
\ Во всех остальных случаях строки считаются определением, тогда
\ из строки берётся первое слово и создаётся для него словарная
\ статья, прочая часть строки игнорируется.

\ Сделано оно это для более лёгкого "мимолётного" чтения текста,
\ когда к левому краю всегда прижимаются только имена определений
\ а все структуры управления (включая сами определения) имеют
\ подчёркнуто отступно-коробчатый вид.

\ Кстати, мне самому смотреть такой код не очень нравится... Вид у
\ кода какой-то жидкий становится, редкие-редкие такие островки
\ буквочек "на белой простыне" (с)...
...


2x2.
   2 2 * . return      Обратите внимание что после слов control-flow можно писать всё что угодно...

CR .( 2x2. ) 2x2.


test
   DUP 2 MOD 0= if    Чётные числа выводим, нечётные -- пропускаем
         DUP .
   DROP
   return

CR .( 1 test ) 1 test
CR .( 2 test ) 2 test

1-10. ( -- )                    Напечатать числа от 1 до 10-и
   10 0 do         Цикл от одного до десяти
      I 2 MOD 0= if   Чёт-нечёт
            I .
   return

CR .( 1-10. ) 1-10.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср янв 31, 2007 20:49 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
А я сделал 2 интерпретатора - исполнения и компиляции и словами [ ] перехожу между ними. : перед словом добавляет имя в словарь как адрес в коде и дальше включает режим компиляции.

А цвета использую так:
Код:
0   extension      ничего
1   execute yellow      [ ] в скобках
3   define red      : перед словом
4   compile green      ничего
7   compile cyan      ', перед словом
9   comment white      ( ) \
a   Capitalized white   -"-
b   all caps white      -"-
c   variable magenta   var перед словом

реализация
[ - передать управление на интерпретатор выполнения (yellow)
], - скомпилировать число со стека и передать управление на
      цикл компиляции (green)

Синтаксис похож на обычный, :, как обычно, начинает определение и переключает в режим компиляции, дополнительные переключения режимов компиляция/интерпретация, как обычно, [ ]. Добавляется только ],, все остальное сохраняется привычное.
Только стиль должен быть другой... ;)

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

Самый лучший вариант компилятора сделан на Perl5. Пока сам себя скомпилировать не может, поэтому я считаю его не готовым. Но по запросу вышлю.
Были еще предыдущие ветки - одна даже на SPF.
Не продолжались, т.к. разработку делал на 486-м ноуте, а там нет виндов... :(
Поэтому DOS+Perl... :(

_________________
With best wishes, in4.


Последний раз редактировалось in4 Вт сен 18, 2007 14:42, всего редактировалось 1 раз.

Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вт мар 27, 2007 20:17 
~profit/lib/colorForth/photon.f:

Код:
\ Факториал на цикле. Хотя в colorForth'ах циклы
\ вырождаются в сочетание if'а (даже без else),
\ хвостовой оптимизации (она же -- GOTO) и
\ каскадных определений (они же -- метки).
\ Эдакое назад в будущее...

fact ( n -- fact(n)
   1 SWAP                \  Ставим аккумулятор на стек внутренней функции
fact0 ( acc n )                  Это можно рассматривать и как функцию и как метку
   ?DUP 0= if               Краевой случай "рекурсии" (он же условие выхода из цикла)
      return
   TUCK * SWAP 1-
   fact0 return             Это GOTO fact0 , по-сути

CR 6 DUP .  .( fact=) fact .


Вывод:
Код:
6 fact= 720


Is it a plane? Is it a bird?.. No, it is .. colorForth!


Последний раз редактировалось profiT Чт мар 29, 2007 20:00, всего редактировалось 1 раз.

Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вт мар 27, 2007 23:16 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
А вот мой вариант - на CLCF:
Код:
: tuck ( x1 x2 -- x2 x1 x2 )  \ добавить слово, которого не было... ;)
   swap over ;

\ : добавляет слово в словарь как адрес в коде, точку входа (для вызова/перехода)
\ словари размещены в отдельном пространстве, и заголовок слова не компилируется
\ в кодофайл, поэтому можно определять слово прямо среди кода, можно сделать подряд
\ несколько "определений", которые используют следующие, т.о. экономится вызов слова
: fact ( n -- fact(n)
   1 swap
: fact0 ( acc n )
   test ifz drop ; then  \ выход из цикла, ifz неразрушаюций
   tuck * swap 1-
   fact0 ;  \ хвостовая рекурсия

Вариант, который мне бОльше нравится:
Код:
: fact ( n -- fact(n)
   1 swap
   begin ( acc n )
      test ifz drop ; then  \ выход из цикла, ifz неразрушаюций
      tuck * swap 1-
      again


А вот код в 16-разрядном .com -файле
Код:
00: 8704                         xchg      ax,[si]
02: 8D74FE                       lea       si,[si][-0002]
05: 8904                         mov       [si],ax
07: 8B4402                       mov       ax,[si][00002]
0A: C3                           retn
0B: 8D74FE                       lea       si,[si][-0002]
0E: 8904                         mov       [si],ax
10: B80100                       mov       ax,00001 ;" ☺"
13: 8704                         xchg      ax,[si]
15: 85C0                         test      ax,ax
17: 7502                         jne       00000001B   -------- (1)
19: AD                           lodsw
1A: C3                           retn
1B: E8E2FF                       call      000000000   -------- (2)
1E: F72C                         imul      w,[si]
20: 8D7402                       lea       si,[si][00002]
23: 8704                         xchg      ax,[si]
25: E80AEA                       call      00000EA32
28: E9EAFF                       jmp       000000015   -------- (3)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт мар 29, 2007 11:25 
Пример с begin again неплох, но как-то не по colorForth'овски, как мне кажется... То что в CF можно обходится только одним if .. then мне как-то чисто эстетически больше трафит (никаких других обоснований "против" begin .. again нет).

И вот что я забыл: условные конструкции (и лог. операции) анализирующие не вершину стека, а флаг процессора! Тут правда вопросец, насколько это приложимо к SPF...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт мар 29, 2007 12:28 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
profiT писал(а):
Пример с begin again неплох, но как-то не по colorForth'овски, как мне кажется... То что в CF можно обходится только одним if .. then мне как-то чисто эстетически больше трафит (никаких других обоснований "против" begin .. again нет).

А мне begin-again нравятся больше - не надо придумывать дополнительных (нужных только для органицации одного цикла) слов! Не занимается словарь (а в CF словарь не такой уж бОльшой)!
И при переименовании слова код можно не трогать!
Такой получается "безымянный" цикл... ;)
И begin-again я сделал на одной переменной (16-разрядный код):
Код:
var (begin)
macro
: begin  here (begin) ! ;
: again  E9 1,  (begin) @ here -  2 - 2, ;

По-моему, простота вполне себя оправдывает...
А с учетом того, что в слове м.б. несколько again, получаются неплохие исходники... :)
profiT писал(а):
И вот что я забыл: условные конструкции (и лог. операции) анализирующие не вершину стека, а флаг процессора! Тут правда вопросец, насколько это приложимо к SPF...

Приложимо, если слова, оставляющие флажок и анализирующие, ставить подряд.
И эти слова м.б. и не SPF-овские. Т.е. среди кода SPF будет еще код CF.

Кстати, в CF неплохой оптимизатор! ;) Я такой уже себе сделал! :) Для 16 разрядов... :(
Уже заметил, что бы еще хотелось оптимизировать, но так красиво, как в CF, уже не выйдет... :(
М. применять внешний оптимизатор?

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт мар 29, 2007 16:55 
in4 писал(а):
А мне begin-again нравятся больше - не надо придумывать дополнительных (нужных только для органицации одного цикла) слов! Не занимается словарь (а в CF словарь не такой уж бОльшой)!

Это да, создаются как бы лишние слова. Только я уже упоминал что я воспринимаю все слова в colorForth'е скорее как метки (идентификаторы)? Поэтому к созданию лишних отношусь гораздо легче.

А то что допустим в оригинальном CF словарь небольшой, так это ко мне не относится -- у меня словарь спроецирован в хэш (средствами ~profit/lib/colorForth/cascaded.f).

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

Да и собственно я совсем не мучаюсь над придумыванием названий для слов-меток: как и показал в примере, называю: word0 , word1 , word2 и т.д. Мур тоже так делает. От коллизий по именам это должно сберечь.

(через часик... прокрутив в голове несколько вариантов...)

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

И тут дальше два варианта:

Ограничивать область видимости внутренних слов только одним словом (при следующем определении внешнего слова, метки, записываемые в отдельный словарь, убиваются). Через это даже мой пример с факториалом никак менять не нужно -- всё сделается правильно: fact0 убъётся, fact останется.

Ограничивать область видимости в пределах "модуля"-лексикона. Границы нужно будет поставить программисту. Для задания границ модуля можно использовать marker и empty. Хотя тогда их смысл меняется (и marker , и empty используются в CF), что не очень хорошо. Тогда можно и назвать по-другому.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт мар 29, 2007 19:12 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
А можно сделать третий словарь, для меток внутри блока, который и чистить empty?
И добавлять туда другим словом, в твоем случае можно и : ...
Что ты по этому поводу думаешь?
А так - я за первый твой вариант. По смыслу это оно - метки для локальных переходов.
Если нужно переходить издалека - определяй обычную точку входа! :)
Единственный недостаток - еще более редкий код... ;)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт мар 29, 2007 19:51 
in4 писал(а):
А можно сделать третий словарь, для меток внутри блока, который и чистить empty?
И добавлять туда другим словом, в твоем случае можно и : ...
Что ты по этому поводу думаешь?

Я именно про это и говорю, что в первом, что во втором варианте. Просто разница в оформлении.

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


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср апр 11, 2007 15:41 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Вот подумалось, что часть эффективности ColorForth-а можно получить и в SPF, если добавить правил в оптимизатор.
Но то, что profit называет каскадными определениями, а я бы сказал, цепочечными - так просто в SPF не получится... :( А использование их поменяет взгляд на программирование (парадигму)... ;)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср апр 11, 2007 21:38 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
in4 писал(а):
Вот подумалось, что часть эффективности ColorForth-а можно получить и в SPF, если добавить правил в оптимизатор.
Но то, что profit называет каскадными определениями, а я бы сказал, цепочечными - так просто в SPF не получится... А использование их поменяет взгляд на программирование (парадигму)...

Я уже не раз писал в форуме о принципе раннего связывания имен и кода в Форте, как об основной причине тормозного характера форт-кода. В CF Мур ни на йоту не отступил от этого принципа. Стало быть принципиальных шагов в направлении ускорения исполнимого кода, создаваемого форт-транслятором в CF сделано не было. А что касается введения флагового(а не стекового) IF(и убирания ELSE), упразднения DOES> и STATE, реализации хвостовой рекурсии, циклов FOR-NEXT, множественных выходов, использования цепочечных операций при поиске слов(кстати в СПФ это тоже используется), другом формате словаря и заголовков словарных статей(ускорение поиска), про цвета говорить не буду(может я дальтоник) - это все в основном доводочная работа(шлифовка, использование незамеченных/неиспользованных ранее возможностей процессора реальной машины) в рамках все той же эмуляции виртуальной форт-машины на реальной машине, архитектура которой сильно отличается от машины-наездника(ф-машины), основанная на том же принципе раннего связывания кода с именами, который в свою очередь использован для упрощения разработки транслятора. Да, такой принцип даст быстрый код - но только на платформе по архитектуре близкой к принятой архитектуре форт-машины.
Пониманию изложенного может помочь такая аналогия - предположим мы имеем машину, команды которой формируются микропрограммно, то есть каждая команда машины разворачивается на микропрограммном уровне как определенная последовательность микрокоманд. Если у нас есть доступ только к командам мы и напишем программу в виде последовательности команд. Но если у нас есть доступ к микрокомандам, то мы можем написать эту же программу в виде последовательности микрокоманд. В первом и во втором случае вся программа будет представлять две разных последовательности микрокоманд. Теперь вопрос: на каком уровне командном или микрокомандном можно получить более быстрый микрокомандный код программы? Ответ очевиден - конечно на микрокомандном(на этом уровне не будет лишнего кода, на командном уровне этот излишек кода неминуемо появится - я называл это люфтом в коде, так как число команд ограничено). Принцип раннего связывания кода с именами как раз и "формирует" набор команд(форт-примитивов), а дальше программист на них и пишет программу. Транслятору не дано выйти на уровень микрокоманд(команд реального процессора) он кладет форт-примитивы друг за другом как это делает ассемблер с командами машины. Все - дальше уже неинтересно. Ясно одно - надежно заложен принцип формирования тормозного кода. Сейчас оптимизатор как раз развязывает этот связанный тормозной код и кладет по новой, но уже другой код - с меньшим люфтом.
Вопрос - а зачем связывать, чтобы потом развязывать? Но это уже другая песня.:)

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт апр 12, 2007 01:16 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
chess писал(а):
Сейчас оптимизатор как раз развязывает этот связанный тормозной код и кладет по новой, но уже другой код - с меньшим люфтом.
Вопрос - а зачем связывать, чтобы потом развязывать? Но это уже другая песня.

Для SPF это так. CF не делает этой перегенерации. Ну, разве что во время компиляции. Реально откатывается только один примитив. Максимум можно сделать два. Второй у Мура пока не откатывается из-за ошибки в дизайне. Но всех устраивает быстродействие! То, что устараивает - как раз и причина создания "тормозного" кода. Его быстродействия достаточно.
Форт - это язык проектирования. Он может быть не эффективным. Но должен быть более-менее удобным. Мур его минимизировал. Он молодец! Это как концепт-кар или модная одежда. Ты это в жизни использовать вряд ли будешь, но идеи - идеи куда-то, да приткнешь! И он пошел даже дальше! Он использует свою разработку (правда, похоже, в основном только он ;) ) в своей работе!
Я пока хочу повторить результат Мура. Чуть улучшить его.
Оптимизация - это уже другая задача. Если у Мура вся его работа в уме, я за него ооочень рад. У меня так не получается. Поэтому хочется, чтоб комп сделал мне иллюстрацию, как все будет выглядеть, если взглянуть с другой стороны. Повертеть. Переставить.
А уж потом результат можно оптимизировать! Вот тут-то и нужно то, что ты предлагаешь! Да, твоя идея хороша... Но меня пока устраивает вариант попроще - как в CF... Хотя я и на него не сразу согласился - хотел еще проще. Потом посмотрел его код внимательно, посмотрел на свой - и сел делать, вариант посложнее, как у Мура, но для моей задачи. Времени ушло на удивление много. Причем основное - на проверки! :( Теперь уже на горизонте (после еще нескольких этапов) маячит создание IDE. А там уж и оптимизация. Дерева программы с учетом набора примитивов. Для PC это ассемблер/машинный код.
А пока у меня исходник компилятора меньше 30Кб и я не хочу его сильно раздувать. Меньше код - меньше искать в нем нужное место! ;)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт апр 12, 2007 01:19 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
А вот чего в SPF нет, а в CF есть - множественные входы, т.е. цепочные или каскадные определения!

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт апр 12, 2007 12:04 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
in4 писал(а):
Он может быть не эффективным.

Почему может быть. Он и есть неэффективный (в части быстродействия выходного кода). Я думаю СПФ в этой части эффективнее CF(из-за оптимизатора - отсюда вывод: развитие оптимизатора дало Форту больше, чем все новшества Мура в CF - в части быстродействия конечно), даже без введения в него всех новшеств CF(хотя это сделать не сильно трудно и для СПФ - вопрос: а надо-ли?). Удобство языка в большей мере это вещь субъективная, неудобство в данном контексте это синоним трудности использования. Когда станет привычным - станет нетрудным, а затем и удобным. Есть в языках и объективные неудобства - например манипуляция большим числом параметров на стеке вещь объективно неудобная, так как входит в противоречие с небольшим объемом кратковременной памяти человека(так Мур в этой части лаконичен до минимума). Насчет повышения выразительных возможностей Форта в его CF-реализации - ничего сказать не могу, не пробовал программировать на нем, но думаю, что революции тут не произошло.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт апр 12, 2007 13:20 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
chess писал(а):
Я думаю СПФ в этой части эффективнее CF

Сделаю 32-битный вариант - будем смотреть. А на крайняк, оптимизатор можно привертеть и к CF ! :) Пардон, добавить расширением... ;) Но я его все равно собираюсь рефакторизовать, хотя внимательно на исходники смотрел давно, может, что-то поменялось...
То, что предлагаешь ты, больше похоже на глобальную оптимизацию. Я от нее ни в коем случае не отказываюсь - просто займусь этим позже. И все это время буду посматривать за ее развитием!
chess писал(а):
Насчет повышения выразительных возможностей Форта в его CF-реализации - ничего сказать не могу, не пробовал программировать на нем, но думаю, что революции тут не произошло.

А ты попробуй! :) Правда, традиционным программистам требуются значительные усилия, чтобы понять... Программирование на рекурсиях не так и просто. Но дело привычки. Хотя мне больше нравится выделять циклы.
И еще - часть оптимизаций становится естественными для CF . А в SPF это скрыто оптимизатором. Мур, да и Броуди, хотели, чтобы было соответствие слово языка - машинный код. CF более соответствует такому, чем SPF+оптимизатор.
В моих первых версиях была только оптимизация хвостовой рекурсии. Вполне хватало. Было просто. Не знаю, что на меня нашло - наверное, 3х экранный компилятор простым показался... ;) На первый взгляд. А как я начал решать задачи - стало ясно, что нужно еще и еще! И изначальная 32-битовость позволяет сделать несколько дополнительных упрощений... А у меня - 16 :(

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу Пред.  1, 2, 3, 4  След.

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


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 22


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

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