[Grace-core] RFC: Compile-time constants

[Timothy Jones]

On 02/05, Andrew P Black wrote:
> On 1 May 2014, at 22:55 , Timothy Jones <tim at ecs.vuw.ac.nz> wrote:
> >  let MyType<T> = type { thing -> T }
> > 
> >  let aThing = brand
> > 
> >  let Thing = aThing.pattern & type { another -> MyType<Thing> }
> > 
> >  def myThing : Thing = object is aThing {
> >    def another is public = object { def thing is public = outer }
> >  }
> > 
> > The static behaviour of this example should be clear,
> 
> Not at all.  You don't say what your goal is: what are you trying to achieve?

To demonstrate the use of the declarations. The actual example isn't
particularly sensible. It creates a type 'Thing' which matches those objects
that are branded 'aThing' and which have a method 'another' that returns an
object with a method 'thing' returning a Thing. The point is that the type is
created from a combination of types and other static values, and also uses
mutual recursion between static declarations.

> > but all of the
> > declarations contain real objects
> 
> Yes
> 
> > which must be created at runtime.
> 
> No.  Your premise is that you know everything about these objects at compile
> time.   So get "unstuck" from the idea that objects don't exist until runtime.
> Objects like 1 and true exist at compile time; so do type objects.   In fact,
> you can regard any immutable object that can be written in the program as
> existing at compile time.
> 
> Of course,  semantically,  there is no phase distinction (between compile- and
> run-time) in the language.  Pragmatically, the compiler can lay down the
> object structure at compile time; it doesn't have to lay down code and then
> ensure that this code is executed at runtime to produce the object later.

But what if the object depends on runtime information? The type system can still
reason about these objects: 'statically known' isn't the same as 'statically
exists'. If a method creates a brand for some internal type checking, then every
time that method is called a unique brand is created. We don't statically know
how many times the method will be called, so we can't create all of these brands
in advance, but we can still reason about the branding within the context of
that method. That's all we're doing inside a module, it's just that we know it
only runs once.

-- 
Tim