[scheme vs lisp] Область видимости переменных.

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

С другой стороны, динамические переменные могу обеспечить более высокий уровень гибкости, и вообще, динамические переменные одна из самых прикольных фишек CL ;)

Т.е., как бы, можно написать такой код на CL который нельзя написать на схеме вообще? Или на схеме, «фишки» завязанные на динамические переменные, реализовать можно, но с большими усилиями?

> Т.е., как бы, можно написать такой код на CL который нельзя

написать на схеме вообще?

Неправильная постановка вопроса, что значит нельзя написать вообще? Я не понял, что именно вас интересует ((

Динамические переменные это улучшенный вариант глобальных переменных, без свойственных им (глобальным переменным) недостатков и они могу (должны) рассматриваться как неявные аргументы. Вообще, вот: http://lisper.ru/articles/cl-vars

Какая разница можно или нельзя? Искаробки их нет, вот и весь разговор. «Можно реализовать» - это крайне слабый довод, это значит, что, скорее всего, никем и никогда это релизовано и использовано не будет.

>можно написать такой код на CL который нельзя написать на схеме вообще?

Это теоретический или практический вопрос? Если вопрос теоретический, то любой код на CL можно переписать на схеме.

Если вопрос практический, то существует довольно много кода, который проще и логичнее пишется с использованием динамической области видимости переменных. Переписать его на схеме можно, но ценой некоторого усложнения.

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

Да, зато в интерпретаторе на коленке динамическая область видимости реализуется просто, а статическую надо аккуратно делать.

> Динамическая область видимости это ужасно,

приводит к трудновылавлиаемым ошибкам

Это вы на основе собственного опыта говори (какого?)? Или там, решили абстрактно порассуждать? Практика как-бы ваши выкладки не подтверждает.

Да, зато в интерпретаторе на коленке динамическая область

видимости реализуется просто

Бу-га-га, вы, очевидно, совершенно не в теме.

В scheme есть динамические переменные.

Или на схеме, «фишки» завязанные на динамические переменные, реализовать можно, но с большими усилиями?

Динамическую видимость переменных даже в PHP можно сделать, в Scheme тем более:

(define-syntax binding*
  (syntax-rules ()
    [(_ () exprs ...) (begin exprs ...)]
    [(_ ((x y) bnds ...) exprs ...)
     (let ((tmp x))
       (set! x y)
       (begin0
         (binding* (bnds ...) exprs ...)
         (set! x tmp)))]))

(define *foo* (void))

(define (bar)
  (+ *foo* *foo*))

(binding* ((*foo* 333))
  (display (bar)))

binding без звездочки тоже делается легко, но кода будет побольше.

>Динамическую видимость переменных даже в PHP можно сделать, в Scheme тем более

У вас неправильный биндинг. Он как минимум не thread-safe, в отличие от CL'ных динамических переменных.

Да, зато в интерпретаторе на коленке динамическая область видимости реализуется просто, а статическую надо аккуратно делать.

А в компиляторе - строго наоборот.

Динамическая область видимости это ужасно

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

А так? (binding* не менял):

(define-syntax-rule (define-thread-local var)
  (begin 
    (define storage (make-hash))
    (define-syntax var
      (syntax-id-rules (set!)
        ((set! var val) (hash-set! storage (current-thread) val))
        (var (hash-ref storage (current-thread) (void)))))))

(define-syntax binding* 
  (syntax-rules () 
    [(_ () exprs ...) (begin exprs ...)] 
    [(_ ((x y) bnds ...) exprs ...) 
     (let ((tmp x)) 
       (set! x y) 
       (begin0 
         (binding* (bnds ...) exprs ...) 
         (set! x tmp)))])) 
 
(define-thread-local *foo*)  

(define (bar) 
  (+ *foo* *foo*)) 
 
(binding* ((*foo* 333)) 
  (display (bar)))

В схеме есть fluid-let, правда, это нестандарт. Есть он, насколько я понимаю, во всех схемах, которые используют макроэкспандеры на базе psyntax (http://ikarus-scheme.org/r6rs-libraries) и не только в них.

Про fluid-let можно прочитать тут: http://www.scheme.com/tspl3/control.html#./control:s43

А, в альтернативном экспандере для R6RS (http://www.het.brown.edu/people/andre/macros/) тоже есть fluid-let.

Насколько я понимаю, все реализации R6RS используют либо тот, либо этот экспандер.