Subject: [clisp-list] critique of default-foreign-language (was: tiny suggestion about foreign1.lisp (FFI))

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Apr 22 10:42:08 2002

Hi,

Sam Steingold wrote:

> if the calling convention (default-foreign-language) is so crucial,
> let's make the :language argument required, 
This is an acceptable solution.

However, it goes against the "support lazyness" principle. And here,
I believe meeting an acceptable degree of lazyness can be achieved
by providing a reasonable default.
 + :language :C was a reasonable default back when the FFI was written.
 + :language :STDC is a reasonable default these days.
 - unknown defaulting behaviour based on a non-closed-over
   default-language special variable is not a reasonable default,
   as I tried to explain. It's calling for crashes.

To be more precise: the one default should not change anymore in future
(compatibility). If somebody finds this unacceptable (why accept
change now when it should be forbidden in future?) then the only
resort I see is make :language a required argument.

Requiring :language will break some code (not all, because presumably
many use DEF-C-CALL-OUT instead of DEF-CALL-OUT). Probably very few, if any.

My argument in favour of :C -> :STDC was similar in that it presumably
also shouldn't break much existing code, and possibly even match current use
and thus actual function declarations better.

> even when default-foreign-language is there.
I don't understand. There's no need for default-foreign-language
anymore when :language is required?

That's why I said I cannot see any value in DEFAULT-FOREIGN-LANGUAGE.
Let'S kill it.

> > o Do not deprecate DEF-C-CALL-OUT. That's what 99% or programmers
> > have been using 95% of time.
> > It consisely expresses the function's signature without
> > affecting arguments. Think about the subtle difference between:
> > (def-stdcall-call-out foo
> >    (:arguments ((callback (c-function (:arguments #)))))
> >    (:return-type int))
> > and
> > (default-foreign-language :stdcall)
> > (def-call-out bar
> >    (:arguments ((callback (c-function (:arguments #)))))
> >    (:return-type int))
> 
> your example does not use def-call-out!
I don't understand. There's def-call-out bar above.

> the default-foreign-language is used not only in 
> def-call-out, but also in c-function.
Sure. All calls to PARSE-C-FUNCTION and PARSE-C-TYPE in foreign1.lisp
are affected, at compile-time *and* at run-time. But what is the point?

> in your example, the problem could have been resolved by issuing a
> default-foreign-language form in top-level

What top-level do you mean?

 + interactive read-eval-print top-level?
 + file top-level?
The latter is not enough.

Perhaps I didn't make my point clear:

My example produces a crash (or at least an incorrect calling convention) when the run-time value (when calling regexec) of the user's DEFAULT-LANGUAGE and the programmer's one differ. Using DEFAULT-FOREIGN-LANGUAGE in some .lisp file does not help for run-time. Neither is it load-time that I'm talking about.

By not allowing control over run-time, DEFAULT-FOREIGN-LANGUAGE induces crashes on machines which differ from the programmer's one (as seen too much on M$-Win*). This is not acceptable.

Therefore, I repeat: let's kill DEFAULT-FOREIGN-LANGUAGE.

Whether :language is made required or defaults to :C (status quo) or :stdc is *another* 
topic. All three choices (require, :C, :StdC) I find acceptable (and favour :stdC).

Regards,
	Jorg Hohle.

---

From: Sam Steingold <[email-masked]>
Date: Mon Apr 22 11:46:02 2002

Joerg,
you are not using the "reply" feature of your mailer (or it is broken),
which makes it hard to read your messages: usually, when someone quotes
too little, I can hit "^" in gnus and see the parent message in the
thread.  it does not work with your messages, alas.

> * In message <[email-masked]>
> * On the subject of "[clisp-list] critique of default-foreign-language (was: tiny suggestion about foreign1.lisp (FFI))"
> * Sent on Mon, 22 Apr 2002 18:06:04 +0200
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>

the result of loading a file (compiled or not) should not depend on the
load environment. (e.g., *package*, *foreign-language* &c).

this is accomplished by ensuring that the macroexpansion of DEF-CALL-*
contains a :LANGUAGE arg, whether it was supplied or not.
this is not done now, and it is a bug.
I will try to fix it soon.

> My example produces a crash (or at least an incorrect calling
> convention) when the run-time value (when calling regexec) of the
> user's DEFAULT-LANGUAGE and the programmer's one differ. Using
> DEFAULT-FOREIGN-LANGUAGE in some .lisp file does not help for
> run-time. Neither is it load-time that I'm talking about.

at run time the *foreign-language* should be irrelevant and
incorporated in the FOREIGN-FUNCTION object (the calling convention is
specific for each function, right?)

> By not allowing control over run-time, DEFAULT-FOREIGN-LANGUAGE
> induces crashes on machines which differ from the programmer's one (as
> seen too much on M$-Win*). This is not acceptable.

if you are saying that the run-time value of *foreign-language* can
influence the behavior of an existing FOREIGN-FUNCTION, we have a bug
in the calling conventions of FOREIGN-FUNCTIONs.

> Therefore, I repeat: let's kill DEFAULT-FOREIGN-LANGUAGE.

let's kill *package* too and require package prefixes for all symbols
in all files.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
MS Windows: error: the operation completed successfully.