[e-lang] Rename Guard, ValueGuard (was Re: Conflict of principles)

[Kevin Reid]

On Sep 2, 2005, at 8:10, Mark Miller wrote:
> Kevin Reid wrote:
>> I haven't thought of a decent name for Guard, though; just
>> ExtendedGuard, SugaredGuard, FancyGuard, etc., which might be true but
>> don't really say anything.
> Unless someone thinks of something better, I'll go with 
> "ExtendedGuard".

(rambling)

Additional thought: The name, ideally, should convey that the 
additional verbs can be implemented entirely in terms of the base guard 
- that they are shorthands, rather than separate operations.

However, I think it will eventually be important to preserve the 
guard's ability to override those operations to be more than that; for 
example, the guard resulting from this expression can be much more 
efficient if IsAny (previously discussed for replacing the ==-pattern) 
can implement | to define a new IsAny guard instead of an or-guard:

   accum none for item :notNull in dataSource { _ | IsAny[item] }

Hypothesis: eventually, we will want the ability to write "if (g =~ eg 
:ExtendedGuard) { eg } else { __extendGuard(g) }". Thus a guard can 
offer optimized/customized versions of the guard compositions (in which 
I include not/0), or its client can add the default extensions when 
necessary.

This requires a well-defined way to ask an object if it is an 
ExtendedGuard. I have some further thoughts on how to implement this 
type of test which I hope to post soon.

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