Re: [gobo-eiffel-develop] Introspection, persistence, debugger

[Eric B. <er...@go...>]

Hi Wolfgang,

Wolfgang Jansen wrote:
> I would like to contribute the following
> features/parts to the GEC compiler:
> - introspection (in particular, class INTERNAL)
>  and persistence closure (in particular, class STORABLE),
>  see persist.pdf
> - debugger, see debug.pdf
> 
> In the course of recent years I implemented those parts
> for the SE-1.* compiler (not integrated into the
> official release), and the last version is almost
> completely written in Eiffel. Thus, it should be
> possible to integrate the stuff into the GEC as well.
> The integration of introspection and persistence closure
> (at least the core parts) seems to be straight forward
> whereas integrating the debugger is much more involved.
> 
> Most of the development still to be done will be my work
> (help about the meaning of existing compiler classes
> and their features may be necessary from time to time).
> Moreover, the development is rather separated from
> the main lines of the development of the compiler,
> therefore, conflicts should be rare. On the other hand,
> things may take some time since it's not my main work.
> 
> What do you think about the topic?

I just finished reading your documents, and here are my
remarks:


INTERNAL
--------

In order to take full advantage of the dynamic type set
mechanism implemented in gec, my plan was to implement
class TYPE first (introduced in ECMA), and then add to
class TYPE the features currently available in INTERNAL.
The features of INTERNAL could be implemented using those
from TYPE in order to allow backward compatibility for
applications currently compiled with ISE. Let's consider
that we have in ANY:

    generating_type: TYPE [like Current]

and in class TYPE:

    attribute_count: INTEGER
         external
              "built_in"

we could implement `field_count' in INTERNAL as follows:

    Result := object.generating_type.attribute_count

and likewise for the other features in INTERNAL. In your
document you mentioned a class INTRO_TYPES. Is it similar
to class TYPE above? In the generated C code there is
already an array 'getypes' whose purpose will be to return
a TYPE object indexed by type-id.


STORABLE
--------

It would indeed be interesting to plug your implementation
of STORABLE in gec. I have two concerns though. First, are
you aware that ISE also implemented a version of Storable
in Eiffel:

http://dev.eiffel.com/cgi-bin/viewvc.cgi/trunk/Src/library/base/ise/serialization/

As far as I understood, they only use INTERNAL. So I wonder
whether you should try to use the experience you gained when
developing your Storable for SmartEiffel and try to improve
ISE's SED library rather than providing a competing library.

The other concern that I have is interoperability. It would
be nice if gec could at least have a way to read and write
the file formats produced by the old ISE's STORABLE mechanism
(at least independent_store). And why not also the file format
produced by SE 2.*, although I'm less interested in this one ;-)
It may be sound odd to try to be interoperable with ISE's old
STORABLE, but that's something I will need at work (we have a
lot of Storable files like that). And probably others currently
using ISE Eiffel will have the same need. So this will have
to be implemented at some stage.


deep_twin
---------

You didn't mention it in your message, but it is mentioned
in your document. None of the deep features are implemented
yet in gec. Even though I don't like to use deep_twin myself
(I prefer to control the level of duplication I want by
redefining `copy'), one of the programs I currently try to
compile with gec at work uses it. So it will need to be
implemented soon.


Debugger
--------

This topic is something that I'm not very good at. So I really need
to rely on others to implement a good debugging mechanism for gec.
I have not really thought about it. My only requirement is that
it should be user-friendly and should do what people expect from
a debugger. So people who want to contribute in this area will
be free to do pretty much what they want, also I will be interested
in following their progress.

But gec is not as advanced as SmartEiffel with respect to
debugging. There is currently only one compilation mode, with
no stack trace, no assertion monitoring, no exception. So
everything needs to be done in this area. If this is not
frightening you, then that would be great.



You spoke about your availability to work on this project.
INTERNAL/TYPE and deep_twin are something that I will need
relatively soon. So I guess I should start implementing
them myself. Of course it does not mean that you cannot
help or that I won't need your help. For STORABLE,
what I will need will be something similar to ISE's
independent store. I don't think that any of us can
implement that in short amount of time. I guess that
you would prefer to work on your own Storable format (which
looks interesting just by reading you document), although it
would be nice if you could have a look at ISE's SED and see
if/how it could be improved. The part of your contribution
offer that I would be the most interested in, considering
my need and your availability, would be the debugger part.
Indeed, this is not something that I need in the short term,
so you have plenty of time to work on it without too much
constraints. There is not that much conflicting parts with
what I currently work on in the compiler. And this is something
that I don't think I will be able to implement myself anyway.
And everything needs to be done from scratch. So if you are
not frightened by that, this could be an interesting experience.

Now I should mention that people contributing to the Gobo
project need to follow some programming rules. It is difficult
to follow them at first because most of them are not explicitly
stated. Some are here:

    http://www.gobosoft.com/eiffel/gobo/guidelines/

Some are just implicit (just look at how the other classes
in Gobo look like). The idea is to have a Gobo package where
all classes follow the same programming style so that we have
some sort of uniformity, instead of being a set of independently
developed parts.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com