[Grace-core] RFC: Compile-time constants

[Timothy Jones]

On 05/05, Michael Homer wrote:
> So this complete program:
>   method greet {
>     def hello = "Hello!"
>     print(ehllo)
>   }
> raises no errors?

Sure, that's the standard for dynamically-typed languages, right? You need to
slap a 'dialect "typed"' at the top to get the static check.

> How is this:
>   var useString := true
>   method foo {
>     if (useString) then {
>       object {
>         def greeting = "Hello"
>       }
>     } else {
>       object {
>         def succ = { x -> x + 1 }
>       }
>     }
>   }
>   object {
>     inherits foo
>     print(greeting)
>   }
>   useString := false
>   object {
>     inherits foo
>     print(succ.apply 2)
>   }
> ?

I wouldn't count that as a tail-return of an object.

> How far does this go towards, say, Ruby's instance_eval? How dynamic
> is the scoping you're thinking of?

I was under the impression that this was entirely normal for a dynamically-typed
language. You can't extend object definitions, and you can't observe a mutation
of an object's structure.

> >> >> - Can it be inherited?
> >> >
> >> > No, for similar reasons as 'let'.
> >> Hang on, I can see how there's a case for lets to be top-level-only,
> >> but methods? How is this code:
> >>   method foo {
> >>     object {
> >>       method x is public, static { 1 }
> >>       let y = x + 1
> >>     }
> >>   }
> >>   object {
> >>     inherits foo
> >>    }.x
> >> ?
> >
> > I'm not sure what you're asking here. I answered this as 'can it be overriden',
> > so we might be on a different page here.
> Is that code a static or dynamic error?

There's a dynamic error when it tries to hoist the static definitions, as
numbers (or at least number instance methods) aren't marked as static (though I
guess they could be?).

>  Can I access x on the subobject? If I let that to a static binding, can I
>  access x in static context?

Yes. Yes.

> >> On the other hand, if it can be inherited, can it refer to self?
> >
> > If self is static, I guess.
> If the method can be inherited, we don't know which object "self" will
> be at the execution. Does that matter?

Probably. This is one of the things I need input on. In general I think it would
be safer to ban things which there aren't definitive use cases for.

> >> >> - What is it allowed to return?
> >> >
> >> > A request for another static value, or a fresh object (like a brand -- this is
> >> > why you can annotate a class as static).
> >> These are a lot like the inheritance rules.
> >>
> >> Can you inherit from a static method?
> >
> > Do you mean if the inheriting object is also static?
> I mean is this valid code:
>   method foo(x) is static {
>     object {
>       method blah { x }
>     }
>   }
>   method bar is static {
>     foo(1)
>   }
>   object {
>     inherits bar
>   }
> ? I assume it can, but I'm not clear on just how if at all that
> interacts with staticness.

The proposal hasn't taken that into account. I was thinking the static
annotation would just restrict content and then allow that method to be used in
a static context. Right now I would be surprised if that code would be allowed,
as bar doesn't tail-return an object. I'm certainly not suggesting we *require*
inheritable methods to be annotated as static either.

-- 
Tim