-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <Pine.GSO.4.03.10105301313430.9205-100000@dog.crn.cogs.susx.a
c.uk>, David Young <davidy@cogs.susx.ac.uk> writes
>A few thoughts about the GSL idea:
>
[Details about other libraries, e.g. NAG, omitted]
>
>Anyway ...
>
>If GSL is good, then I agree with Aaron about what would be useful, viz:
>
>> I was thinking more of providing convenient pre-packaged interfaces
>> with some limited documentation, which would point to the full GSL
>> documentation.
>
>and
>
>> ... (A pop11 program reads the
>> GSL documentation, and then genrates all the interface files ?????)
>
>[Maybe it would be sufficient for it to read the header files?]
>
I agree. For GSL, or any package to work as a library, all of the public
interface should be declared in the header files. They would be easier
to work with than the documentation.
I believe Aaron wants a slim volume of interface documentation for
Poplog users. A very formulaic interface reference document can be
generated from the same header files as the interface itself, possible
segmented according to the directory or file segmentation of the
original source. We may be able to correlate this segmentation with
chapters of the original documentation, and if it is sufficiently well-
structured, we may be able to pull descriptive text to accompany
translated-header-based function descriptions.
It would be an interesting exercise to define coding and documentation
standards that support this type of transformation effort. Perhaps the
Gnu community has already done this?
>Ideally an installer ought to be able to download and compile GSL and
>then generate the interface just by specifying a path and running a
>procedure. After that, a user should be able to say "uses gsl" and then
>be able to able to run gsl routines via Pop-11 routines, without ever
>looking at HELP/REF EXTERNAL.
>
I think that this route is essential. If we include GSL with Poplog,
then I believe Poplog's license will have to be a GPL.
>However, there are some hard bits. One is dealing with the GSL macros.
>Another is deciding whether Pop-11 arrays can be passed to the gsl
>procedures, or whether the user has to do some explicit translation.
>There are, I suspect, quite a few similar major representation issues.
>
In general, when generating a Pop-11 interface to an arbitrary library,
then there will be substantial representation problems to be dealt with.
However, I have been slowly analysing the code, and so far, I think GSL
provides few of these.
Starting with the C macros, these divide into public constants, private
constants and genuine macros. I hope that none of the macros constitute
part of a public interface - if they do, then GSL would only be usable
when included as source code in a project. I think it is more likely,
given the stated intentions of the authors that these macros are only
private and can be ignored by Poplog. (Note that I haven't yet got a
successful build of the libraries, as my download appears to contain a
large number of configuration faults).
Of the remaining constants, I initially thought we would have to filter
the headers to locate "#define" statements, and further filter with a
simple rule that tests if the macro value is numeric. In general, we can
extend this to provide a mechanism for importing constants from any
package into a "#define" filter over the file tree, piped through a rule
applier that selects relevant macros. E.g. we could write Poplog pattern
matching rules to ignore anything that parsed as C/C++ code.
Looking more closely at the GSL source, there is a gsl/const directory
with several header files. This may be the only place to declare
constants that are part of the public interface. Whether this is so, or
not, we can generalise our file filter for the constants translator to
include rules for only looking at certain files.
My process generalisation for this part of an interface generator then
becomes:
[Directory] -> (Tree Lister)
-> (Directory Filter) <- [Directory List]
-> (Filename Filter) <- [Filename List]
-> (Hash Define Filter)
-> (Constant Rule Applier) <- [Statement Rules]
This uses an optional directory list, a filename list and a statement
rule-set. The statement rule set might include filter rules to select or
discard statements under consideration, and transformation rules to
generate the target statements that "translate" the original. We will
see similar components in the remaining components needed to process
public functions, type definitions and any global variables, so it may
make sense to generalise these data sets and label them in sections
relevant to each class of component we want to process.
I'll post suggestions regarding the handling of structures, function
prototypes, global objects and externals (file references, shared
memory, semaphores, queues, environment variables, etc.), where they are
relevant, if no-one else covers this before I've completed some further
analysis.
>I'm not volunteering to do anything about it just yet, but I am
>interested in the project.
>
Ideas and moral support are appreciated.
>David
>
>
Regards,
- --
Jeff Best (jeffb@jtbest.demon.co.uk)
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBOxyXH/Hj+enJbeYqEQJIqQCfV8N1y+TOdX9yiXrBGqSuZ0aWKVIAn0BD
0Y5Z3zueDZOSLor+JQSGQzO4
=fzHK
-----END PGP SIGNATURE-----
|