[clisp-list] critique of default-foreign-language

[Hoehle, Joerg-C. <Joe...@t-...>]

Hi,

Sam Steingold wrote:
> I am sorry, but I do not understand a single word of what you are
> saying.

My summary is: the current implementation of default-foreign-language makes simple things look simple, but complex things unpredictably broken.

I'll try the "show by example" approach. Consider:

(DEFAULT-FOREIGN-LANGUAGE :stdc)
(def-call-out foo ...)
(def-call-out bar ...)

(def-c-var callback-pointer (:name "ffi_user_pointer")
  (:type (c-function (:arguments (data c-pointer)) (:return-type int))))

(defun set-callback-1arg (fun)
  ;; symbol-macro on foreign-variable
  (setf callback-pointer fun))

(defun set-callback-2arg (fun)
  (setf (cast callback-pointer
	      '(c-function (:arguments (data c-pointer) (more-data uint)) (:return-type int)))
	fun)

Observations:
a) the programmer gets used not to state :language in foreign function type declarations.

b) CLISP makes no guarantees of any sort as to what gets parsed (-> set in stone) when. I distinguish compile-time, load-time and run-time.

Analysis:
i) callback-1arg works. PARSE-C-TYPE on the callback pointer has been called at load-time, in which the DEFAULT-FOREIGN-LANGUAGE was bound.
ii) callback-2arg can break. It produces different functions, depending on the user's settings or previously loaded or executed code!

This is because PARSE-C-TYPE is called at run-time there, as opposed to load-time (or compilation-time).

One might consider adding :language just in callback-2arg.
I do not like this irregular behaviour at all.
1. How to explain the programmer that the addition
   be needed at just this place and not the others?
2. The programmer might not even add the line, since
   the "set-default-to-stdc" behaviour encourages
   lazyness and incorrect code: s/he might have set it
   earlier (in his/her .mem file) and forget about it.
3. Furthermore, the programmer might not even get a warning for
   this module (and thus never add :language), because other
   code s/he loaded previously may already have set the default.

So my summary is: the current implementation of default-foreign-language makes simple things look simple, but complex things dangerous. That's not what I expect from Lisp.

That's enough for now. I can speak about parse-c-type optimization and also scoping issues at a later time.

Regards,
	Jorg Hohle.