[e-lang] Thought: DeepFrozen too restrictive for guards?

[Kevin Reid]

The plan has been to require that all objects in guard positions are  
DeepFrozen.

It occurred to me that there might be reasons to use a less  
restrictive condition. For example:

   def deopt { to get(default) { def guard { to coerce(specimen, _) {
     return if (specimen == null) {specimen} else {default} }}}}

   def ...(..., log :deopt[stdout]) {
   }

would be rejected since stdout isn't DeepFrozen.

Similarly, the new guard-based expansions in 0.8.36f use non- 
DeepFrozen guard construction:

   ? epatt```$$stdout```
   # value: epatt`[] :__MatchBind.get(simple__quasiParser.matchMaker 
("${0}"), __makeList.run(stdout))`


Possible solutions:


1. Rather than the whole guard being required DeepFrozen, 'deopt' is.

    Problems: makes guard expressions have strange semantics, as it's  
not a simple composition with CallExpr any more.


2. Guards may hold non-DeepFrozen references as long as they do not  
interact with them.

    Problems: hard to define right. Doesn't work at all for the quasi- 
pattern case.


3a. Introduce the guard-but-not-DeepFrozen operator (which I've  
mentioned before, though possibly not on e-lang).

     It would be identical to the : pattern but with a different  
symbol, and possibly using 'run' or 'match' instead of  
'coerce' (since these Are Not Guards Since They Aren't DeepFrozen).

     Problems: Hard to find a good syntax for it.


3b. Same as 3a, but guard patterns expand to it. This simplifies  
Kernel-E.

     Problems: Doesn't apply to result-guard positions. Would make  
expansions uglier by mentioning DeepFrozen (or Guard) everywhere.


(Irrelevantly, we need to kill the 'ValueGuard' name, since  
SlotGuards don't exist any more.)

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