Mon, 26 Feb 2001 07:07:55 -0800, Simon Peyton-Jones <simonpj@microsoft.com> pisze:
Most notably, Malcolm's latest proposal introduces a new form of abstraction (named thing), a bundle of attributes like Gtk or Bzip. Another environment for the compiler to manage! Soon people will want to export these things and import them elsewhere!
Yes, we will! :-) What's wrong with it? Yet another name instead of 'foreign default': foreign module I am specifying some details about a foreign module I want to interface to.
* The "gtk:" part is a concession to (b). It specifies a C package from which this procedure comes. There is then some compiler-specific mechanism for mapping the name of a C package to the location of its header files and .o file.
This gives no advantage over the current scheme. I already can specify header names in a compiler-specific way, and I still can't do it compiler-independently, and the compiler still won't push it automatically to modules which inline functions infected with C calls.
Notice that cross-module exports of inlinings are now straightforward: the foreign call carries its package name with it.
How the package is defined?
You may think this is too minimalist,
I would say: too incomplete.
Do we really need the elaboration of Malcolm's proposal?
Yes, unless a simpler design provides what is needed. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK