Jim Starkey <jas@...> wrote:

>A couple of questions and comments.

Likewise. I've been thinking about this very issue for a while.

>First, do you think this stuff needs to be in the engine, or would
>an extension to GDEF be sufficient? Is there really much gain
>over simple cut and paste?

No, it shouldn't be in the engine, depending on how you define engine. It
is really a language and code generation issue.

>Second, C++ templates are kinda funny beasts, added very late in the
>development cycle to paper over a specific design problem concerning
>container classes. In essence, templates are compile/link time macros.
>To the best of my knowledge, no other language has adopted the idea.

Ada, Modula-3 and Clu have generics.

The major difference these generics and C++'s templates is in the
interaction with the type system. In C++ operating overloading and lookup
rules let the compiler decide which template to instantiate, and generate
code accordingly. In the languages above, the programmer must specifically
instantiate generics. Obviously in C++, the programmer must also explicitly
class templates, eg. list<int>.

This contributes to the power (and danger) of C++, and the ability to
implement things like the C++ STL, but I don't think it is appropriate for
an SQL type environment.

>Wouldn't a simple macro facility answer your needs and be a great
>deal more flexible to boot? I'm generally not a proponent of macros
>(macros in a language is a confession by the designer that he screwed
>up), but they seem a better match for your problem.

Type checking, scope, single evalulation of arguments.

>Lastly, and this may determine the choice between a template and a
>macro model, what update semantics do you want. I presume that
>a change to the template should force a change to all instances.
>But what if one fails -- what happens?

There is a distinction between defining the template and instantiation.

One model is that a template can be defined without instantiation. It is
stored in some intermediate form tree. When it is instantiated, the
parameters of instantiation must be provided, and the appropriate code
generated (BLR, whatever). This is the trigger, procedure, whatever. After
the instantiation, modifications to the original template do not affect the
generated code, unless there is specific operator intervention.

Administratively, it would be a useful thing to be able to regenerate all
generated code when a template changes (and have that be an atomic
operation), but that is adminstrative rather than architectural.

>If the answers are a) engine, b) template, and c) consistency, there
>are major changes to the engine, the system tables, and the various
>DDL processors, most of which will be difficult to make backwards
>compatible. Do you think this is worth the cost of a little cut
>and paste activity in a text editor? It seems to me likely that the
>number of keystokes expended in the implementation would exceed the
>number of keystrokes expended over the lifetime of the feature...

Yes, there are major changes. There is also the little issue of the type
system and SQL3 ...

What do the various intermediate forms between parsers and code generators
look like in Interbase? Is there a standardised intermediate
representation, or does every compiler do its own thing?


Jan Mikkelsen