[e-lang] literal-oname?

[Kevin Reid]

On Aug 9, 2006, at 14:42, Mark S. Miller wrote:
> Kevin Reid wrote:
>> Why has this syntax been disabled by default?
...
> 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.

I no longer remember my reasoning at the time. However, it does seem  
straightforward to handle, so I retract my objection.

   def "bizarre qualified name" { ... }

becomes

   def ::"bizarre qualified name" { ... }

or

   { def ::"bizarre qualified name" { ... } }

or

   def simpleName {
     to __getAllegedType() {
       return meta.context().getSource().asTypeDesc() \
         .withFQN("bizarre qualified name")
     }
     ...
   }

or

   def simpleName {
     to __getAllegedType() {
       return meta.evaluator().asTypeDesc(meta.context().getSource()) \
         .withFQN("bizarre qualified name")
     }
     ...
   }

Not strictly relevant:

The last case is what will be necessary if we move to Term-trees for  
E, as previously discussed, since the source tree no longer has any E- 
specific behaviors. I am currently working on implementing this in E- 
on-CL.

This is a slight uglification in several places, but I think it has  
the advantage of making the Kernel-E behavior more concentrated in  
one object (the exposed evaluator) rather than spread out (and yet  
necessarily non-extensible) in the data structure.

You can't sensibly 'define a new ENode' in the current system, since  
the evaluator has complex invariants.

But if it's eval(node) instead of node.eval(), and nodes are generic  
rather than having Kernel-E structure constraints baked in, then it  
is more feasible to work with an extension or other variant of the  
language, or a refractive/virtualized evaluator.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>