[e-lang] literal-oname?

[Mark S. Miller]

Kevin Reid wrote:
> Why has this syntax been disabled by default?

First, to be clear, the situation is even worse in release candidate 0.8.37a 
and in the current SVN head than it is in 0.8.36t -- the literal-oname option 
has been discontinued:

     ? interface "$foo" {}
     # syntax error: reserved: literal qualified name no longer accepted
     #   interface "$foo" {}
     #                    ^

And in syntax-props-default.txt:

     #### Discontinued as of 0.8.37a ####

     # Allows the use of a literal string as an object-expr's qualified or
     # fully-qualified name.

     # e.enable.literal-oname=allow


I did this because:

1) As we discussed verbally, I'm changing the Kernel-E ObjectExpr so that

     def varName { ... varName ... }

is now kernel, so that direct recursive access of an object to itself doesn't 
require creation of an intermediate promise. This addresses the issue you 
raised: that a self-referring object that's otherwise DeepFrozen would, 
because the self-reference requires a promise, need to be audited by 
EventualDeepFrozen, since it would fail the DeepFrozen audit. With this 
change, it can pass a hypothetical DeepFrozen audit, once we have a DeepFrozen 
auditor that knows about the new ObjectExpr.

2) When making that change, it turned out to be difficult to also support the 
old literal-oname syntax for compatibility.

3) I expect that no one other than you would be effected by discontinuing the 
literal-oname syntax. From that same previous conversation, I thought you said 
that it would be painless for you to stop using it. If I misunderstood, my 
apologies.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM