[Chicken-users] interpreter/compiler mismatch

[address@hidden]

Hi Felix and happy Chicken users,

here is some feedback I had in my hard drive, which was waiting for a
favorable moment to be posted ;-). I would be  curious to know what others
think about the following issues.

1. First of all, I don't particularly like the fact that the interpreter
magically includes modules, so

(pp '(1 2 3))

works in the interpreter but in the compiler I must write

(require 'extras)
(pp '(1 2 3))

I would force the "require" in the interpreter too. I do realize that
it is convenient to have everything included by default in the repl:
but it is easy enough for the user to include what he wants in his
.csirc file. Magic should not happen under the hood.

2. I also have some complain about the differences between the
interpreter and the compiler for what concerns runtime macros.
Consider for instance the following:

(define (helper) (print "helper called"))

(define-macro (my-macro)
  (begin
    (helper)
    'dummy))

(my-macro)

This works fine with the interpreter, but does not work with the compiler.
You (Felix) already explained to me why it is so, and the cure:

(eval-when
 (compile load eval)
 (define (helper) (print "helper called")))

(define-macro (my-macro)
  (begin
    (helper)
    'dummy))

(my-macro)

This second version is conceptually cleaner: it makes obvious that
"helper" must be available at compile time in order to be used in
the macro. The first version works in the interpreter due to black
magic: it should not work. So, I would submit to your attention the
idea of removing some dynamism from the interpreter and force the
user to use "eval-when" in the interpreter too.

3. On a similar note, the following code works in the interpreter, but
does not work in the compiler, no matter how I put eval-when:

;; problems with macros at run-time in compiled Chicken
(define (make-macro name)
  (eval `(define-macro (,name x) x)))
(make-macro 'identity-macro)
(display (identity-macro 1))

If this is not valid code for the compiler, it should not work in the
interpreter!

I do realize you intended the interpreter mostly for quick and dirty
tests in the repl and not for developing programs, still since I don't
like to wait for the compiler and I have an interpreter available, so
I develop using the interpreter. But then I expect a valid interpreted
program to be a valid program for the compiler too. Currently, this is
not the case, so I have to fix by hand my scripts adding "require" and
"eval-when" to make the compiler happy.

Conclusion: the interpreter shouldn't be too forgiving, otherwise you
will get bad habits and you will be beaten by the compiler. It is
better to be forced to write a valid program from the beginning,
that to be forced to change an already written program which is
only apparently valid.

'Nuff said for today,

                      Michele