This message has been split into two because of 5 kb message size
limitations.
(continued)
interns.c anso has undergone serious changes. Most of the introspection
primitives return values of certain fields of Hugs' storage objects
wrapped as Integers, and the rest of processing is done in Interns.hs.
In storage.[ch] along with new fields in Hugs object structures I
changed the way internal variables are named. I implemented per-module
internal variables counters, and now names of those variables are stored
in the same way as regular variables' names. This is the most
unfortunate part because strings table size grew significantly: I had to
increase the setting in prelude.h for NUM_TEXT 10 times to be able to
compile fptools. The reason for this change: I need those internal
variables' names to be independent of the order modules are compiled,
and of the number of modules compiled. I do not see the immediate
solution of this problem. One possible solution might be to use the old
way for variables that are not exported, and the new way for those
exported (like implementations of instance methods and instance
builders, but not every lifted lambda or supercombinator).
Here are things I have not done yet or do not exactly understand how to
implement them.
These include kinds (I only use them to get arity), functional
dependencies (I do not understand how the graph is structured), RANK2
(same reason).
My final goals are to make it possible for a Haskell program to access
information sufficient:
a) externalize the Hugs' compilation results to be able to use them with
alternative runtime
b) create an external format for Hugs compilation results, so they might
be loaded into Hugs and simulate the situation as Hugs has just compiled
the source (i. e. how it is done in Java or Python).
I would like to get feedback form the Hugs users community whether there
is any interest in such an extension.
PS As an example of using these primitives, I have written an
experimental web-based application, "Hugs Insider":
http://www.golubovsky.org/software/hugs-insider/article.html
which allows to enter some Haskell code, and then runs a cross reference
generator over bytecodes and other parts of Hugs storage (written in
Haskell).
Dimitry Golubovsky
South Lyon, MI
This message has been split into two because of 5 kb message size
limitations.
Dear list members,
I am suggesting one more extension to Hugs: a set of introspection
primitives. These primitives extend the existing Hugs.Internals module
allowing a Haskell program see the internal structure of Hugs'
compilation results.
This may be used for various purposes such as externalization of Hugs'
compilation results in some format and using them with alternative
runtime. With the primitives proposed, such an externalization may be
performed by a Haskell program, and the native part of Hugs does not
need to be modified. Also Hugs may be further extended to be able to
load precompiled functions/modules thus increasing the startup speed.
URL of the diff file:
http://www.golubovsky.org/software/hugs-insider/hugs98-intro.diff
I have been working on these extensions since June 2004, and the diff
file is against the July 11 CVS snapshot, but as I can see from
cvs-hugs, there have not been any significant updates in the repository
that might conflict with this patch.
These extensions work only if enabled with --enable-internal-prims
configure options.
Here is the summary of what has been done so far.
Internals.hs: added primitives to access almost all fields of Hugs'
storage objects (classes, instances, tycons, etc.) Also some upper-level
wrappers are provided to represent Hugs internal structures in a more
convenient way. I followed the same pattern which was used for the Name
type already present in Hugs.Internals. I extended the CellKind type
definition adding more data constructors to represent not only Names,
but also classes, instances, type expressions, etc. I added the whatIs
primitive which does not require an IO monad (unlike classifyCell), but
it operates with restricted set of cell kinds which I suppose do not
vary over time, therefore IO monad is not needed. whatIs also does not
have side effects because it never evaluates the cell whose kind it
retrieves. I also fixed the Haskell representation of bytecode
instructions (it looks like some Gofer stuff still was there) and added
the DIGIT bytecode (same as CELL, used for BIGNUMs because I needed to
distinguish between numbers that may go with the CELL instruction, and
numbers that make up big integers). I improved the representation of the
TABLE instruction: now it captures the names of tycon's variants. The
FLOAT instruction was removed as it seems to no longer exist in Hugs.
The TEST instruction now has a Cell as its operand rather than a Name
(which is not sufficient to cover all the variants of TEST). Data types
representing Module, Class, Instance, Tycon are made in the same way as
the data type for Name - "opaque integers". Also toplevel functions
were added providing convenient representation of Hugs' storage contents
and improved printer for bytecodes.
I added some fields to Hugs storage objects, including name.endCode
which caused changes in the prototype and implementation of codeGen.
(to be continued)
