[Types-sig] Back to basics

Greg Stein gstein@lyra.org
Thu, 23 Dec 1999 01:35:40 -0800 (PST)


On Wed, 22 Dec 1999, Paul Prescod wrote:
> Greg Stein wrote:
> > This is all fine as long as the design does not preclude the availability
> > of typedecl information at runtime. 
>...
> > Some of these discussions about new
> > namespaces or not worrying about names being defined could prevent that.
> 
> I don't follow the part following "or".

Sorry. There are at least a couple things that have been discussed
recently might prevent us from having typedecl objects at runtime:

- shifting names of typedecl objects into a distinct namespace
  (how does the runtime access this namespace? when is the namespace
   created? etc)

- undefined names, per the runtime execution order
  (at the time a function object is created, we need a typedecl object for
   one of its args; if the name referring to the typedecl is undefined at
   that point in the execution, then we fail or we don't get a typedecl;
   both situations are untenable for me)

In light of these possible directions in discussion, I'm concerned that
following them will mean we don't have runtime typedecls.

While walking to dinner tonite, I came up with a great example for runtime
typedecl objects: debuggers. I imagine there are other IDE functions that
would find the information useful.
[ of course, I can also imagine that, in some situations, an IDE needs
  typedecl objects without loading a module ]

>...
> > [ personally: I'd recommend parameterization get punted to V2, although I
> >   worry that if we don't take its syntax into account, we might preclude
> >   its addition later on. ]
> 
> Agreed. Tim Peters convinced me that it isn't actually too big of a
> deal. Parameterization is almost like string substitution. In some
> lexical scope, _T stands for a paramater that is substituted in when a
> concrete object is declared. If you treat it like string substitution
> then the semantics are pretty simple. One minor detail to work out is
> whether to predeclare the list of parameter variables or just look for
> names beginning with underscores.

Sure. Parameterization isn't a hard concept, but coming up with a nice
syntax :-). I would hope that we don't base semantics on the presence of a
leading underscore.

In your original "Back to basic" note (which started this thread), you
state that out-of-line files would be used. I'm beginning to agree with
the need for separate interface files. But for a different reason :-).
Let's say that you have a module that has a few "decl member" statements
here and there. Those decl statements along with function and class
definitions form its interface. How do we cache that interface so the
type-checker can use it later? If we are analyzing module "foo" and it
imports "bar", then where do we get bar's interface? I hope the answer
isn't that we go and parse bar to derive it.
[ actually, I'd hope we somehow generate a central database of interfaces,
  but that is an implementation detail best left for later :-) ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/