smart-extension --- a signed unit with meta data

[Greg Pettyjohn <GregP@bsquare.com>]

-----Original Message-----
From: Matthew Flatt [mailto:mflatt@cs.utah.edu] 
Sent: Sunday, January 23, 2000 12:48 PM
To: Greg Pettyjohn
Subject: RE: plt-scheme message


Quoting Greg Pettyjohn:
> I wasn't sure whether this was the correct forum for that.

plt-scheme is definitely the right forum. I think you should send
everything else you wrote in your message to plt-scheme, and point to
ftp.cs.rice.edu/pub/mflatt/ (or wherever you put it) for the code.

Matthew

-------------------------------------
Very well, as per Matthew


In playing with the extension stuff, I noticed that when I switched
over to the unit model, I had a whole list of exports that I needed to
maintain.
In particular, there are redundant entries in several locations in the code:

1. In scheme_intialize
2. In the unit_init function.
3. In the signature file e.g. sigs.ss

In SrPersists, Paul centralizes this data a little better by putting it
all into a .tbl file. Then the work in the various init functions is handled
by
a simple for loop.

What I did with the example "smart-extension" was to write a routine that
returns a list with the signature information. Then I worked out a way
so that scheme_initialize returns a *signed* unit rather than an ordinary
unit.

The unit exports the signature function called export-list. So if you want
the
export information you can invoke the unit as follows:

(require-library "macro.ss")
(define smart-extension@ (load-relative-extension (build-path "bin"
"smart_extension.dll")))
(define-values/invoke-unit/sig (export-list) smart-extension@)

When you call export-list it produces a list suitable to be used as a
signature:

(eval `(define-values/invoke-unit/sig ,(export-list) smart-extension@))

The trick is that export-list uses exactly the same .tbl data that the
scheme_initialize and unit_init
do. It's a short little routine with a two-line for loop in it. Plus, it can
never be wrong, the signature
it produces will match whatever is needed since it is based off the same
data.

Of course, smart-extension@ is a signed unit just like any other signed
unit. Once you have the export information,
you can use it however you want.

Another thought crossed my mind while I was writing this. The .tbl
information also contains handy information
about each exported function. In particular, it knows the min arity and max
arity for each function. I suppose
you could also add more fields to the structure if you wanted as well.
Anyway, it wouldn't be hard to write a routine
help-list.

(help-list help-proc)

help-list would accept a single argument help-proc. help-proc would be a
proceedure of 
three arguments, min-arity, max-arity, name. When called, help-list would
apply help-proc 
to each function in the .tbl array. The idea is that help-proc would be
supplied by a help
system and would automatically load reference data for each of the
functions.

I've already, experimented with a help-proc that makes a doc.txt file.